это ты еще не замерял скорость отдачи реста и графа, для одного и того же набора данных)

если че я за граф, просто обьективный коммент)

блять

бот банит сообщения 🙁

как объяснить боту, что я не спамер?)

Абсолютно поддерживаю. Но и перформит граф лучше

Какой результат?)

А что там со скоростями?

ну рест быстрее у меня был)

The main GraphQL quality is being less loquacious than REST API. GraphQL treats performance as its top priority while REST is focused on keeping services reliability as their main objective. Even if a REST API returns only a basic partial, it is still transferring more data, while GraphQL is always aiming for the smallest possible request. In an example, if the client needs a field, they request it, and if the API adds a new field, clients don't get it, unless it's being added into the GraphQL query.

Вот что почитал
Вроде звучит логично

Не почувствовал у себя на проекте

Единственное что классно это автоматическое кеширование и интерфейс /graphql
Что заменяется на react-query и swagger

/trust

Так смысл не в одном и том же запросе , а в том , что ты можешь сделать выборку и не тянуть все сразу , тогда будет быстрее

Вопрос:
Насчет удаленного стейта (серверных данных). Нужно ли их подымать как можно выше или как можно ниже. Скажем у меня есть 2 компонента - таблица и дешборда с метриками таблицы. Как лучше:
1) получить с верху все данные для таблицы и посчитать данные для дешборда и отобразить.
2) или лучше таблица запрашивает с сервера данные для себя и отображает. А дешборда запрашивает свои данные из сервера и отображает.
То есть вопрос: стоит удаленный стейт подымать или оставлять в каждой компоненте? Таблица может еще и изменять данные на сервере.

Наверное ответ - надо поднять вверх запрос.

А теперь вопрос с graphql subscriptions:
а что если оба компонета получают данные через subscription, каждый для себя. Стоит ли подымать с subscriptions наверх? Или оставить их внутри каждого компонета?

Привет всем, извините за крайне странный вопрос, но, что сейчас модно использовать relay или apollo client?
Недавно посмотрел выступление по этим технологиям, где говориться что relay решение получше,  но не популярный т.к сложный, с apollo наоборот - легче, и вот у меня вопрос, тот доклад 2019 года, много чего изменилось после этого?
и что сейчас модно использовать relay с фрагментным подходом, или появились решение получше?

Сейчас вроде react-query популярно(там есть gql), но я не вдавался в подробности пока что

Привет, чат!
Может кто-то рассказать как решает проблему отстояной спецификации graphql относительно nullability и undefinability полей?
https://github.com/graphql/graphql-spec/issues/476
https://github.com/graphql/graphql-spec/issues/542

Думаю, что в issue все можно прочитать, но кратко повторюсь тут.
Опциональность полей может означать:
* Что поле можно не передавать или обнулить его значение при помощи null
* Что поле можно не передавать, но нельзя обнулить
* Что поле должно быть обязательно передано, но может быть обнулено

Интересует полная картина решения проблемы как со стороны бэкенда, так и на фронтенде

Проблема серьезная и непонятно, как люди пользуются graphql в больших проектах, если спецификация не доработана даже в такой мелочи

Есть такой прикол - postgraphille - делает из постгрес graphqlAPI
Кто-то юзал?