07 - Glossaire
Tous les termes rencontres dans cette serie sur gRPC, classes par ordre alphabetique.
B
Bidirectional Streaming
Un mode d'appel gRPC ou le client et le serveur envoient des messages en parallèle sur le meme stream. Chacun peut envoyer a son rythme, sans attendre l'autre. Utile pour le chat, le monitoring en temps réel, ou la synchronisation de donnees.
Voir l'article sur le streaming pour les 4 patterns.
C
Channel
La connexion logique entre un client gRPC et un serveur. Un channel maintient une connexion HTTP/2 persistante et gere le load balancing, les retries et le pooling. Tu créés un channel une fois au démarrage et tu le reutilises pour tous les appels.
Client Streaming
Un mode d'appel gRPC ou le client envoie un flux de messages et le serveur répond une seule fois a la fin. Utile pour l'upload de fichiers en morceaux ou l'envoi de metriques par lots.
D
Deadline
Le temps maximum qu'un client gRPC est pret a attendre une réponse. Si le serveur ne répond pas avant le deadline, l'appel echoue avec le status DEADLINE_EXCEEDED. Toujours définir un deadline : sans lui, un appel peut rester bloque indefiniment.
typescriptconst response = await client.getUser(
{ id: "123" },
{ deadline: Date.now() + 5000 } // 5 secondes max
);
G
gRPC
Un framework d'appel de procedures à distance (RPC) développé par Google. Il utilise HTTP/2 pour le transport et Protocol Buffers pour la sérialisation. Plus rapide et plus type que REST pour la communication entre services backend.
Voir l'introduction de la serie.
gRPC-Web
Un sous-ensemble de gRPC qui fonctionne dans les navigateurs. Les navigateurs ne supportent pas HTTP/2 en mode bidirectionnel, donc gRPC-Web passe par un proxy (Envoy) qui traduit. Ca marche, mais un API Gateway REST est souvent plus simple. Voir le comparatif gRPC vs REST.
H
Health Check
Un endpoint standardise (grpc.health.v1.Health) qui permet a un load balancer ou un orchestrateur de vérifier si un service gRPC est operationnel. Le service répond SERVING, NOT_SERVING ou UNKNOWN. Voir l'article production.
HTTP/2
Le protocole de transport utilise par gRPC. HTTP/2 apporte le multiplexage (plusieurs requêtes sur une connexion), la compression des headers, et le streaming bidirectionnel. C'est ce qui rend gRPC plus performant que REST sur HTTP/1.1.
I
Interceptor
Un middleware gRPC qui s'exécuté avant ou apres chaque appel. Cote serveur ou cote client. Tu les utilises pour le logging, l'authentification, le rate limiting, les metriques. L'équivalent des middlewares Express, mais pour gRPC.
typescriptfunction loggingInterceptor(call, callback) {
const start = Date.now();
callback(null, (err, response) => {
console.log(`${call.method} - ${Date.now() - start}ms`);
});
}
Voir l'article production.
L
Load Balancing
La distribution des appels gRPC entre plusieurs instances d'un service. Deux approches : cote client (le client connaît toutes les instances et choisit) ou via un proxy (Envoy, Traefik). Le load balancing gRPC se fait au niveau de la requête, pas de la connexion, grâce à HTTP/2.
M
Metadata
Des paires clé-valeur envoyees avec un appel gRPC, equivalentes aux headers HTTP. Tu y mets les tokens d'authentification, les IDs de correlation, les informations de tracing. Les metadata peuvent etre envoyees avec la requête (client -> serveur) ou avec la réponse (serveur -> client).
mTLS (Mutual TLS)
L'authentification TLS dans les deux sens : le client vérifié le serveur ET le serveur vérifié le client. Chacun presente un certificat. C'est le standard pour sécuriser la communication entre services dans un cluster. Plus solide qu'un token API.
P
Protobuf (Protocol Buffers)
Le format de sérialisation binaire de Google, utilise par gRPC. Tu définis la structure des messages dans un fichier .proto, puis un generateur de code créé les classes dans ton langage. Plus compact et rapide que JSON.
Voir l'article sur Protobuf.
Proto file (.proto)
Le fichier qui definit les messages et les services gRPC. C'est le contrat entre le client et le serveur. Tu y declares les types, les champs (avec des numeros), et les méthodes RPC.
protobufservice UserService {
rpc GetUser (GetUserRequest) returns (User);
}
message GetUserRequest {
string id = 1;
}
R
Reflection
Un mecanisme qui permet a un client gRPC de découvrir les services et méthodes disponibles sur un serveur sans avoir le fichier .proto. Utile pour le debug avec grpcurl ou Postman. A désactiver en production si tu ne veux pas exposer ton schema.
S
Server Streaming
Un mode d'appel gRPC ou le client envoie une requête et le serveur répond avec un flux de messages. Le client lit les messages un par un jusqu'a la fin du stream. Utile pour les listes paginables, les logs en temps réel, ou les notifications.
Service Définition
La déclaration d'un service dans un fichier .proto. Elle liste les méthodes RPC, leurs types de requête et de réponse, et le mode de streaming. C'est le point de depart de tout service gRPC.
Status Code
Le code de retour d'un appel gRPC. Equivalents aux codes HTTP mais spécifiques a gRPC : OK (0), NOT_FOUND (5), INTERNAL (13), DEADLINE_EXCEEDED (4), UNAUTHENTICATED (16). Il y en a 17 au total, chacun avec une semantique precise.
U
Unary RPC
Le mode d'appel gRPC le plus simple : un message en entree, un message en sortie. Comme un appel de fonction classique, mais à travers le réseau. C'est le mode par défaut et le plus courant.
Sources
- gRPC Documentation -- la référencé officielle
- Protocol Buffers Language Guide -- syntaxe proto3
- gRPC Status Codes -- tous les codes de retour
Retrouve d'autres articles techniques sur paltemps.fr.
Article précédent : 06 - gRPC vs REST
Début de la serie : 00 - Introduction