Определение
GraphQL — это язык запросов к API и среда выполнения (runtime) для обработки этих запросов, созданный в Facebook (Meta) в 2012 году и открытый для сообщества в 2015-м. В отличие от классического REST, где сервер сам решает, какие данные вернуть в каждом эндпоинте, GraphQL позволяет клиенту (фронтенду, мобильному приложению, умной колонке) точно указать, какие поля и связи ему нужны. Сервер возвращает ровно этот набор — ни больше, ни меньше.
Для DTC-бренда это означает простую вещь: витрина, приложение лояльности и CRM-интеграция могут обращаться к одному GraphQL-эндпоинту, но получать разные срезы данных под свои задачи. Никаких «толстых» ответов, где 80% полей не используются.
Аналогия из розницы
Представьте шоурум с товарами. При REST-подходе вы приходите и говорите: «Дайте коробку с товаром». Продавец приносит стандартный набор: футболка, размерная сетка, состав, история бренда, 12 фото, отзывы, инструкция по стирке. Даже если вам нужна только цена и наличие — вы получаете всё.
При GraphQL вы заполняете бланк: «Цена, размер L, наличие на складе в Москве». Продавец приносит ровно три строки. Быстрее, дешевле по трафику, меньше ошибок на кассе.
Формула: сколько вы экономите
Ключевая метрика — payload efficiency:
Экономия трафика (%) = (1 − Размер GraphQL-ответа / Размер REST-ответа) × 100
Пример из практики headless-магазина косметики:
- REST-ответ карточки товара: 48 КБ
- GraphQL-ответ с нужными полями: 7,4 КБ
- Экономия: (1 − 7,4 / 48) × 100 ≈ 84,6%
На мобильном трафике при 120 000 сессий в месяц это даёт ощутимое снижение нагрузки на CDN и ускорение LCP.
Сравнительная таблица: REST vs GraphQL
| Критерий | REST | GraphQL |
|---|---|---|
| Количество эндпоинтов | Много (`/products`, `/cart`, `/user`) | Один (`/graphql`) |
| Выбор полей | Определяет сервер | Определяет клиент |
| Over-fetching | Часто | Практически исключён |
| Under-fetching (N+1 запросов) | Требует нескольких вызовов | Решается одним запросом |
| Версионирование | `/v1/`, `/v2/` | Эволюция схемы без версий |
| Кэширование на CDN | Простое (по URL) | Сложнее (обычно POST) |
| Порог входа | Низкий | Средний (нужна схема, resolver'ы) |
| Идеален для | Простых сайтов, webhooks | Headless commerce, омниканальность |
Где GraphQL реально работает в DTC
1. Headless-витрина на Next.js + Shopify Storefront API.
GraphQL-запрос собирает карточку товара, варианты, остатки по складам и рекомендации за один round-trip. Время до первого байта (TTFB) падает на 200–400 мс по сравнению с цепочкой REST-вызовов.
2. Единая корзина на всех каналах.
Сайт, мобильное приложение и чат-бот в Telegram используют одну схему cart. Изменение логики промокодов происходит в одном месте — resolver'е, а не в трёх клиентах.
3. Персонализация на лету.
Запрос customer { loyaltyPoints, segment, recommendedProducts(first: 6) } возвращает блок «Для вас» без отдельного микросервиса рекомендаций.
4. Интеграция с ERP и 1С.
GraphQL-слой-фасад скрывает legacy-систему. Фронтенд не знает, что под капотом SOAP или прямой SQL — он видит чистую схему.
5. A/B-тесты и feature flags.
Директива @include(if: $showNewCheckout) позволяет включать поля условно, не переписывая запросы.
Частые ошибки и заблуждения
«GraphQL заменяет базу данных».
Нет. GraphQL — это слой между клиентом и источниками данных (БД, микросервисы, внешние API). Он не хранит данные.
«GraphQL автоматически решает проблему N+1».
Нет. Без DataLoader'а и батчинга вы получите N+1 на уровне resolver'ов. Это классическая ловушка при подключении к PostgreSQL.
«GraphQL всегда быстрее REST».
Не всегда. Сложные вложенные запросы без ограничения глубины могут положить сервер. Обязательны: persisted queries, лимит глубины (обычно 7–10 уровней), rate limiting по стоимости запроса.
«Один эндпоинт = нечего кэшировать».
Кэширование возможно: на уровне resolver'ов, через Apollo Cache, CDN с persisted queries (GET-запросы по хэшу).
«GraphQL небезопасен».
Схема может раскрыть внутреннюю структуру. Решение — отключить introspection в production и использовать allow-list запросов.
«Нужен всем».
Если у вас 20 SKU и статичный сайт на Tilda — GraphQL избыточен. Он окупается при омниканальности, сложной каталогизации и активной интеграции с внешними системами.
Практические цифры для планирования
- Стоимость запроса в Apollo: по умолчанию 1000 единиц в час на клиента — этого хватает на ~3000–5000 карточек товара в сутки.
- Глубина запроса: держите ≤ 7 уровней, иначе latency растёт нелинейно.
- Размер ответа: цель — ≤ 15 КБ на один запрос карточки товара для мобильных.
Связанные термины
- Headless commerce — архитектура, где фронтенд отделён от бэкенда; GraphQL — типовой язык связи.
- REST API — предшественник и альтернатива.
- Apollo Client / Relay — популярные клиенты для работы с GraphQL.
- DataLoader — утилита батчинга запросов, решает N+1.
- Persisted Queries — механизм кэширования и безопасности.
- Storefront API (Shopify) — коммерческая реализация GraphQL для e-commerce.
- Schema Stitching / Federation — объединение нескольких GraphQL-сервисов в один граф.
