Есть ли недостатки в GraphQL?

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

+71
19 нояб. '16 в 6:19
источник поделиться
5 ответов

Недостатки:

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

Но это более чем противопоказано:

  • GraphQL не так сложно узнать
  • Дополнительный код всего несколько килобайт
  • Определяя схему, вы предотвратите гораздо больше работы после исправления ошибок и прочного волосатого обновления
  • Есть много людей, переключающихся на GraphQL, поэтому существует развитая богатая экосистема, с отличным оснащением
  • При использовании постоянных запросов в процессе производства (заменяя запросы GraphQL просто идентификатором и параметрами) вы отправляете меньше байтов, чем с помощью REST
  • Дополнительная обработка входящих запросов незначительна
  • Предоставление чистой развязки API и бэкэнд позволяет значительно ускорить итерацию при улучшении бэкэнда
+67
19 нояб. '16 в 10:47
источник

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

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

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

Кэш на уровне сети. Из-за того, что GraphQL используется по протоколу HTTP (POST в одной конечной точке), кеш на сетевом уровне становится сложным. Способ решения проблемы - использовать Persisted Queries.

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

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

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

+40
07 авг. '17 в 2:09
источник

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

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

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

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

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

+28
07 апр. '17 в 9:05
источник

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

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

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

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

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

+8
10 дек. '18 в 19:56
источник

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

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

Также стоит рассмотреть плюсы после его реализации:

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

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

  4. Простота тестирования API благодаря созданию файлов, содержащих все запросы и мутации GraphQL.
  5. Мутации просты и легко реализуемы после понимания концепции.
  6. Мощный способ извлечения нескольких глубин данных.
  7. Поддержка Voyager и GraphiQL UI или Playground позволяет легко просматривать и использовать.
  8. Простота документирования при определении схемы с допустимыми методами описания.
0
27 июн. '19 в 18:38
источник

Посмотрите другие вопросы по меткам или Задайте вопрос