Идем дальше. Расскажу, что делать, если физрук оставлял вас после уроков и не давал пользоваться GraphQL.
⬇️
⬇️
1. GraphQL крут тем, что из коробки дает тебе документацию, валидацию запросов/ответов и TS-типы. Об этом подробно рассказала @pgurtovaya на прошлой неделе.
2. Но проблема в том, что бэкендеров, которые только вчера отказались от SOAP или RPC в пользу JSON REST API, довольно трудно заставить заехать на GraphQL.
Поэтому расскажу, как получить developer experience хотя бы приближенный к GraphQL.
Поэтому расскажу, как получить developer experience хотя бы приближенный к GraphQL.
3. Первая мысль, которая в такой ситуации приходит в голову, - а давайте сами поднимем GraphQL-сервер и напишем резолверы к существующему REST API.
Об это, например, рассказывал @nodkz на HolyJS:
Об это, например, рассказывал @nodkz на HolyJS:
4. Но лично я в таких случаях практикую другой подход. Первым делом нужно попросить от бэкендеров машиночитаемую документацию хоть в каком-нибудь виде. RAML, Postman - не важно. Обычно они соглашаются на Swagger.
5. Если бэкендеры сопротивляются, то мы сами начинаем писать Swagger внутри фронтовой команды. То есть буквально вручную пишем yaml-схему на методы, которые дергаем и описываем ответы, которые ожидаем.
6. Из этой схемы дальше мы генерируем TypeScript-типы. Я пробовал разные библиотеки, но остановился на github.com/drwpow/openapi…
Если у тебя клиент на TS, то тебе все равно пришлось бы писать типы вручную. Вместо этого легче написать Swagger-схему и сгенерировать типы.
Если у тебя клиент на TS, то тебе все равно пришлось бы писать типы вручную. Вместо этого легче написать Swagger-схему и сгенерировать типы.
7. Но что гораздо круче – это то, что, помимо типов, можно сгенерировать и полноценный клиент с помощью github.com/OpenAPITools/o…
Т.е. не нужно вручную создавать сервисный слой для работы с API, писать реквесты, типизировать вход-выход и т.д.
Т.е. не нужно вручную создавать сервисный слой для работы с API, писать реквесты, типизировать вход-выход и т.д.
8. Качество генераторов (openapi-generator.tech/docs/generators) очень разное. Возьмем, например, typescript-fetch и попробуем сгенерировать клиент для Swagger-схемы с полиморфным ответом oneOf. Что-то типа такого: 
9. Не знаю как оно работает для Swagger v2, но на третьей версии я получаю нормальный тип:
loginMethod(): Promise<LoginSuccess | LoginFail>;
Но вместе с типом генератор решает сходить регуляркой по всему файлу и поставить эту палочку везде, даже в импортах:
loginMethod(): Promise<LoginSuccess | LoginFail>;
Но вместе с типом генератор решает сходить регуляркой по всему файлу и поставить эту палочку везде, даже в импортах:
10. Ну а что вы хотели? Это вам не GraphQL.
Подобная проблема описана в ишьюсе github.com/OpenAPITools/o…. Я так понимаю, его просто закрыли год назад.
С typescript-axios (openapi-generator.tech/docs/generator…) таких проблем нет. Поэтому внимательно выбирайте генератор.
Подобная проблема описана в ишьюсе github.com/OpenAPITools/o…. Я так понимаю, его просто закрыли год назад.
С typescript-axios (openapi-generator.tech/docs/generator…) таких проблем нет. Поэтому внимательно выбирайте генератор.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
