Size: a a a

GraphQL — русскоговорящее сообщество

2021 August 12

EP

Ekaterina Pantaz in GraphQL — русскоговорящее сообщество
пока что доступ советуем осуществлять через SDK, это был один из весомых аргументов, что это не нужно, но планы могут поменяться - лучше закладываться по максмуму, чтобы потом не переделывать
источник

P@

Pavel @nodkz in GraphQL — русскоговорящее сообщество
Скорее всего ваше апи будут с чем то “склеивать” (federation stiching) и дальше использовать как повезет.

Лучше на федерейшен тогда вам заморочиться, чем на строгое соответствие их пагинации (под названием Relay connection specification) если мы про нее говорим.
источник

t

toriningen in GraphQL — русскоговорящее сообщество
я бы советовал не экспозить gql как публичный поддерживаемый API и лучше отдавать клиентам SDK
источник

t

toriningen in GraphQL — русскоговорящее сообщество
стоимость интеграции меньше, миграции проще
источник

P@

Pavel @nodkz in GraphQL — русскоговорящее сообщество
по любому будите переделывать
источник

P@

Pavel @nodkz in GraphQL — русскоговорящее сообщество
раза три
источник

P@

Pavel @nodkz in GraphQL — русскоговорящее сообщество
не встречал никого, кто бы с первого раза сделал нормального апи
источник

P@

Pavel @nodkz in GraphQL — русскоговорящее сообщество
так что закладывайте лучше сразу время на переделки
и лучше быстрее деливерите то что есть клиентам
источник

P@

Pavel @nodkz in GraphQL — русскоговорящее сообщество
чтоб быстрее собрать фидбек и быстрее начать пилить новую
действительно удобную версию
источник

EP

Ekaterina Pantaz in GraphQL — русскоговорящее сообщество
да это правда
источник

𝘂

𝘂𝘅𝗻𝗮𝗺𝗲... in GraphQL — русскоговорящее сообщество
graphql + codegen + typescript = мгновенный фидбэк на клиенты в  случае изменения схемы на бэке
источник

EP

Ekaterina Pantaz in GraphQL — русскоговорящее сообщество
Да, спасибо, я имела ввиду именно connect specification.  
Стичинг сейчас становится актуален для нас. мы как раз начали смотреть в сторону этой архитектуры - у нас условно есть сейчас основное апи, мы хотим еще расширять доп сервисами через стичинг схем. рассматривали варианты либо  через федерейшн, либо через schema-stitching-handbook, ваш совет что выбрать тоже был бы очень полезен для нас 🙂
источник

P@

Pavel @nodkz in GraphQL — русскоговорящее сообщество
https://docs.ton.dev/86757ecb2/p/612162-schema/t/888748

вашей сортировкой ужасно неудобно пользоваться
рекомендую перепилить на ЭНУМЫ -https://github.com/nodkz/conf-talks/tree/master/articles/graphql/schema-design#rule-5.2
источник

EP

Ekaterina Pantaz in GraphQL — русскоговорящее сообщество
спасибо) записала, будем улучшаться)
источник

P@

Pavel @nodkz in GraphQL — русскоговорящее сообщество
еще есть Graphql Mesh

оптимальный выбор зависит от конретных ваших задач
невозможно ничего посоветовать не знаю ньюансов
источник

EP

Ekaterina Pantaz in GraphQL — русскоговорящее сообщество
мы выбрали пока схема стичинг вместо федерейшн, так как там не поддерживаются подписки, а у нас есть подписки
источник

EP

Ekaterina Pantaz in GraphQL — русскоговорящее сообщество
но еще не имплементили
источник

EP

Ekaterina Pantaz in GraphQL — русскоговорящее сообщество
ок, посмотрим его тоже
источник

P@

Pavel @nodkz in GraphQL — русскоговорящее сообщество
Подписки боль на бэкенде, даже без стичинга )
источник

EP

Ekaterina Pantaz in GraphQL — русскоговорящее сообщество
да уж, особенно когда они теряют данные при обрыве соединения))
источник