GraphQL или REST: что выбрать для нового API в 2026 году

Каждый раз, когда я начинаю новый проект, всплывает один и тот же вопрос: REST или GraphQL? Ответ зависит не от моды, а от трёх вещей — кто будет потреблять API, насколько часто меняется модель данных и как устроена команда. Разберу это на примерах.

Чем GraphQL отличается на пальцах

REST: один эндпоинт = одна сущность. GET /users/42, GET /users/42/orders, GET /users/42/profile — три запроса, три ответа.

GraphQL: один эндпоинт /graphql, клиент сам пишет, что хочет получить.

query {
  user(id: 42) {
    name
    profile { avatar }
    orders(last: 5) { id total status }
  }
}

Один запрос, один ответ, ровно те поля, которые нужны. Звучит как панацея — но за это платится сложностью на бэкенде.

Где REST остаётся сильнее

REST хорош там, где:

• API простое и стабильное. 5-10 эндпоинтов на CRUD — на REST это 100 строк DRF-кода и понятная документация.
• Один тип клиента. Если у вас только мобильное приложение, и команда фронта/мобайла одна, GraphQL не даст преимуществ — все эндпоинты заточены под их экраны.
• HTTP-кеширование критично. REST идеально работает с CDN: Cache-Control: max-age=3600 на /api/products/popular снимает 80% нагрузки. С GraphQL это сложнее (один эндпоинт /graphql для всех запросов).
• Команда без опыта GraphQL. REST понятен любому за 10 минут. GraphQL требует освоить язык запросов, схему, резолверы, DataLoader.

Где GraphQL действительно решает

В моём проекте Diamond Pharm я использовал GraphQL — и это был правильный выбор. Причина: B2B-витрина с 60+ категориями, разными карточками товаров, динамическими полями для каждой категории. Если бы делал на REST — пришлось бы либо плодить эндпоинты под каждую страницу, либо отдавать тяжёлые ответы со всеми полями «на всякий случай».

С GraphQL фронтенд просит ровно те поля, которые показывает на конкретной странице. Карточка в каталоге берёт name + price + thumbnail. Детальная страница — name + 30 полей характеристик + 5 фото. Один тот же эндпоинт, две разные query.

GraphQL хорош когда:

• Клиентов много и разные потребности. Web-каталог хочет 5 полей, мобильное приложение — 3, агентский кабинет — 15. Все обслуживаются одним API без оверфетча.
• Модель данных активно эволюционирует. Новое поле — добавил в схему, фронт сам решает использовать или нет. В REST новое поле = новый эндпоинт или версия API.
• Сложные связные данные. «Пользователь со списком заказов и статусами доставки и треккерами курьеров» — на REST это 4-5 запросов с N+1, на GraphQL один.
• Нужна типобезопасность по обе стороны. Codegen из схемы выдаёт типизированные TypeScript-типы для фронта и Pydantic-модели для бэка.

Цена GraphQL — что обычно недооценивают

Это не бесплатная замена REST. Скрытые расходы:

N+1 проблема становится больше. Резолвер для user.orders вызывается N раз вместо одного. Без DataLoader/aiodataloader на каждом проекте — производительность утопает.

Кеширование сложнее. Стандартное HTTP-кеширование не работает (запросы — POST на один URL). Нужны специализированные решения (Apollo, urql, persisted queries).

Безопасность глубже. Любой клиент может запросить query с глубиной 100 — DoS на ровном месте. Нужно ограничивать depth/complexity.

Отладка сложнее. В REST «GET /users/42» можно открыть в браузере. В GraphQL для воспроизведения нужен playground или коллекция в Postman.

Rate-limiting не на путях. Стандартный «100 запросов в минуту на IP» работает по-другому — нужна оценка стоимости каждой query.

Гибридный подход: используем оба

В реальных проектах я часто беру оба:

• REST — для публичных API, вебхуков, интеграций с третьими сторонами, OAuth-эндпоинтов, файлового аплоада
• GraphQL — для собственного фронтенда, мобильного приложения, агентского кабинета

Это не противоречие — это правильное распределение ролей. Партнёру по интеграции дать GraphQL-схему — почти наверняка плохая идея (overcomplication). Дать REST — стандарт.

Конкретный совет по выбору

Возьмите проект из ваших ближайших планов и пройдитесь по чек-листу:

1. Сколько у вас разных типов клиентов? 1 → REST. 3+ → GraphQL.
2. Часто меняется набор полей в карточках? Редко → REST. Часто → GraphQL.
3. Нужно ли HTTP-кеширование? Критично → REST. Не критично → GraphQL.
4. Команда знает GraphQL? Нет → REST или закладываем 2 недели на обучение.
5. API только для своих или для партнёров тоже? Для партнёров → REST (минимум).

3+ ответа в пользу GraphQL — берите его. Меньше — оставайтесь на REST. И помните: переход с REST на GraphQL занимает 3-4 спринта, обратный путь — несколько недель.

Что выбираю для типового проекта

В 2026 году мой шаблонный выбор для нового продукта:

• Внутреннее API для собственного фронта/мобайла → GraphQL (Strawberry для Python, gqlgen для Go)
• Публичные эндпоинты для интеграций → REST (DRF, FastAPI)
• Файлы и медиа → REST с прямым стримом (GraphQL плохо умеет в multipart)
• Real-time → GraphQL Subscriptions или отдельный WebSocket с своим протоколом

Это не «правильный» выбор — это рабочий выбор для типичного SaaS. Ваш контекст может сместить баланс.

Итог

GraphQL — не лучше REST. Он другой. Решает другие задачи и платит другую цену. Если у вас простой проект с одним типом клиента — REST. Если у вас сложная клиентская поверхность с разными потребностями — GraphQL окупается.

И помните: архитектурное решение должно следовать за реальной болью, а не за модой. Если GraphQL решает вашу боль — берите. Если боли нет — REST не сломан.

ПоделитьсяTelegramWhatsApp