AWS AppSync pour les produits à formes de clients multiples, besoins temps réel et données réparties entre plusieurs sources ; Amazon API Gateway pour les consommateurs HTTP classiques : endpoints REST publics, webhooks, intégrations partenaires décrites en OpenAPI. La vraie question n'est pas « GraphQL ou REST » mais « qui appelle cette API, et quel contrôle du protocole lui faut-il ». Sur les plateformes serverless matures, faire tourner les deux côte à côte est la trajectoire normale, pas un compromis.
Quand GraphQL justifie-t-il sa complexité ?
GraphQL devient rentable quand plusieurs clients consomment les mêmes données sous des formes différentes : une app mobile qui affiche une carte compacte, un dashboard web qui charge la fiche complète, un outil interne qui croise trois sources. Un seul schéma, un seul endpoint, et chaque client demande exactement les champs dont il a besoin, un avantage décisif sur les connexions mobiles contraintes.
L'autre signal fort, c'est l'agrégation. Quand un même écran combine des données venant de DynamoDB, d'une base RDS et d'une API tierce, une couche GraphQL résout le tout en un seul aller-retour, au lieu de trois appels côté client ou d'un backend-for-frontend artisanal par vue. Avec un unique client web aux vues stables, rien de tout cela ne s'applique : des endpoints REST calqués sur ces vues restent plus simples à construire, à mettre en cache et à comprendre.
Que gère AppSync à votre place ?
AppSync, c'est GraphQL en service managé : il héberge le schéma, exécute les resolvers et fait tourner les subscriptions sur WebSocket sans serveur à opérer de votre côté. Les resolvers s'écrivent en JavaScript et peuvent appeler DynamoDB directement, sans Lambda sur le chemin, ce qui élimine toute une classe de cold starts et de code de liaison.
Les subscriptions sont l'atout majeur. La diffusion temps réel vers les clients connectés est intégrée au service, déclenchée par les mutations du schéma. Un cache côté serveur est disponible par resolver. Un resolver minimal en accès direct DynamoDB ressemble à ceci :
// Resolver unitaire : DynamoDB en direct, sans Lambda sur le chemin
import { util } from '@aws-appsync/utils';
export function request(ctx) {
return {
operation: 'GetItem',
key: util.dynamodb.toMapValues({ id: ctx.args.id }),
};
}
export function response(ctx) {
return ctx.result;
}
Quand API Gateway reste-t-il le choix le plus simple ?
API Gateway l'emporte dès que les consommateurs ne sont pas vos propres frontends : récepteurs de webhooks, systèmes partenaires, SDK de fournisseurs, tout ce qui se scripte avec curl. Il offre un contrôle HTTP brut (codes de statut, en-têtes, négociation de contenu) et un contrat OpenAPI exportable, versionnable, transmissible à un tiers.
Les usage plans avec clés d'API gèrent nativement quotas et throttling par partenaire, un point sans réel équivalent côté AppSync et qui devient central dès qu'un SLA est publié (nous avons traité ce volet dans la conception du SLA d'une API partenaire). Pour du REST neuf, comparez d'abord les deux déclinaisons d'API Gateway : les HTTP APIs couvrent la plupart des besoins avec une tarification plus légère que les REST APIs.
Vous hésitez entre GraphQL, REST ou les deux pour votre couche API ? Décrivez votre système : diagnostic d'une page sous 48 h.
Recevoir mon diagnostic →Comment les coûts se structurent-ils ?
AppSync facture à l'opération (query et mutation), le temps réel étant compté à part, par mise à jour de subscription délivrée et par minute de connexion ; le cache optionnel ajoute un coût horaire par instance. API Gateway facture à la requête, les HTTP APIs à un tarif plus léger que les REST APIs, plus le transfert de données sortant.
La structure compte plus que les chiffres. Un client GraphQL bavard qui multiplie les petites queries paie à l'opération, exactement comme un client REST bavard paie à la requête : GraphQL ne réduit la facture que s'il supprime réellement des allers-retours. Les subscriptions longues coûtent des minutes de connexion même inactives. Vérifiez les chiffres à jour et les conditions de l'offre gratuite sur les pages officielles d'AppSync et d'API Gateway : les deux évoluent.
AppSync vs API Gateway : le comparatif
Six dimensions séparent les deux services en pratique. Protocole et temps réel sont des différences structurelles ; auth et coût sont des différences de configuration, adaptables dans les deux sens. La dernière ligne est celle que nous utilisons en audit : le terrain où chaque service gagne sans forcer le cas d'usage de l'autre.
| Dimension | AWS AppSync | Amazon API Gateway |
|---|---|---|
| Protocole | GraphQL sur HTTP et WebSocket | HTTP/REST, plus WebSocket APIs brutes |
| Temps réel | Subscriptions intégrées, diffusion managée | WebSocket APIs : connexions et diffusion à votre charge |
| Flexibilité client | Chaque query choisit champs et imbrication | Formes de réponse fixes par endpoint |
| Auth | Cognito, OIDC, IAM, clés d'API, authorizers Lambda, règles par champ | IAM, Cognito, JWT, authorizers Lambda, usage plans avec clés d'API |
| Structure de coût | À l'opération, plus mise à jour et minute de connexion en temps réel | À la requête (ou message et minute de connexion en WebSocket) |
| Quand il gagne | Formes de clients multiples, bande passante mobile, agrégation, données live | Webhooks, API partenaires, contrats OpenAPI, quotas par consommateur |
La discipline du schéma : le vrai coût de GraphQL
Le prix opérationnel d'AppSync n'est pas le service, c'est le schéma. GraphQL impose un contrat partagé et versionné que chaque équipe touchant au graphe doit respecter : nommage, nullabilité, conventions de pagination, politique de dépréciation. Sans cette discipline, vous obtenez un graphe que plus personne n'ose modifier.
L'autorisation migre elle aussi dans le graphe : des règles d'accès par champ remplacent les règles par endpoint, plus précises et plus longues à tester. La conception des resolvers a son piège propre, le motif N+1, où un resolver de liste naïf déclenche un appel aval par élément. Tout cela se résout, mais ce sont des coûts d'ingénierie récurrents que REST ne vous facture tout simplement pas. Budgétez-les avant de choisir GraphQL, pas après.
Pourquoi finir avec les deux est la norme
La plupart des plateformes que nous voyons convergent vers un partage : AppSync devant les clients web et mobiles maison, API Gateway pour les webhooks, les endpoints partenaires et le trafic machine à machine. Ce n'est pas de l'indécision architecturale, c'est accorder le protocole au consommateur.
Les deux s'appuient sur les mêmes fonctions Lambda, les mêmes tables DynamoDB, le même bus d'événements : deux portes d'entrée, un seul backend, la duplication est plus mince qu'elle n'en a l'air. L'erreur à éviter, c'est de forcer un service dans le rôle de l'autre : une mutation GraphQL déguisée en récepteur de webhook, ou un endpoint REST qui réimplémente la sélection de champs à coups de paramètres de requête. Si ce partage est précisément ce que vous dessinez, c'est le cœur de notre service de développement d'API.
Check-list de décision
- Trois formes de clients ou plus sur les mêmes données : AppSync.
- Clients mobiles sur réseaux contraints : AppSync.
- Mises à jour live (chat, dashboards, présence) : subscriptions AppSync.
- Webhooks, intégrations partenaires, contrats OpenAPI : API Gateway.
- Quotas et clés d'API par consommateur : usage plans API Gateway.
- Un seul client web aux vues stables : API Gateway (HTTP API), restez simple.
- Les deux profils présents : les deux services, un seul backend derrière.
Dans le doute, commencez par REST : ajouter GraphQL plus tard, quand les formes de clients se multiplient, est bien plus facile que de le retirer.