Questions d'entretien GraphQL
1. Qu'est-ce que GraphQL et quels problèmes resout-il par rapport à REST ?
GraphQL est un langage de requête pour les API et un runtime pour exécuter ces requêtes. Problèmes de REST résolus par GraphQL : over-fetching (recevoir trop de données — GraphQL permet de demander exactement les champs nécessaires), under-fetching (nécessiter plusieurs appels — GraphQL résout tout en une seule requête), évolution de l'API (pas de versionnement — ajoutez des champs sans casser les clients existants). Un seul endpoint, un schéma type, et le client contrôle la forme de la réponse.
2. Expliquez le schéma GraphQL et ses types de base.
Le schéma définit les types de données et les opérations disponibles. Types scalaires : Int, Float, String, Boolean, ID. Types complexes : Object (champs types), Input (arguments structures), Enum (valeurs prédéfinies), Interface (contrat commun), Union (un parmi plusieurs types). Opérations racines : Query (lectures), Mutation (écritures), Subscription (temps réel). Le schéma est le contrat entre le client et le serveur.
3. Comment fonctionnent les resolvers ?
Un resolver est une fonction qui fournit la valeur d'un champ dans le schéma. Chaque champ a potentiellement un resolver. Les resolvers reçoivent 4 arguments : parent (résultat du resolver parent), args (arguments de la requête), context (données partagees : user, DB connection), info (informations sur la requête). GraphQL execute les resolvers de haut en bas, champ par champ. Si un resolver n'est pas défini, GraphQL utilise le resolver par défaut (propriété du parent avec le même nom).
4. Qu'est-ce que le problème N+1 et comment le résoudre ?
Le problème N+1 : pour une liste de N éléments, chaque élément declenche un resolver qui fait une requête à la base de données, soit N+1 requêtes totales au lieu de 2. Exemple : lister 10 articles avec leurs auteurs = 1 requête (articles) + 10 requêtes (un auteur par article). Solution : DataLoader (bibliothèque qui regroupe les appels en batch et met en cache les résultats). DataLoader collecte toutes les clés demandées dans un tick d'event loop et effectue une seule requête batch.
5. Expliquez les mutations et les bonnes pratiques.
Les mutations sont les opérations d'écriture (création, modification, suppression). Bonnes pratiques : nommez les mutations avec un verbe d'action (createUser, updatePost, deleteComment), utilisez des Input types pour les arguments complexes, retournez l'objet modifie (pas juste un boolean) pour que le cache client puisse se mettre à jour, et gérez les erreurs dans le type de retour (union Success | Error) plutôt que dans les erreurs GraphQL pour un meilleur contrôle.
6. Comment implémenter la pagination en GraphQL ?
Deux approches : Offset-based (simple, limit/offset, mais fragile avec les insertions), Cursor-based (Relay-style connections, recommande). La pagination Relay utilise le pattern Connection : edges (liste de nœuds avec un cursor), pageInfo (hasNextPage, hasPreviousPage, startCursor, endCursor). Arguments : first/after (avant), last/before (arrière). Le cursor est un identifiant opaque (souvent l'ID encode en base64). La pagination par cursor est plus performante et cohérente.
7. Qu'est-ce que les subscriptions GraphQL ?
Les subscriptions permettent au serveur d'envoyer des données en temps réel aux clients. Elles utilisent généralement des WebSockets (protocole graphql-ws). Le client s'abonne à un événement, et le serveur pousse les mises à jour quand l'événement se produit. Cas d'usage : chat en temps réel, notifications, mise à jour de prix, suivi de livraison. Cote serveur, les subscriptions sont liées à un système de pub/sub (Redis, Kafka, en mémoire).
8. Comment sécuriser une API GraphQL ?
Défis spécifiques : pas de points d'entrée distincts comme REST (tout passe par un endpoint). Solutions : authentification dans le context (JWT dans le header Authorization), autorisation au niveau des resolvers ou des directives (@auth), limitation de profondeur des requêtes (prévenir les requêtes imbriquées infinies), limitation de complexité (coût par champ, budget par requête), rate limiting par IP/utilisateur, persisted queries (n'autoriser que des requêtes preapprouvees en production). Desactivez l'introspection en production.
9. GraphQL Federation et architecture multi-services.
Apollo Federation permet de composer un schéma GraphQL à partir de plusieurs services (subgraphs). Chaque service définit une partie du schéma et ses resolvers. Un gateway (Apollo Router) combine les schémas et route les requêtes vers les bons services. Le gateway résout les entités qui s'etendent entre services avec la directive @key. C'est l'approche recommandee pour les architectures microservices avec GraphQL, car chaque équipe possède son subgraph.
10. Quand choisir GraphQL plutôt que REST ?
GraphQL recommande : applications mobiles (bande passante limitee, requêtes optimisées), API consommee par de multiples clients avec des besoins différents, domaines avec des relations complexes, équipes frontend et backend séparées. REST préférable : API simples avec peu de ressources, caching HTTP natif critique, upload de fichiers (plus simple en REST), API publiques (REST est plus familier). Les deux peuvent coexister : REST pour les opérations simples, GraphQL pour les requêtes complexes.