REST vs GraphQL в iGaming

TL;DR

REST — предсказуемые ресурсы, простая кэшируемость/CDN, крепкая идемпотентность и вебхуки. Отличен для платежей, KYC/AML, вебхуков PSP, отчетности.
GraphQL — гибкие выборки «ровно нужных полей», агрегации и BFF для клиентских приложений. Идеален для каталога игр, персонализации/рекомендаций, лободашбордов и операторских консолей.
Комбо-подход: Edge REST для критичных доменов (платежи, комплаенс) + GraphQL-BFF для UI/виджетов и агрегированных чтений.

1) Домены и типовые юзкейсы

2) Производительность и трафик

REST: четкие ресурсы → легко кешировать на CDN по `GET` + `ETag/Cache-Control`. Минус — «overfetch/underfetch» при сложных UI.
GraphQL: запрашиваем ровно нужные поля и связи → меньше трафика на мобильных/медленных сетях; опасность N+1 и «дорогих» запросов (cost-лимиты, глубина, complexity scoring).

• Для UI — GraphQL-BFF поверх внутренних REST/gRPC.
• Для внешних интеграций и критичных операций — чистый REST с тонкими DTO и серверными экспандами (`?include=balances,limits`).

3) Кэш и CDN

REST выигрывает: `GET` кэшируются на edge; вариативность через `Vary`/`ETag`.
GraphQL: кэш на уровне клиента/шлюза (APQ, persisted queries, response cache per query hash). Для публичного CDN — сложнее, но возможны persisted queries с белым списком.

4) Версияция и эволюция контрактов

REST: `v1/v2` в URI/заголовке; добавляем поля — допускается, ломаем — новая версия. Проста политика устаревания (deprecation).
GraphQL: ненарушающие изменения (добавление полей/типов) без v2; удаление — через `@deprecated` и окна миграции. Сложнее дисциплина схемы, нужен «schema registry» и линтеры.

5) Идемпотентность, ретраи, согласованность

REST: естественная идемпотентность по `PUT`/`DELETE` и заголовку `Idempotency-Key` для `POST` (платежи/рефанды). Вебхуки с `event_id` и дедуп.
GraphQL: мутации требуют явного ключа идемпотентности в input; для критики — заворачивать мутации в доменные команды на REST/gRPC.

6) Безопасность и лимиты

• mTLS между шлюзом и бэкендами, OAuth2/OIDC (JWT, короткий TTL), ABAC по тенанту/ролям.

• Тонкие scopes на маршрут/метод, простые rate/quotas.
• Подписанные вебхуки (HMAC + таймштамп), allow-list IP.

• Query complexity/depth limit, max nodes/aliases, timeout на резолверы.
• Persisted/whitelisted queries для публичных клиентов.
• DataLoader/batching против N+1.
• Политики на поле/тип (field-level authZ), маскирование PII в селекторах.

7) Наблюдаемость и контроль

Корреляция по `trace_id`/`span_id`.
REST: метрики по эндпоинту/методу (RPS, p95, 4xx/5xx).
GraphQL: метрики по операции/типу, время резолверов, «дорогие поля», частота ошибок схемы.
Аудит: логировать кто и какие поля читал/мутировал (важно для KYC/AML/Responsible Gaming).

8) Реал-тайм и события

REST вебхуки для событий PSP/игры/антифрода (надежность, подпись, ретраи).
GraphQL Subscriptions — удобно для live-виджетов (баланс, турнир, лимиты ответственной игры). Требуются отдельные лимиты/авторизация канала.
Альтернатива — SSE/WebSocket на REST-шлюзе для простых каналов.

9) Мультитенантность и регионы

REST: изоляция маршрутами/домена­ми, квоты per-tenant, простая маршрутизация по региону.
GraphQL: один endpoint — необходимо строгое tenant scoping в контексте, запрет cross-tenant полей на уровне схемы/резолверов.
Geo-маршрутизация и data-residency: в обоих подходах — через gateway/policy.

10) Матрица решений (быстрый выбор)

11) Анти-паттерны

GraphQL поверх всего подряд: дорого и небезопасно для платежных мутаций.
REST со сверхдробными ресурсами: чехарда чатов запросов в UI.
Отсутствие query-лимитов в GraphQL: DDoS/«expensive query».
GraphQL без DataLoader: лавина N+1 в БД.
Неявная идемпотентность мутаций: дубли в платежах/бонусах.
Смешение публичного и админского API в одном графе/домене.

12) Референс-паттерн для iGaming

Edge REST Gateway (WAF, OAuth2, rate/quotas, вебхуки) для платежного/комплаенс-домена.
GraphQL-BFF для фронтов: агрегирует данные из внутренних REST/gRPC, вводит field-authZ, complexity-limit, persisted queries.
Service Mesh под капотом: mTLS, политика трафика, circuit-breaker.

13) Вопросы версии/контрактов

REST

Контракт = OpenAPI + генерация SDK.
Версии: `v1` → `v2` с периодом депрекации 6–12 мес.

GraphQL

Контракт = SDL + schema registry, линтеры (breaking change check).
Эволюция: `@deprecated`, «sunset» календарь, рассылка схем-диффов.

14) Чек-лист внедрения

• Определили домены: REST (деньги/комплаенс) vs GraphQL (UI/агрегации).
• Gateway: OAuth2/OIDC, mTLS, WAF, rate/quotas.
• REST: `Idempotency-Key`, консистентные статусы, вебхуки с HMAC.
• GraphQL: persisted queries, complexity/depth, DataLoader, таймауты.
• Аудит/логирование полей, маскирование PII, тенант-скоуп.
• Кэш: CDN для REST, response cache/APQ для GraphQL.
• Наблюдаемость: метрики p95, error budget, «дорогие резолверы».
• Процедуры депрекации (REST vN / GraphQL @deprecated).
• UAT: NFR-тесты на нагрузку, «expensive query» кейсы, дубликаты мутаций.

15) Дорожная карта миграции (если сейчас чистый REST)

1. Выделить UI-тяжелые сценарии (каталог, профиль, дашборды).
2. Поднять GraphQL-BFF поверх существующих REST/gRPC; включить persisted queries.
3. Вынести field-authZ и лимиты сложности.
4. Пошагово переводить фронты на GraphQL, оставив платежный контур в REST.
5. Включить общий schema registry и CI-проверки breaking-changes.
6. Оптимизировать N+1 (DataLoader), добавить кэш уровня резолверов.

16) НФТ/SLO (ориентиры)

REST: добавочная latency шлюза ≤ 50–80 ms p95, 5xx шлюза ≤ 0.05%, вебхуки: доставка p95 ≤ 3 s, дубликаты = 0.
GraphQL: p95 запроса ≤ 300–500 ms для UI; max depth = 8–10; complexity budget per op; ошибка схемы < 0.1%.

Резюме

Не «REST или GraphQL», а «и то, и другое — по назначению». Дайте платежам и комплаенсу стабильный, предсказуемый REST с сильной идемпотентностью и вебхуками. Дайте интерфейсу и аналитике гибкий GraphQL-BFF с лимитами сложности, полевой авторизацией и кэшами. Свяжите все через единый gateway, наблюдаемость и дисциплину контрактов — и получите быстрый UI, надежные деньги и безопасную эволюцию платформы.