00 - Pourquoi gRPC existe et quand l'utiliser

Ce que tu vas apprendre

• L'histoire de gRPC et pourquoi Google l'a créé
• Comment fonctionne HTTP/2 + Protocol Buffers
• Quand gRPC est le bon choix (et quand REST suffit)

Prerequisites

Aucun. C'est le point de depart. Si tu viens de la serie Microservices, tu as deja vu gRPC mentionne dans l'article sur la communication. Ici, on va en profondeur.

Un peu d'histoire

En interne, Google utilise un système RPC appele Stubby depuis les annees 2000. Stubby gere des milliards d'appels par seconde entre les services de Google. En 2015, Google a open-source une version modernisee de Stubby sous le nom de gRPC (le "g" change de signification a chaque version -- "good", "green", "groovy"...).

gRPC n'est pas une curiosite academique. C'est le protocole utilise par Google Cloud, Netflix, Spotify, Dropbox, et a peu pres toutes les boîtes qui font du microservice a grande échelle. Si tu as utilise Google Maps, YouTube, ou Gmail aujourd'hui, des appels gRPC ont tourne derrière.

Comment ca marche

gRPC repose sur deux piliers.

HTTP/2 pour le transport. Contrairement a HTTP/1.1 ou chaque requête ouvre une connexion, HTTP/2 multiplexe plusieurs appels sur une seule connexion TCP. Ca veut dire : moins de latence, moins de handshakes, et du streaming natif dans les deux sens.

Protocol Buffers (Protobuf) pour la sérialisation. Au lieu d'envoyer du JSON en texte, gRPC envoie du binaire compact. Un message qui fait 1 Ko en JSON fait 300 octets en Protobuf. C'est 3x moins de donnees sur le réseau.

protobuf// user.proto -- le contrat d'API
syntax = "proto3";

service UserService {
  rpc GetUser (GetUserRequest) returns (User);
  rpc ListUsers (ListUsersRequest) returns (stream User);
}

message GetUserRequest {
  string user_id = 1;
}

message User {
  string id = 1;
  string email = 2;
  string name = 3;
  int64 created_at = 4;
}

Ce fichier .proto est le contrat. A partir de ce fichier, tu générés du code client et serveur dans n'importe quel langage : TypeScript, Go, Python, Java, Rust, C++. Le compilateur s'assure que le client et le serveur parlent exactement le meme langage. Pas de surprise a runtime.

Les 4 types de streaming

C'est là où gRPC se demarque vraiment de REST.

1. Unary : une requête, une réponse. Comme REST. C'est le mode le plus courant.

2. Server streaming : le client envoie une requête, le serveur répond avec un flux de messages. Exemple : suivre les logs d'un service en temps réel.

3. Client streaming : le client envoie un flux de messages, le serveur répond une fois a la fin. Exemple : uploader un fichier par morceaux.

4. Bidirectional streaming : les deux cotes envoient et recoivent en continu. Exemple : un chat, un jeu multijoueur, un flux de metriques en temps réel.

protobufservice LogService {
  // Unary
  rpc GetLog (GetLogRequest) returns (LogEntry);

  // Server streaming
  rpc StreamLogs (StreamLogsRequest) returns (stream LogEntry);

  // Client streaming
  rpc UploadLogs (stream LogEntry) returns (UploadResponse);

  // Bidirectional streaming
  rpc LiveLogs (stream LogFilter) returns (stream LogEntry);
}

REST ne peut pas faire ca nativement. Tu dois ajouter du WebSocket ou du SSE a cote, avec un autre protocole, un autre format, un autre système d'erreurs. Avec gRPC, le streaming fait partie du framework. L'article dédié au streaming montre des exemples concrets en TypeScript.

Quand gRPC gagne

• Communication interne entre services : là où la performance et le typage fort comptent. C'est le use case principal.
• Haut debit : des milliers d'appels par seconde entre services. Protobuf est 5-10x plus rapide que JSON a sérialiser/désérialiser.
• Streaming de donnees : logs, metriques, events en temps réel. Impossible a faire proprement en REST.
• Equipes polyglotes : le fichier .proto généré du code dans tous les langages. L'équipe Go et l'équipe TypeScript partagent le meme contrat.

Quand REST gagne

• APIs publiques : les navigateurs parlent HTTP/JSON nativement. gRPC nécessité gRPC-Web, une couche supplementaire.
• Simplicite : curl https://api.example.com/users/123 est plus simple que grpcurl -plaintext localhost:50051 UserService/GetUser.
• Debug : tu peux lire du JSON dans un navigateur. Du Protobuf binaire, non.
• Ecosysteme : OpenAPI/Swagger, Postman, les outils de test API sont tous construits autour de REST.

Sur paltemps.fr, l'API est en REST (Elysia). C'est le bon choix pour une application avec un frontend web et un seul processus backend. gRPC ne se justifierait que si on extrayait des services internes, ce qui n'est pas le cas.

Ce que couvre cette serie

Tous les exemples sont en TypeScript avec @grpc/grpc-js. Si tu veux comprendre le contexte architectural dans lequel gRPC s'inscrit, la serie Microservices : de la theorie a la pratique est le point de depart.

Résumé

• gRPC = HTTP/2 + Protocol Buffers, créé par Google, open-source depuis 2015
• Binaire compact (3x moins que JSON), typage fort, streaming natif
• Ideal pour la communication interne entre services
• REST reste meilleur pour les APIs publiques et le debug
• Les 4 modes de streaming sont la vraie force de gRPC face a REST

Article suivant : 01 - Protocol Buffers : définir ton contrat d'API

Sources

• gRPC Official - Introduction to gRPC
• Protocol Buffers Documentation
• Google Cloud - gRPC Design and Architecture