𝘂
тогда вручную продублировать по квере на каждый rest эндпоинт
Size: a a a
2021 September 29
PP
да, руками описать все резолверы - это вариант, но возможно есть уже что-то готовоее
𝘂
федерация это либа позволяющая написать несколько микро бэков и один внешний псевдо бэк, который автоматически смержит все микро бэки в один
PP
Федерация умеет работать в рестами?
𝘂
это чисто gql технология
PP
Я тоже так думал, поэтому не упомянул ее в вопросе
AO
можно над рестовским API сделать GraphQL (через https://github.com/apollographql/apollo-server/tree/main/packages/apollo-datasource-rest, например) и потом объединить в один через федерацию
PP
да, это интересно. Только зачем через федерейшен объединять, он же вроде может несколько сорсов вместе
PP
А у вас есть опыт использования в проде этой штуки?
PP
Как она, проблем не было?
P@
Лучше чем руками, никакой генератор не сделает. Я руками оборачиваю с помощью graphql-compose с описанием дополнительных связей между entity, с queryCost и прочими плюшками. В любом случае все наверное закончится у вас гибридным подходом. Часть генерите, часть руками дозавязываете.
Я на эту тему доклад делал, можете посмотреть, возможно подчерпнуете какие-нибудь идеи
https://youtu.be/CA_ZVf5lbWI
Я на эту тему доклад делал, можете посмотреть, возможно подчерпнуете какие-нибудь идеи
https://youtu.be/CA_ZVf5lbWI
АР
Кто-нибудь смотрит GraphQL Conf? )
PP
Ну в общем-то я к гибридному варианту склоняюсь тоже, но хочется по максимому использовать что-то готовое.
В любом случае всем спасибо
В любом случае всем спасибо
P@
Я смотрю и вспоминаю Краснодар )))
Шрути Капур выступает со своим доработанным докладом. Процентов 50 она рассказывала 2-3 года назад.
Шрути Капур выступает со своим доработанным докладом. Процентов 50 она рассказывала 2-3 года назад.
P@
Если у вас NodeJS и готовы вложиться инженером в опенсорс на разработку graphql-compose-openapi, то я могу вам помочь все спроектировать и напилить генератор. Который из свагерровской схемы позволит генерировать запчасти типов и резолверов, которые потом можно будет склеивать в большое волосатое АПИ.
АР
@nodkz Кстати, видел? 😉
https://github.com/dotansimha/graphql-eslint/pull/643/files#diff-0b5ca119d2be595aa307d34512d9679e49186307ef94201e4b3dfa079aa89938R50
Потихоньку превращаем твой https://graphql-rules.com в правила graphql-eslint. )
https://github.com/dotansimha/graphql-eslint/pull/643/files#diff-0b5ca119d2be595aa307d34512d9679e49186307ef94201e4b3dfa079aa89938R50
Потихоньку превращаем твой https://graphql-rules.com в правила graphql-eslint. )
P@
О крутяк!
Мы недавно впилили туда проверку имен файлов и название операций внутри файла https://github.com/dotansimha/graphql-eslint/pull/458
Мы недавно впилили туда проверку имен файлов и название операций внутри файла https://github.com/dotansimha/graphql-eslint/pull/458
PP
пока не могу сказать, но буду иметь в виду.
Вообще у нас не open-api в основном. У нас кастомное подобие RMI. Так что там по идее надо парсить java интерфейсы. В общем не просто все 🙂
Вообще у нас не open-api в основном. У нас кастомное подобие RMI. Так что там по идее надо парсить java интерфейсы. В общем не просто все 🙂
P@
Ну если у кастомного RMI есть схема/интроспекция, то можно на базе нее написать генератор. Самое главное чтоб в каком-то перевариваемом стандарте была, чтоб могла другим людям пригодиться в виде опенсорс решения. В противном случае, мне не шибко интересно будет участвовать в выпиливании кастомного генератора на безвозмездной основе.