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

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

Недостатки:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Легко добавлять условия с помощью аргументов и настраиваемого порядка после реализации

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

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

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