Comments 8
Странно, что вы, как бекендер, не упомянули о переносе вычислительной сложности использования GraphQL с фронтенда на бекенд. Например, хотя бы, как решать проблему глубоко вложенных запросов.
Возможно, стоило упомянуть, спасибо!
Почему-то мне это показалось само собой разумеющимся, ведь со стороны фронтенда необходимо лишь сформировать запрос по схеме, указав все необходимые для получения данные.
А дальше уже со стороны бэкенда они уже будут собраны через механизм резолверов.
Вы правы. Почему-то большая часть статей о graphql обходят этот вопрос. Помимо оптимизации глубоко вложенных запросов, есть также проблема глубины как таковой, так как object типы могут ссылаться циклически друг на друга (если так задать схему), то тем самым можно запросто положить сервер. У себя решили это просто собрав все запрашиваемые клиентами пути путем логирования, а потом все, что не в списке, то отбрасываем. Complexity тут не особо помогает тоже, так как сложно понимать что и насколько оценивать. Глубоко вложенные структуры в рамках одного сервиса можно оптимизировать, отображая схему запроса на eager или lazy отношения в orm, ну или как кому удобнее. Проблема N+1 может быть решена с помощью data loader (в federation схеме к примеру), но опять же смотреть надо что и как запрашивается. Оффтоп, но механизм upload в некотором роде просто приставка сбоку, и не рекомендуется аполло. У себя сделали просто отдельный рест для загрузок файлов, а в сервис передаем айди загрузки.
Непонятно почему нет ещё двух протоколов, которые тоже базируются на HTTP - SOAP и JSONRPC. Эволюция схемы GraphQL это недостаток, поэтому некоторые компании его версионируют как и REST. Ничего не сказано про заголовки, кеширование, асинхронные запросы. Очень поверхностная статья, которая может ввести в заблуждение. Порекомендую бесплатную книжку про API https://twirl.github.io/The-API-Book/API.ru.html
+ не затронута тема кеширования
В высоконагруженных системах очень тяжело будет управлять всей этой системой. Настройка рейт лимитеров, сценарии аварийного отключения АПИ, выше уже писали про кеширование и иерархические запросы. По мне так 5 отдельных рест запросов это меньшая из проблем.
Я конечно понимаю, что вы очень влюблены в gql, но всё же не надо так прям ванильно маркетингом заниматься. Пройдёмся по фактам:
POST - что насчёт HTTP-кеширования? Приходится самим всё организовывать. Это больно. Никакой proxy не сможет это делать безболезненно.
В случае REST API потребовалась бы серия запросов
Мало того, что это прям 100% неправда, потому что нет такого ограничения, чтобы нельзя было на детальную запись навесить вес набор данных, так и организовать серию запросов при наличии хорошего кеширования вообще не проблема. Публичные данные будут кешироваться на прокси между пользователями, приватные - кешироваться только для пользователей. В общем всё зависит от задачи и можно легко манипулировать данными так, чтобы получить лучший результат.
GraphQL позволяет клиентам запрашивать только нужные данные, избегая избыточного или недостаточного получения. Это повышает эффективность сетевых запросов: передаются только необходимые данные.
Условный PostgREST для вас шутка какая-то? Вы можете запросить любой набор полей, при этом работают все преимущества HTTP GET-запросов.
А я упоминал про заголовки? Да, через них можно тоже много чего делать и это будет вполне согласовано с REST. Есть даже замечательный стандарт ETag в купе с If-None-Match и If-Match, чтоб работать с консистентными данными в запросе. Такое к gql прикрутить довольно сложно, а без этого работать - довольно глупо с большой нагрузкой на сервер.
Graphql, тем не менее хорошая технология, если наплевать на имеющиеся стандарты и изобретать велосипед или в тех случаях, когда запросы на 90% уникальные для пользователей: хранить и восстанавливать стейт на клиенте, делать кастомную валидацию кеша, мапить действия со стейтом в бэкенд, когда источников данных больше чем самих данных и никакой структуры этих данных нет и не предвидится.
Я это всё к чему... Прежде чем сравнивать какие-то стандарты, имеет смысл хотя бы в них разбираться, иметь реальный список pros-cons, не говоря уже о том, чтобы разбираться в истории и причинах создания оных. Я понимаю такие статьи в 2015-2017 годах, когда была волна хайпа вокруг gql и redux, просто потому что ещё никто толком не знал про него. Но сейчас, когда уже многие обломали себе пальцы об него, может хватит? Может лучше начать нормально учиться в архитектуру в эпоху вайбкодинга?
GraphQL или REST: Какой API выбрать, чтобы не прогадать?