DynamoDB prend-il en charge GraphQL ?

Oui, via AWS AppSync. AppSync est le service GraphQL managé d'AWS, et DynamoDB est l'une de ses sources de données natives : les resolvers traduisent chaque query ou mutation GraphQL en une opération DynamoDB comme GetItem, Query ou PutItem. DynamoDB lui-même n'a pas d'endpoint GraphQL — la couche GraphQL s'exécute devant lui.

Comment le duo fonctionne

Dans AppSync, tu enregistres une table DynamoDB comme source de données, puis tu attaches un resolver à chaque champ de ton schema GraphQL. Le handler de requête du resolver traduit les arguments GraphQL entrants en un appel DynamoDB, et son handler de réponse remet en forme le ou les éléments renvoyés par DynamoDB pour la réponse GraphQL. AWS cite AppSync en premier parmi les intégrations serverless de DynamoDB, précisément pour ce motif.

Pourquoi c'est une stack courante

Les deux moitiés sont serverless : AppSync fait monter en charge la couche API pendant que DynamoDB fait monter en charge le stockage et le débit, sans serveur d'aucun côté. Les subscriptions GraphQL en temps réel s'accordent naturellement avec les écritures en quelques millisecondes à un chiffre de DynamoDB.

Ce que coûte un seul champ imbriqué

Un resolver par champ, c'est une requête DynamoDB par champ. posts { author { name } } résout la liste une fois, puis résout author une fois par post, et chacune de ces résolutions est facturée séparément.

Mesuré avec ReturnConsumedCapacity sur une table contenant 25 posts dans une même collection d'éléments et 25 éléments auteur, d'environ 920 octets chacun :

Query, the 25 posts                        ConsumedCapacity 3.0
25 GetItem calls, one author each          ConsumedCapacity 12.5
1 BatchGetItem, the same 25 author keys    ConsumedCapacity 12.5

Le champ imbriqué coûte plus de quatre fois la requête qui a produit la liste. Le batch n'y change rien : BatchGetItem (une opération de resolver AppSync à part entière, plafonnée à 100 clés et 16 MB par appel) réduit 25 allers-retours à un seul, mais il lit quand même 25 éléments et facture 25 lectures. Il achète de la latence, pas de la capacité.

À dix de ces requêtes GraphQL par seconde, ça fait 50,92 $ par mois d'unités de requête de lecture en on-demand dans us-east-1, dont 41,06 $ pour le seul champ author — le calculateur de tarifs refait la même arithmétique sur tes propres chiffres.

C'est pour ça que le correctif est dans la conception des clés et non dans le resolver. Projette ce que renvoie le champ imbriqué dans l'élément parent ou dans un GSI, pour que la requête de liste le porte déjà et que le resolver enfant n'ait plus rien à récupérer.

L'alternative : ton propre serveur

Rien n'oblige à passer par AppSync — n'importe quel serveur GraphQL (Apollo, Yoga, et d'autres) peut résoudre des champs en appelant DynamoDB via l'AWS SDK, exactement comme il appellerait n'importe quel autre backend. Le compromis, c'est que tu exploites toi-même la couche GraphQL.

Aller plus loin

Les resolvers GraphQL restent soumis aux mêmes règles de modèles d'accès — le guide de modélisation des données explique comment concevoir des clés qui servent tes requêtes, l'expression builder génère la syntaxe de condition sous-jacente, et DynoTable te laisse inspecter ce que tes resolvers ont réellement écrit.

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.

Chiffres de capacité mesurés le 2026-07-28 sur DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 sur Node 24.18.0 ; les valeurs de ConsumedCapacity ci-dessus sont celles du moteur lui-même. Coûts calculés à partir du prix on-demand de l'unité de requête en us-east-1 dans notre table de tarifs AWS synchronisée.