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

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

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

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

2 аргумента и 10 плюсиков
за «GraphQL»
4 аргумента и 16 плюсиков
за «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»
В описании батла как раз всё указано:Р

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

🥴

😎

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

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


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