И сразу контр аргумент, если вас будут тыкать в эту статью:

С REST API фронтендеры пишут кучу бойлерплейта для получения связанных данных между ресурсами.

О связях хорошо знают бэкендеры, но не фронтендеры.

Концептуальная разница GraphQL и REST API в том, что логику получения связанных ресурсов перенесли с клиента на сервер.

Tl DR в графе есть проблемы, но их решили в аполо, но осадочек остался

интересно понять https://github.com/grpc/grpc-web vs graphql

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

json api и прочие "стандарты" включали в себя работу с релейшенами примерно тогда когда фэйсбук начинал работу над своим graphql.

p.s. твой графикьюэль уже научился в мэпы со связями?

последнее это про бойлерплейт - его и в graphql в целом хватает для специфичных ситуаций. Да и бойлерплейт прячется неплохо.

А вот стоимость внедрения какой-то штуки может сильно привышать стоимость. Это больше про cost/benifit анализ в который мало кто умеет сегодня... балом правит хайп и непрофессианализм.

p.s. на всякий случай - мне graphql нравится просто надо на вещи реально как-то смотреть. А то выглядит как "смотрите. наконецта серебрянная пуля"

контракты - gprc лучше. Возможность композиции данных под UI - graphql лучше.

Поэтому бизнес должен быть готов тратиться на R&D. Солюшн архитектор может сходу и знать ответ на вопрос "а оно нам надо вообще?"

По моему опыту gql при правильном использовании несёт в себе профит даже в проектах, которые чуть больше банального интернет-магазина.

А если бизнес имеет привычку менять требования каждую неделю, то gql позволит не плодить кучу эндпоинтов, в которых потом черт ногу сломит

Насчет черт ногу сломит - вобще спорно,в графе ногу сломать можно с той-же легкостью подстраиваясь под внезапные изменения

Я сейчас работаю с кучей легаси-эндпоинтов, а когда нужен новый:
1. Я тыкаю бэкендера
2. Он ворчит и говорит юзать старые, либо делать несколько последовательных запросов
3. С вероятностью 50% пишет новый эндпоинт

К тому же постоянно страдаем от оверфетчинга. На b2b-платформе это не страшно, но когда доходит до обычных клиентов, может тянуться несколько десятков кб лишнего json'а

С последовательными запросами для связанных данных

Очень знакомая ситуация, наш свагер тоже попахивал ) В графе ногу сломать в не эндпоиниах а в реализации некоторых хитроумных выкрутасов на стороне бекенда дабы сделать то что схема изначально не предпологала

Я сейчас не ругаю граф, я о том что он хорошо справляется с постоянными внезапными переделками бизнес логики не всегда, имхо

Схема имеет гибкость только в ширину

То покажите в ответ комментарии под оригинальным постом...

graphql/express-graphql v0.6.12 → v0.7.0 🎉

graphql/express-graphql v0.7.0 → v0.7.1 🎉

Ребят, а есть какой-то инструмент чтобы из модели генерировать typeDefs по типу как это делает prisma deploy?
Типа, я описал все модели (User, Cart, News) а он мне сгенерирует всевозможные вариации create, delete, update, query.