Questions d'entretien GraphQL
1. Qu'est-ce que GraphQL et quels problemes resout-il par rapport a REST ?
GraphQL est un langage de requete pour les API et un runtime pour executer ces requetes. Problemes de REST resolus par GraphQL : over-fetching (recevoir trop de donnees — GraphQL permet de demander exactement les champs necessaires), under-fetching (necessiter plusieurs appels — GraphQL resout tout en une seule requete), evolution de l'API (pas de versionnement — ajoutez des champs sans casser les clients existants). Un seul endpoint, un schema type, et le client controle la forme de la reponse.
2. Expliquez le schema GraphQL et ses types de base.
Le schema definit les types de donnees et les operations disponibles. Types scalaires : Int, Float, String, Boolean, ID. Types complexes : Object (champs types), Input (arguments structures), Enum (valeurs predefinies), Interface (contrat commun), Union (un parmi plusieurs types). Operations racines : Query (lectures), Mutation (ecritures), Subscription (temps reel). Le schema 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 schema. Chaque champ a potentiellement un resolver. Les resolvers recoivent 4 arguments : parent (resultat du resolver parent), args (arguments de la requete), context (donnees partagees : user, DB connection), info (informations sur la requete). GraphQL execute les resolvers de haut en bas, champ par champ. Si un resolver n'est pas defini, GraphQL utilise le resolver par defaut (propriete du parent avec le meme nom).
4. Qu'est-ce que le probleme N+1 et comment le resoudre ?
Le probleme N+1 : pour une liste de N elements, chaque element declenche un resolver qui fait une requete a la base de donnees, soit N+1 requetes totales au lieu de 2. Exemple : lister 10 articles avec leurs auteurs = 1 requete (articles) + 10 requetes (un auteur par article). Solution : DataLoader (bibliotheque qui regroupe les appels en batch et met en cache les resultats). DataLoader collecte toutes les cles demandees dans un tick d'event loop et effectue une seule requete batch.
5. Expliquez les mutations et les bonnes pratiques.
Les mutations sont les operations d'ecriture (creation, 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 a jour, et gerez les erreurs dans le type de retour (union Success | Error) plutot que dans les erreurs GraphQL pour un meilleur controle.
6. Comment implementer 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 noeuds avec un cursor), pageInfo (hasNextPage, hasPreviousPage, startCursor, endCursor). Arguments : first/after (avant), last/before (arriere). Le cursor est un identifiant opaque (souvent l'ID encode en base64). La pagination par cursor est plus performante et coherente.
7. Qu'est-ce que les subscriptions GraphQL ?
Les subscriptions permettent au serveur d'envoyer des donnees en temps reel aux clients. Elles utilisent generalement des WebSockets (protocole graphql-ws). Le client s'abonne a un evenement, et le serveur pousse les mises a jour quand l'evenement se produit. Cas d'usage : chat en temps reel, notifications, mise a jour de prix, suivi de livraison. Cote serveur, les subscriptions sont liees a un systeme de pub/sub (Redis, Kafka, en memoire).
8. Comment securiser une API GraphQL ?
Defis specifiques : pas de points d'entree 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 requetes (prevenir les requetes imbriquees infinies), limitation de complexite (cout par champ, budget par requete), rate limiting par IP/utilisateur, persisted queries (n'autoriser que des requetes preapprouvees en production). Desactivez l'introspection en production.
9. GraphQL Federation et architecture multi-services.
Apollo Federation permet de composer un schema GraphQL a partir de plusieurs services (subgraphs). Chaque service definit une partie du schema et ses resolvers. Un gateway (Apollo Router) combine les schemas et route les requetes vers les bons services. Le gateway resout les entites qui s'etendent entre services avec la directive @key. C'est l'approche recommandee pour les architectures microservices avec GraphQL, car chaque equipe possede son subgraph.
10. Quand choisir GraphQL plutot que REST ?
GraphQL recommande : applications mobiles (bande passante limitee, requetes optimisees), API consommee par de multiples clients avec des besoins differents, domaines avec des relations complexes, equipes frontend et backend separees. REST preferable : 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 operations simples, GraphQL pour les requetes complexes.