REST vs GraphQL в iGaming

TL; DR

REST - ressources prévisibles, mise en cache/CDN simple, idempotence forte et webhooks. Excellent pour les paiements, KYC/AML, webhooks PSP, rapports.
GraphQL - échantillons flexibles de « champs exactement appropriés », agrégation et BFF pour les applications clientes. Idéal pour le catalogue de jeux, la personnalisation/recommandation, les lobodashbords et les consoles d'opérateur.
Approche combo : Edge REST pour les domaines critiques (paiements, conformité) + GraphQL-BFF pour les UI/widgets et les lectures agrégées.

1) Domaines et yuskeis typiques

2) Performance et trafic

REST : ressources claires → facile à mettre en cache sur le CDN par 'GET' + 'ETag/Cache-Control'. Moins - « overfetch/underfetch » dans les UI complexes.
GraphQL : nous demandons exactement les champs et les communications nécessaires → moins de trafic sur les réseaux mobiles/lents ; danger N + 1 et requêtes « coûteuses » (cost-limites, profondeur, scoring complexe).

• Pour UI - GraphQL-BFF sur le REST/gRPC interne.
• Pour les intégrations externes et les opérations critiques, REST pur avec des DTO subtiles et des expandas de serveurs ('? include = balances, limites').

3) Cache et CDN

REST gagne : 'GET' est mis en cache sur edge ; variabilité par « Vary »/« ETag ».
GraphQL : cache au niveau client/passerelle (APQ, queries persistantes, réponse cache per query hash). Pour un CDN public, c'est plus difficile, mais des queries persistantes avec une liste blanche sont possibles.

4) La versification et l'évolution des contrats

REST : « v1/v2 » dans l'URI/titre ; nous ajoutons des champs - permis, cassé - une nouvelle version. La politique d'obsolescence est simple.
GraphQL : modifications non destructives (ajout de champs/types) sans v2 ; suppression - via '@ deprecated' et les fenêtres de migration. La discipline du schéma est plus difficile, il faut un « schema registry » et des linters.

5) Idempotence, rétroactivité, cohérence

REST : idempotence naturelle selon 'PUT '/' DELETE' et titre 'Idempotency-Key' pour 'POST' (paiements/refands). Webhooks avec 'event _ id' et dedup.
GraphQL : les mutations nécessitent une clé explicite d'idempotence dans input ; pour les critiques, il s'agit d'envelopper des mutations dans des commandes de domaine sur REST/gRPC.

6) Sécurité et limites

• mTLS entre la passerelle et les backends, OAuth2/OIDC (JWT, court TTL), ABAC par tenant/rôle.

• Scopes subtiles par route/méthode, rate/quotas simples.
• Webhooks signés (HMAC + Timstamp), allow-list IP.

• Query complexity/depth limit, max nodes/aliases, timeout sur les résolves.
• Queries Persisted/whitelisted pour les clients publics.
• DataLoader/batching vs N + 1.
• Stratégies de champ/type (field-level authZ), masquage PII dans les sélecteurs.

7) Observation et contrôle

Corrélation par 'trace _ id '/' span _ id'.
REST : métriques par endpoint/méthode (RPS, p95, 4xx/5xx).
GraphQL : métriques par opération/type, temps de résolveurs, « champs chers », taux d'erreur de schéma.
Audit : Loger qui et quels champs ont lu/muté (important pour KYC/AML/Responsible Gaming).

8) Temps réel et événements

REST webhooks pour les événements PSP/jeux/antifrod (fiabilité, signature, retraits).
GraphQL Subscriptions - pratique pour les widgets en direct (équilibre, tournoi, limites du jeu responsable). Des limites/autorisations de canal distinctes sont requises.
L'alternative est SSE/WebSocket sur la passerelle REST pour les canaux simples.

9) Multiplicité et régions

REST : isolation par itinéraire/domaine, quotas per-tenant, routage simple dans la région.
GraphQL : un endpoint - il faut un scoping tenant strict dans le contexte, l'interdiction des champs cross-tenant au niveau du schéma/résolver.
Géo-routage et data-residency : dans les deux approches, via gateway/policy.

10) Matrice de solutions (sélection rapide)

11) Anti-modèles

GraphQL est au-dessus de tout : coûteux et dangereux pour les mutations de paiement.
REST avec des ressources ultrarapides : chechard des demandes de chat à l'IU.
Aucune limite de query dans GraphQL : DDoS/« expensive query ».
GraphQL sans DataLoader : avalanche N + 1 dans la base de données.
L'idempotence implicite des mutations : les prises dans les paiements/bonus.
Mélange de l'API publique et de l'API Admin dans un seul graphe/domaine.

12) Modèle de référence pour iGaming

Edge REST Gateway (WAF, OAuth2, rate/quotas, webhooks) pour le domaine de paiement/conformité.
GraphQL-BFF pour les fronts : agrégera les données de REST/gRPC internes, entrera field-authZ, complexity-limit, queries persistantes.
Service Mesh sous le capot : mTLS, politique de trafic, circuit-breaker.

13) Questions de version/contrats

REST

Contrat = OpenAPI + génération SDK.
Versions : 'v1' → 'v2' avec une période de dépréciation de 6 à 12 mois.

GraphQL

Contrat = registre SDL + schema, linters (breaking change check).
Evolution : '@ deprecated', calendrier « sunset », diffusion de schémas diffs.

14) Chèque de mise en œuvre

• Ont défini les domaines : REST (argent/conformité) vs GraphQL (UI/agrégation).
• Gateway: OAuth2/OIDC, mTLS, WAF, rate/quotas.
• REST : 'Idempotency-Key', statuts constants, webhooks avec HMAC.
• GraphQL: persisted queries, complexity/depth, DataLoader, таймауты.
• Audit/logage des champs, masquage PII, tenant-scope.
• Cache : CDN pour REST, réponse cache/APQ pour GraphQL.
• Observabilité : métriques p95, error budget, « résolveurs chers ».
• Procédures de dépréciation (REST vN/GraphQL @ deprecated).
• UAT : tests de charge NFR, cas de « query extensive », mutations dupliquées.

15) La feuille de route de la migration (si maintenant REST propre)

1. Mettre en évidence les scripts lourds UI (catalogue, profil, dashboards).
2. Lever le GraphQL-BFF sur les REST/gRPC existants ; activer les queries persistantes.
3. Sortir le champ-authZ et les limites de complexité.
4. Transférez pas à pas les fronts vers GraphQL en laissant le circuit de paiement à REST.
5. Activer le système général d'enregistrement et les vérifications CI de breaking-changes.
6. Optimiser N + 1 (DataLoader), ajouter un cache de niveau résolver.

16) NFT/SLO (repères)

REST : passerelle de latence supplémentaire ≤ 50-80 ms p95, 5xx passerelle ≤ 0. 05 %, webhooks : livraison p95 ≤ 3 s, doublons = 0.
GraphQL : p95 de la demande ≤ 300-500 ms pour UI; max depth = 8–10; complexity budget per op; erreur de schéma <0. 1%.

Résumé

Pas « REST ou GraphQL », mais « les deux sont prévus ». Donnez aux paiements et à la conformité un REST stable et prévisible avec une forte idempotence et des webhooks. Donnez à l'interface et à l'analyse un GraphQL-BFF flexible avec des limites de complexité, des autorisations de terrain et des caches. Connectez tout via un guichet unique, l'observabilité et la discipline des contrats - et obtenez un UI rapide, de l'argent fiable et une évolution sûre de la plate-forme.