Между Строк Требований|Блог системного аналитика

Размышления о GraphQL

Сегодня снова об интеграциях: подавляющее большинство интеграций в современных ИТ-продуктах и сервисах реализовано с использованием REST-подхода (мысли про который как раз писал в предыдущем посте). Однако не смотря на популярность этого архитектурного стиля, все равно не получится закрыть глаза на явные недостатки в виде over-fetching и under-fetching (иными словами избыточное и недостаточное извлечение данных), на которые я в том числе планирую сегодня ворчать.
Long Story Short: в очередной раз при проектировании сервиса и проработке его интеграций, когда понадобилось подключиться к другому нашему МС по готовому методу, возникли вот эти раздражающие мысли из серии "Мы сделаем 10 запросов к сервису, чтобы получить две нужные строчки на экран, но при этом получим кучу данных, которые нам, собственно, и не нужны". Так мне и пришла идея сделать ход конем — ~~вкрутить саморезы гаечным ключом~~ "А давайте замутим новую интеграцию через GraphQL 💻 и будем забирать только то, что нам нужно одним запросом!"
GraphQL для меня, как Биткоин. 💰 Он такой стильный, современный, все говорят, что за ним будущее, что вот-вот и фиатные деньги будут заменены им, ведь это удобно, децентрализованно и безопасно, но по факту реально расплатиться им ты можешь только в каком-нибудь Эквадоре, да и то при условии, что тебя после этого не подстрелят. Также и GraphQL — вроде что-то на прогрессивном и современном, но по данным на 2022 год (сорян, актуальнее данные ~~не нашел~~ не искал) подход используется всего-лишь в 0,4% сайтов. Почему так?

Пример полностью вымышленный, но похож на мой кейс (проект связан с парковками и видеонаблюдением):
GET /parkings/{parking_id} — тут получаем информацию по парковке, состоящую из огромного JSONа, 💻 берем отсюда только ID в системе Моспаркинга, все остальные данные нам не нужны;
GET /parkings/{parking_id}/address — тут получаем адрес.

С GraphQL это выглядело бы так:

query {
  parking(id: parking_id) {
    mospark_id
    email
    address {
      city
      street
      building
    }
  }
}

В целом нормально, можно использовать: минимальное количество запросов к API, только необходимый набор данных. 💻 Тем не менее, могут возникнуть следующие сложности:

⚠️Один запрос на GraphQL может породить десятки SQL-запросов, если не использовать DataLoader. В REST эта проблема часто менее выражена, так как с предсказуемыми эндпоинтами он проще в управлении нагрузкой. Не надо одним запросом GraphQL дергать сотню полей с пятью уровнями вложенности... 🙏
⚠️Кэшировать GET-запросы по URL в REST легко. Кэшировать уникальные GraphQL-запросы на уровне HTTP — сложно. Для этого потребуются дополнительные инструменты, тот же DataLoader, например.

Собственно, GraphQL полезен в следующих кейсах 📈:
✅Много разных клиентов (мобильное приложение, веб, smart-TV) с разными потребностями.
✅Данные сильно связаны, и клиенту нужна гибкость в их получении.
✅Скорость разработки на клиенте критически важна (фронтенд может сам собирать свои данные).

Когда лучше выбрать что-то другое 📉:
🚩В случае простого CRUD-сервиса без сложных связей.
🚩Производительность и кэширование — главный приоритет, а команда не готова к сложностям.
🚩Нужны простые и стандартные мониторинг и логирование.

Возвращаясь к кейсу, который натолкнул меня на мысль начать использовать GraphQL на проекте, там в итоге было принято решение использовать REST, но по другим причинам: там планируется миграция сервиса с 🥲 на 💻, поэтому пока отказались от новых подходов.

Зафиналим философским выводом: GraphQL — это не «лучшая версия REST», а принципиально другой инструмент для других задач.

#GRAPHQL #API #HTTP #интеграция

Please open Telegram to view this post