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

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

Ответ 1

Недостатки:

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

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

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

Тот факт, что вы можете разрешить/запретить несколько полей, делает соединения нетривиальными (не простыми). Что приводит к дополнительным запросам.
Также вложенные запросы в graphql приводят к циклическим запросам и могут привести к сбою сервера. Особое внимание должно быть уделено.
Ограничение скорости звонков становится затруднительным, поскольку теперь пользователь может запускать несколько запросов за один звонок.

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

Очень гибкий для поддержки новых предметов и обновления существующего поведения.
Легко добавлять условия, используя аргументы и настраиваемый порядок после внедрения
Используйте множество пользовательских фильтров и избавьтесь от всех действий, которые необходимо создать. Например, пользователь может иметь в качестве аргументов идентификатор, имя и т.д. И выполнять фильтрацию. Кроме того, фильтры могут применяться к группам пользователей.
Простота тестирования API благодаря созданию файлов, содержащих все запросы и мутации GraphQL.
Мутации просты и легко реализуемы после понимания концепции.
Мощный способ извлечения нескольких глубин данных.
Поддержка Voyager и GraphiQL UI или Playground позволяет легко просматривать и использовать.
Простота документирования при определении схемы с допустимыми методами описания.

Ответ 6

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