GraphQL
или
REST
 Публичный пост    13 мая 2020  302

REST — зрелый и понятный подход. При грамотной реализации можно получить хорошее кеширование почти бесплатно. Также в арсенале рестовиков все приблуды протокола HTTP.

GraphQL же манит возможность легко запрашивать нужные тебе данные. Не нужно ждать когда бекендеры сделают ручку поудобнее, не нужно на клиенте делать склейку запросов. Всякие взрослые большие дяденьки типа Гитхаба делают у себя GraphQL апишки.

Когда имеет смысл применять одну технологию, а когда — другую? Насколько дорого поддерживать GraphQL сервер?

2 аргумента и 10 плюсиков
за «GraphQL»
4 аргумента и 14 плюсиков
за «REST»
за «GraphQL»
При грамотной реализации можно получить привычные REST–плюшки и кое–что еще
  • при грамотной реализации GraphQL можно тоже получить хорошее кеширование 🙂 (стоит отметить, что возня с кэшем в обоих подходах часто завязана на логику приложения, так что поработать напильником так или иначе придется)
  • можно не только запрашивать только нужные данные, но еще и не запрашивать не нужные, а при должной сноровке — в БД за ними не ходить, благо доступ к списку требуемых полей есть
  • хоть GraphQL и позиционируется как transport-agnostic, он обычно таки работает поверх HTTP, так что завести "все приблуды протокола HTTP" всегда можно
  • GraphQL всегда имеет схему, поэтому из коробки (не надо ничего рядом ставить, никаких сваггеров) есть актуальная документация, валидация запросов и проверка типов
  • в стандарте есть механизм подписок, а значит, если он реализован для вашего стека — все будет работать из коробки (опять же, рядом ставить ничего не придется)
за «REST»

В каждом проекте я начинаю с GraphQL и в каждом проекте либо сожалею, либо перехожу назад на рест. Моя цель всегда — это написать как можно меньше кода, чтобы все работало и работало безопасно. На GraphQL хеллоуворлды короче, да.

Но когда подключаешь контроль доступов и тучу разных миддлварь, начинается ад и паттерны из REST, которые в GraphQL становятся костылями. Ни один мой сервер на GraphQL даже близко не стоит по лаконичности с другим моим любимым стаком.

за «REST»
GraphQL сырая хипстерская поделка

Основная претензия к GraphQL то что он декларативен как SQL в итоге по уму он должен поддерживаться как диалект внутри СУБД. Чего в данный момент не наблюдаем.
А реализовывать его через какие-то магические либы которые фактически оборачивают REST в GraphQL ну такое.
Без них же сложность написания backend превращается в сложность равная написать СУБД с поддержкой SQL.

за «GraphQL»
Интеграция с фронтендом

Если не брать сферический вакуумный случай, а решать конкретную задачу: приложение с большим количеством взаимодействия на экране у пользователя (управление состоянием), которое должно постоянно синхронизироваться с бекендом (мутации и подписки), при этом быть отзывчивым (опять таки управление состоянием и optimistic response). Представьте себе условную рисовалку с поддержкой одновременной работы нескольких пользователей над одной картинкой. То вытягивать и держать в памяти сложные структуры гораздо удобнее graphql’ем. Сейчас используем Apollo client, что позволило отказаться от redux + поделок для транспорта и разруливания конфликтов, кеширования и т.п.

P.S В современном мире http кеширование не нужно, если это не статика. Частые запросы кешируются на уровне приложения, БД.

P.P.S Rest Спокойно живет рядом с graphql , не вижу ни одной вменяемой причины полностью отказываться от одного в пользу другого.

за «REST»
Типизация иногда мешает

REST в целом более универсальный и гибкий инструмент по сравнению с GQL. На ресте можно построить всю коммуникацию сервисов в большой системе и будет ок. На GQL это тоже можно сделать, но поддержка этого счастья начинает становиться проблемой.

Когда у тебя апи продиктовано сервером, то ты можешь его обновить просто обновив сервер. Когда у тебя апи типизировано тебе становится нужно синхронизировать схему сервера с схемой клиента, даже когда этого не требует бизнес-логика приложения.

Когда у тебя нет типов, прокинуть данные через несколько сервисов довольно легко. Когда у тебя GQL, у тебя начинаются пляски с синхронизацией этих сервисов.

Кто-нибудь, впрочем, скажет что это ок.

за «REST»
В описании батла как раз всё указано:Р

Ну вот реально не вижу действительно весомых причин, чтобы бросаться юзать хипстеркий GraphQL, даже вот Злые Марсиане меня не убедили

🥴

Этикет батлов:
  • 💣 Батл — это схватка двух крайностей. Мы пытаемся выделить аргументы каждой из сторон чтобы потом по ним составить свою картину мира. Рекомендуется избегать аргументов типа «каждый хорош для своего».
  • ☝️ Один аргумент — один комментарий. Не делайте списков, так сложнее вести дискуссию и подсчитывать статистику.
  • 😎 Можно топить как за одну, так и за обе стороны сразу. Просто выберите за кого вы при постинге.
  • 💬 На аргументы можно отвечать. Реплаи никуда не засчитываются и нужны только для срача.
  • 👮‍♀️ Авторам батлов нужно удалять повторы и комментарии не по формату.

😎

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

Что вообще здесь происходит?


Войти  или  Вступить в Клуб