REST — зрелый и понятный подход. При грамотной реализации можно получить хорошее кеширование почти бесплатно. Также в арсенале рестовиков все приблуды протокола HTTP.
GraphQL же манит возможность легко запрашивать нужные тебе данные. Не нужно ждать когда бекендеры сделают ручку поудобнее, не нужно на клиенте делать склейку запросов. Всякие взрослые большие дяденьки типа Гитхаба делают у себя GraphQL апишки.
Когда имеет смысл применять одну технологию, а когда — другую? Насколько дорого поддерживать GraphQL сервер?
за «GraphQL»
за «REST»
В каждом проекте я начинаю с GraphQL и в каждом проекте либо сожалею, либо перехожу назад на рест. Моя цель всегда — это написать как можно меньше кода, чтобы все работало и работало безопасно. На GraphQL хеллоуворлды короче, да.
Но когда подключаешь контроль доступов и тучу разных миддлварь, начинается ад и паттерны из REST, которые в GraphQL становятся костылями. Ни один мой сервер на GraphQL даже близко не стоит по лаконичности с другим моим любимым стаком.
Основная претензия к GraphQL то что он декларативен как SQL в итоге по уму он должен поддерживаться как диалект внутри СУБД. Чего в данный момент не наблюдаем.
А реализовывать его через какие-то магические либы которые фактически оборачивают REST в GraphQL ну такое.
Без них же сложность написания backend превращается в сложность равная написать СУБД с поддержкой SQL.
REST в целом более универсальный и гибкий инструмент по сравнению с GQL. На ресте можно построить всю коммуникацию сервисов в большой системе и будет ок. На GQL это тоже можно сделать, но поддержка этого счастья начинает становиться проблемой.
Когда у тебя апи продиктовано сервером, то ты можешь его обновить просто обновив сервер. Когда у тебя апи типизировано тебе становится нужно синхронизировать схему сервера с схемой клиента, даже когда этого не требует бизнес-логика приложения.
Когда у тебя нет типов, прокинуть данные через несколько сервисов довольно легко. Когда у тебя GQL, у тебя начинаются пляски с синхронизацией этих сервисов.
Кто-нибудь, впрочем, скажет что это ок.
Если не брать сферический вакуумный случай, а решать конкретную задачу: приложение с большим количеством взаимодействия на экране у пользователя (управление состоянием), которое должно постоянно синхронизироваться с бекендом (мутации и подписки), при этом быть отзывчивым (опять таки управление состоянием и optimistic response). Представьте себе условную рисовалку с поддержкой одновременной работы нескольких пользователей над одной картинкой. То вытягивать и держать в памяти сложные структуры гораздо удобнее graphql’ем. Сейчас используем Apollo client, что позволило отказаться от redux + поделок для транспорта и разруливания конфликтов, кеширования и т.п.
P.S В современном мире http кеширование не нужно, если это не статика. Частые запросы кешируются на уровне приложения, БД.
P.P.S Rest Спокойно живет рядом с graphql , не вижу ни одной вменяемой причины полностью отказываться от одного в пользу другого.
Ну вот реально не вижу действительно весомых причин, чтобы бросаться юзать хипстеркий GraphQL, даже вот Злые Марсиане меня не убедили