Есть ли у GraphQL недостатки? [закрыто]

101

Все статьи о GraphQL расскажут, насколько он прекрасен, но есть ли в нем недостатки или недостатки? Спасибо.

Доктор Немо
источник

Ответы:

96

Недостатки:

  • Вам нужно узнать, как настроить GraphQL. Экосистема все еще быстро развивается, поэтому вам нужно не отставать.
  • Вам нужно отправлять запросы от клиента, вы можете просто отправлять строки, но если вам нужно больше комфорта и кеширования, вы будете использовать клиентскую библиотеку -> дополнительный код в вашем клиенте
  • Вам необходимо заранее определить схему => дополнительная работа, прежде чем вы получите результаты
  • У вас должна быть конечная точка graphql на вашем сервере => новые библиотеки, которые вы еще не знаете
  • Запросы Graphql занимают больше байтов, чем просто переход к конечной точке REST
  • Серверу необходимо выполнить дополнительную обработку, чтобы проанализировать запрос и проверить параметры.

Но им более чем противостоят:

  • GraphQL не так уж и сложно изучить
  • Дополнительный код составляет всего несколько КБ
  • Определив схему, вы предотвратите гораздо больше работы, после исправления ошибок и длительных обновлений.
  • Многие люди переходят на GraphQL, поэтому развивается богатая экосистема с отличным инструментарием.
  • При использовании постоянных запросов в производстве (заменяя запросы GraphQL просто идентификатором и параметрами) вы фактически отправляете меньше байтов, чем с REST.
  • Дополнительная обработка входящих запросов незначительна
  • Обеспечение четкой развязки API и бэкэнда позволяет значительно ускорить итерацию по улучшениям бэкэнда.
w00t
источник
1
«Вам нужно определить схему заранее => дополнительная работа, прежде чем вы получите результаты» Я не понимаю, как это не нужно без GraphQL? Конечно, для некоторых фреймворков на некоторых языках это не требуется, но, например, для Java API вам все равно придется описывать «схему» в своих моделях.
AntoineB
3
@AntoineB вы правы, но в NodeJS вы можете легко создать REST API, даже не задумываясь об общей схеме; просто верни вещи.
w00t
1
@ w00t, и как только вам понадобятся некоторые параметры с REST, вы прибегнете к синтаксическому анализу URL-адреса и проверке правильности типа параметра, выбрасывая 400, если это не так. Если бы только было что-то, чтобы избежать необходимости делать это вручную в каждом обработчике маршрута: D
Capaj
С помощью Spring Boot вы можете просто вытащить некоторые артефакты graphql-spring-boot-starterи graphql-java-toolsначать работу. Создайте свою схему в ресурсе .graphqls и создайте классы Resolver, и все готово. Чтобы запустить рабочий тестовый пример, потребовалось около 10 минут.
Babyburger
1
Я не согласен со всеми недостатками, на самом деле это сэкономит вам много времени. Посмотрите
Шафкат Али
59

Я обнаружил некоторые важные проблемы для всех, кто рассматривает возможность использования GraphQL , и до сих пор основные моменты:

Запрос с неопределенной глубиной: GraphQL не может выполнять запросы с неопределенной глубиной, поэтому, если у вас есть дерево и вы хотите вернуть ветку, не зная глубины, вам придется выполнить некоторую разбивку на страницы.

Конкретная структура ответа : в GraphQL ответ соответствует форме запроса, поэтому, если вам нужно ответить в очень конкретной структуре, вам придется добавить слой преобразования, чтобы изменить форму ответа.

Кэширование на сетевом уровне : из-за того, что GraphQL обычно используется через HTTP (POST в одной конечной точке), кеширование на сетевом уровне становится затруднительным. Решить эту проблему можно с помощью постоянных запросов.

Обработка загрузки файла : в спецификации GraphQL ничего не говорится о загрузке файлов, а мутации не принимают файлы в аргументах. Чтобы решить эту проблему, вы можете загружать файлы с помощью других типов API (например, REST) ​​и передавать URL-адрес загруженного файла в мутацию GraphQL или внедрять файл в контекст выполнения, чтобы у вас был файл внутри функций преобразователя.

Непредсказуемое выполнение : природа GraphQL заключается в том, что вы можете запрашивать, комбинируя любые поля, которые хотите, но эта гибкость не бесплатна. Есть некоторые проблемы, о которых полезно знать, например, производительность и запросы N + 1.

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

Бруно Соарес
источник
2
Для неопределенной глубины я прибегаю к ответам JsonType. Он не строго типизирован, поэтому вам нужно проверять вводимые данные, но это может быть очень удобно.
w00t 02
3
У REST всегда была проблема с запросами N + 1. Единственное отличие состоит в том, что REST не позволяет серверной части даже пытаться решить проблему. Вместо этого он выталкивает проблему на интерфейс.
Capaj 02
40

