gRPC et alternatives : choisir son protocole

Prérequis : cours 5.1 ; notions HTTP/2 (Réseaux 7.3).

Pourquoi

REST/JSON suffit entre front et back, mais entre services internes à fort volume, le texte verbeux et les allers-retours coûtent cher. gRPC et consorts existent pour ces cas — à choisir en connaissance de cause, pas par hype.

Concepts

• gRPC : contrats en Protocol Buffers (schéma typé, génération de clients), transport HTTP/2 binaire, 4 modes (unaire, streaming serveur/client/bidirectionnel). Fort : perfs, typage, streaming. Faible : debug au curl impossible, navigateurs mal à l'aise (grpc-web en passerelle).
• GraphQL : le client choisit ses champs (fini le sur/sous-fetching), schéma unique fédérable. Fort : front mobile/web hétérogènes. Faible : cache HTTP quasi mort, complexité (N+1 côté serveur, depth limiting), observabilité.
• Règle de choix : REST/JSON par défaut (universel, débuggable) ; gRPC entre services internes chauds ; GraphQL quand les clients ont des besoins très différents. Un seul style par frontière, pas trois.

Exemple : contrat proto

service Billing {
  rpc Charge (ChargeRequest) returns (ChargeResponse);
}
message ChargeRequest { string order_id = 1; int64 cents = 2; }
// Champs numérotés : renommer libre, renuméroter interdit

Cas réel

Passerelle REST→gRPC ajoutée « pour les perfs » alors que le goulot était la base (p95 inchangé, +1 hop à opérer). Mesurer d'abord (profiler !), changer de protocole ensuite — dans 80 % des cas, le protocole n'était pas le problème.

Pièges

• Changer les numéros de champs proto : casse la compatibilité binaire. Ajouter = ok, renuméroter = jamais.
• GraphQL sans garde-fous : requêtes abyssales (profondeur/complexité limitée !), N+1 serveur.
• gRPC exposé au public sans passerelle : debug et sécu compliqués — REST/GraphQL en façade, gRPC en interne.

À retenir

REST par défaut, gRPC interne chaud, GraphQL clients hétérogènes ; mesurer avant de changer.