Когда выбирать GraphQL вместо REST, а когда нет?

Question

IT Interview Practice · Accepted Answer

Выбирайте исходя из того, **кто потребляет API и насколько разнообразны их потребности в данных** — а не из хайпа. GraphQL выигрывает, когда множеству разных клиентов нужно самим формировать свои данные; REST выигрывает, когда запросы единообразны, кэшируемы и просты.

## Выбирайте GraphQL, когда

- **Много клиентов с разными потребностями** — web, iOS, Android — каждому нужны разные поля от одних и тех же сущностей. GraphQL устраняет over/under-fetching, так что вам не нужно выпускать новую конечную точку под каждый экран.
- **Глубоко связанные/графоподобные данные** — один запрос обходит связи (`user -> posts -> comments`) вместо N обращений REST.
- **Быстрая продуктовая итерация** — аддитивная эволюция схемы позволяет фронтенд-командам добавлять поля, не дожидаясь новых бэкенд-эндпоинтов или версий.
- **Агрегация микросервисов** — федеративный gateway представляет единый граф над множеством сервисов (паттерн BFF).

## Выбирайте REST, когда

- **Простые, единообразные ресурсы** с предсказуемым доступом — CRUD, где каждому клиенту нужна одна и та же форма.
- **HTTP-кэширование / CDN важнее всего** — модель REST с URL + `GET` тривиально кэшируется на каждом слое; GraphQL нужны persisted queries, чтобы приблизиться.
- **Загрузка/выгрузка файлов, бинарные данные или публичные API**, где выигрывают широкая поддержка инструментов, коды статусов и простота.
- **Небольшая команда / низкая сложность** — серверная цена GraphQL (resolvers, контроль N+1, лимиты стоимости запросов, инструменты схемы) не оправдана ради горстки эндпоинтов.

## Честная таблица компромиссов

| Аспект | GraphQL | REST |
|---|---|---|
| Over/under-fetching | Решено по дизайну | Частая проблема |
| HTTP/CDN-кэширование | Сложно (требует работы) | Нативно и просто |
| Контроль стоимости запросов/DoS | Нужно добавлять самому | Естественно ограничен |
| Гибкость клиента | Высокая | Низкая |
| Сложность сервера | Выше | Ниже |

Они также не взаимоисключающи — многие системы предоставляют REST для публичных/кэшируемых эндпоинтов и GraphQL для богатых внутренних клиентов.

## Почему это важно

Senior-интервьюеры проверяют **суждение, а не преданность**. Сильный ответ называет оси — разнообразие клиентов, потребности в кэшировании, зрелость команды, поверхность DoS — и признаёт реальные издержки GraphQL (кэширование и контроль стоимости запросов), а не продаёт его как универсально лучший.

Аспект	GraphQL	REST
Over/under-fetching	Решено по дизайну	Частая проблема
HTTP/CDN-кэширование	Сложно (требует работы)	Нативно и просто
Контроль стоимости запросов/DoS	Нужно добавлять самому	Естественно ограничен
Гибкость клиента	Высокая	Низкая
Сложность сервера	Выше	Ниже

Выбирайте GraphQL, когда

Выбирайте REST, когда

Честная таблица компромиссов

Почему это важно

Похожие вопросы