Гайды

GraphQL vs REST: когда что лучше

Матрица кэша и версий, BFF, безопасность и rate limit, компромиссы для публичного и внутреннего API.

~8 мин чтения

GraphQL vs REST: когда что лучше

REST — ресурсы и HTTP-методы; GraphQL — одна точка входа и декларативный запрос дерева. Оба валидны; выбор зависит от клиентов, команды и нагрузки. Детали GraphQL — Основы GraphQL: схема и резолверы; REST-дизайн — HATEOAS и версионирование; контракты — OpenAPI и генерация клиентов.


1. Краткая матрица

КритерийGraphQLREST
Гранулярность полейКлиент сам выбирает поляЧасто «фиксированные» DTO или over/under-fetch
Кэширование HTTPСложнее (POST + тело)Естественно GET + URL
ВерсионированиеСхема, deprecated поляURL /v2/, заголовки
ИнструментыPlayground, Apollo StudioOpenAPI, Swagger — см. документация в FastAPI
Серверная сложностьDataLoader, лимиты, N+1Проще для простых CRUD

2. Когда GraphQL уместен

  1. Много клиентов (web, mobile, партнёры) с разными наборами полей.
  2. Сложные агрегированные экраны без лавины специализированных REST-эндпоинтов.
  3. Команда готова инвестировать в производительность и безопасность схемы.

3. Когда REST (или гибрид) проще

  1. Кэш на CDN/прокси по GET критичен.
  2. Загрузка файлов, бинарные потоки, простые вебхуки.
  3. Команда маленькая, домен — классический CRUD.

Частый компромисс: REST для публичного API и файлов, GraphQL для внутреннего BFF (Backend for Frontend).


4. BFF-паттерн

Отдельный GraphQL-слой перед микросервисами собирает данные для фронта, не заменяя внутренние REST/gRPC между сервисами.


5. Безопасность

GraphQL — один URL; rate limiting и query cost обязательны. REST проще режет по path+method в WAF.

Persisted queries (хэш запроса вместо произвольного тела) и APQ (Automatic Persisted Queries) уменьшают поверхность атаки и помогают кэшировать на CDN для GET-запросов с queryId — компромисс между гибкостью ad-hoc GraphQL и предсказуемостью для edge.


6. Решение

Зафиксируйте требования к кэшу, типизации клиентов, команде и наблюдаемости. Не внедряйте GraphQL «ради моды» без инженеров, которые чинят N+1.


7. Пагинация и лимиты

Relay connections (first/after) или лимиты глубины/количества полей в query complexity плагинах — иначе один запрос может положить БД. Для публичного API документируйте дефолтные лимиты и коды ошибок.


8. Наблюдаемость

Логируйте operationName (не только в dev), разделяйте ошибки резолверов и транспорта. Трассировка — OpenTelemetry; корреляция с логами по trace_id.


9. Миграции схемы

@deprecated с reason и сроком, schema registry в CI (graphql-inspector, Spectral). Для мобильных клиентов планируйте долгий хвост старых версий приложения.


Дальше: REST: принципы и версии · тег GraphQL