Самая большая проблема, которую я вижу с graphQL, т.е. если вы используете реляционную базу данных, связана с объединениями .

  1. Тот факт, что вы можете разрешить / запретить несколько полей, делает объединение нетривиальным (не простым). Это приводит к лишним запросам.

  2. Также вложенные запросы в graphql приводят к циклическим запросам и могут привести к сбою сервера . Следует проявлять особую осторожность.

  3. Ограничение скорости вызовов становится затруднительным, поскольку теперь пользователь может запускать несколько запросов за один вызов.

СОВЕТ : используйте загрузчик данных facebook, чтобы уменьшить количество запросов в случае javascript / node

aWebDeveloper
источник
1. Как выбранные поля имеют отношение к операциям соединения? 2. Нет, если вы используете загрузчик данных. 3. Можно разобрать и назначить costзапрос. Также это не проблема, если вы используете предопределенные запросы, когда клиент отправляет только идентификатор.
zoran404
1
согласен с 2. С 3 это немного лишняя работа и, что более важно, люди должны знать.
aWebDeveloper
1
2. Это больше не так, поскольку вы можете использовать множество инструментов для защиты своего сервера. Например, ссылка: howtographql.com/advanced/4-security Тайм-ауты, ограничение сложности и глубины. Это похоже на то, как вы говорите, что ваш REST будет доступен для DDoS-атак, если вы не будете использовать ограничитель скорости. Все изменилось
Евгений Герасимчук
обновлено: пункт 2
aWebDeveloper,
14

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

  • Кэширование на уровне сети - как сказал Бруно, это постоянные запросы, и, конечно же, вы можете кэшировать на клиенте, и никто не мешает вам использовать кеширование на уровне базы данных или даже Redis. Но, конечно же, поскольку GraphQL имеет только одну конечную точку и каждый запрос отличается, этот тип кэширования намного сложнее, чем с REST.
  • Вложенные запросы в GraphQL приводят к циклическим запросам и могут привести к сбою сервера - больше не проблема с огромным разнообразием решений. Некоторые из них перечислены здесь
  • Обработка файлов для загрузки - мы уже много из решений для него

Но есть еще пара случаев, которые можно отнести к минусам:

  • шаблонная избыточность (я имею в виду, что для создания, например, нового запроса вам необходимо определить схему, преобразователь и внутри преобразователя, чтобы явно указать GraphQL, как разрешать ваши данные и поля внутри, на стороне клиента создать запрос с точно полями, относящимися к эти данные)
  • обработка ошибок - я должен сказать, что это больше связано с сравнением с REST. Здесь с apollo возможно, но в то же время это намного сложнее, чем в REST
  • аутентификации и авторизация - нокак я сказалсообщество растут с исключительной скоростью и есть уже пара из решений для этой цели.

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

Евгений Герасимчук
источник
4

Действительно здорово иметь единую конечную точку и предоставлять все данные. Я нахожу следующие моменты, которые следует учитывать для GraphQL:

  1. Осуществление загрузки / выгрузки файла становится сложным (преобразование в строку может быть не лучшим вариантом для больших файлов)
  2. Много шаблонного кода и кода схемы как во фронтенде, так и в бэкэнде.
  3. Следуйте и поддерживайте разбиение на страницы, предусмотренное в спецификации GraphQL.
  4. Разрешить настраиваемый порядок и логику приоритезации полей. Пример получения данных пользователей и связанных групп и ролей. Пользователь может выполнять множественную сортировку данных по имени пользователя, имени группы или имени роли.
  5. Аутентификация и авторизация будут зависеть от внутренней структуры.
  6. Обеспечение внутренней оптимизации и поддержки базы данных для запуска одного запроса для каждой команды graphql может стать сложной задачей.

Также следует учитывать плюсы после его реализации:

  1. Очень гибкий для поддержки новых элементов и обновления существующего поведения.
  2. Легко добавлять условия с помощью аргументов и настраиваемого порядка после реализации

  3. Используйте множество настраиваемых фильтров и избавьтесь от всех действий, которые необходимо создать, например, пользователь может иметь идентификатор, имя и т. Д. В качестве аргументов и выполнять фильтрацию. Кроме того, фильтры могут применяться к группам пользователей.

  4. Легкость тестирования API за счет создания файлов, содержащих все запросы и мутации GraphQL.
  5. Мутации просты и их легко реализовать после понимания концепции.
  6. Мощный способ получения данных различной глубины.
  7. Поддержка Voyager и GraphiQL UI или Playground упрощает просмотр и использование.
  8. Легкость документации при определении схемы с допустимыми методами описания.
vCillusion
источник
3

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

user998548
источник