ProtoBuf + gRPC : une stack moderne pour des services distribués efficaces

Les applications deviennent de plus en plus distribuées, faire dialoguer des services de manière efficace et fiable est un défi technique majeur. Dans cet article, découvrez pourquoi et comment utiliser ProtoBuf et gRPC pour construire des services distribués efficaces, performants et interopérables et éviter les pièges courants.

Qu’est-ce que ProtoBuf ? Définition & avantages

Protocol Buffers, ou ProtoBuf, est un format de sérialisation de données binaire développé par Google. Il permet de structurer et transmettre des données de façon efficace, quel que soit le langage utilisé.

Concrètement

• ProtoBuf sert à définir des structures de données dans un fichier .proto.
• Ce fichier est ensuite compilé dans le langage utilisé (Python, Go, .NET, etc.).
• Le résultat : un code prêt à l’emploi, typé, sans parsing manuel.

Avantages principaux :

•  Format compact et léger (binaire).
• Multi-langage.
• Rapide à sérialiser et désérialiser.
• Versionnable et évolutif.

Comment ça fonctionne ?

Tout part d’un fichier .proto.

Ce fichier contient :

• Les structures de données (message, enum or service). Celles-ci sont composés de champs définis par :
  • Un type (string, int32, enum, repeated, etc.).
  • Un nom
  •  Un int associé qui va être le numéro protobuf associé pour ce champ
• La version du langage ProtoBuf utilisée.
• Si besoin des librairies, par exemple :
  • Timestamp.proto pour les datetime
  • Google.protobuf.Empty pour les messages vides
• Si besoin l’import d’autres fichiers proto
  

On compile ce fichier avec un outil adapté au langage (Python, .NET, etc.). Suivant le langage, à part l’import de libraire, aucune autre manipulation n’est nécessaire. Cela génère du code prêt à l’emploi. Pas besoin d’écrire manuellement les classes. Pas besoin de bibliothèque supplémentaire.

Côté performance

ProtoBuf utilise un format binaire.
Cela réduit la taille des messages.
Cela accélère la sérialisation et désérialisation par rapport à JSON ou XML.
D’après plusieurs tests de performances, les gains sont significatifs sur des volumes importants.

Compatibilité et support

ProtoBuf est supporté par de nombreux langages.
Certains le gèrent nativement. D’autres nécessitent un outil en ligne de commande.

Trois versions existent :

• Proto 1 : obsolète.
• Proto 2 : encore utilisée.
• Proto 3 : la plus récente. À privilégier.

Proto 3 n’impose plus les champs required.
Tous les champs sont facultatifs par défaut.
L’avantage est que les messages seront toujours compatibles cependant si un champ est nécessaire, il sera obligatoire de le mettre en required. De ce fait, protobuf gérera directement la vérification.

Utilisations possibles

ProtoBuf peut être utilisé seul.
Mais aussi avec des protocoles comme gRPC, MQTT, REST...
Il suffit que tous les composants du système partagent le même fichier .proto et surtout la même version de celui-ci.

Cas d’usage :

• Communication entre microservices.
• Transfert de données entre équipes/langages différents.
• Sérialisation rapide pour stockage ou transport.
  

Visualisation côté code

Une fois compilés, les messages et enum sEn résumé, pourquoi choisir ProtoBuf (vs JSON, XML) Caractéristiques Description Format Binaire Langages supportés Multi-langages (Python, C#, etc.) Compilation À partir de fichiers .proto Dépendances Aucune après compilation Performance Supérieure à JSON/XML Version recommandée Proto 3ont disponibles comme des objets classiques.
Pas besoin de parsing manuel.
L’exemple en .NET affiche clairement les champs générés : title, type, content, etc.

Exemple de compilation et usage du .proto en .NET

Envoyer un objet « SendMessages »
Il contient :
 - un titre global
 - un niveau de confidentialité de type Message Types
 - Une liste de messages de type Body qui contiennent chacun : une liste de texte et optionnellement une entête et un pied de page
 - Optionnellement la taille du message

et en .net 

En résumé, pourquoi choisir ProtoBuf (vs JSON, XML)

gRPC : le protocole réseau haute performance

gRPC est un framework RPC haute performance, à l'origine développé par Google et aujourd'hui en open source, basé sur HTTP/2 et ProtoBuf, offrant génération de stubs, streaming et interopérabilité multi-langage.

Fonctionnalités principales

• Communication client ↔ serveur en mode requête/réponse, et aussi streaming unidirectionnel ou bidirectionnel.
• Multiplexage de requêtes grâce à HTTP/2.
• Gestion du load balancing et des health checks pour vérifier l’état du serveur.
• Authentification possible via mTLS (certificats). Recommandé en production.
  

gRPC permet :

• D’envoyer des requêtes entre un client et un serveur.
• D’échanger des données structurées, dans les deux sens.
• De connecter des services dans une architecture distribuée.

gRPC : pourquoi c’est mieux que REST ?

gRPC privilégie les échanges rapides et typés entre microservices, tandis que REST vise l’universalité et la simplicité HTTP/JSON côté clients web

• Moins de surcharge réseau et de CPU (grâce au format binaire).
• Meilleure performance en cas d’échanges fréquents ou intensifs grâce au multiplexage qui réduit les latences.
• Plus grande vitesse de transmission de données grâce à une compression intégrée.
• Typage fort et génération automatique de code côté client et serveur.
• Gestion plus fine des erreurs contrairement au REST qui s’appuie sur les codes HTTP standards.
• Intègre une mécanique de gestion de timeout, reprise, load balacing qui améliore la robustesse de la communication.

Intégration avec ProtoBuf

gRPC s’appuie sur Protocol Buffers pour définir les messages échangés.
L’association des deux outils permet une architecture où :

• Le .proto sert à définir à la fois les messages ((request, reply, etc.)) et les services exposés par le serveur.
• Ces définitions sont compilées dans les différents langages utilisés.
• Les échanges sont structurés, optimisés et interopérables.

Résultat : Chaque service peut envoyer ou recevoir des messages dans le format défini, sans avoir à se soucier du langage ou du système utilisé de l’autre côté.

Exemple d’implémentation

Appels SayHello, GetTime, clients multi

- Idée : transmettre des questions depuis un client sur un serveur avec un message contenant une chaîne string. Récupérer la réponse sur le client
   - Question : SayHello qui prend en entrée un message de type HelloRequest avec le champ name
   - La réponse sera un message de type HelloReply avec le champ message
- Le mot clé service permet de définir une interface "RPC" qui contient les méthodes possibles. le compilateur va générer le code qui permettra d'utiliser ces méthodes

Dans la démo présentée :

• Le serveur est en .NET.
• Deux clients : un en .NET, un en Python.
• Tous utilisent le même fichier .proto.

Fonctionnement 

• Le client envoie une requête (SayHello).
• Le serveur la reçoit, traite, et renvoie une réponse.
• Le tout se fait via une liaison réseau gérée par gRPC.

Les messages échangés sont compilés à partir du .proto.
Pas besoin de parser manuellement.
Le format est connu des deux côtés.
Le client Python appelle la méthode SayHello. Le serveur en .NET reçoit la requête, traite, et renvoie une réponse visible dans le terminal Python.

Points techniques à retenir

Cas d'usage

gRPC est adapté à :

• Des échanges intensifs ou fréquents.
• Des appels de services dans des environnements distribués.
• Du streaming de données.
• Des communications entre services en microservices.

Utiliser ProtoBuf avec gRPC : points clés

L’objectif ici est de faire communiquer plusieurs applications à travers un protocole réseau, en s’appuyant sur ProtoBuf pour la définition des messages, et sur gRPC pour leur transport.

Définir le protocole partagé

Avant toute chose :

• Choisir une version commune de ProtoBuf (recommandé : Proto3).
• Définir les messages et services à partager.
• Les fichiers .proto peuvent contenir d’autres éléments, mais seules les définitions communes doivent être synchronisées entre les services.

Les champs partagés doivent être strictement identiques des deux côtés.
Le reste peut rester spécifique à chaque application.

Architecture requise

gRPC fonctionne sur une architecture serveur/clients :

• Au minimum : 1 serveur, 1 client.
• Possible : multi-serveurs, multi-clients.

Des outils peuvent être ajoutés :

• Health checks pour surveiller les services.
• mTLS pour l’authentification et la sécurité (certificats requis).
  

Exemple d’implémentation

Démo complète : en .NET (serveur) et Python (clients).transfert data
Chaque client peut :

• Envoyer une requête (ex. : “Hello”).
• Obtenir une réponse du serveur.
• Simuler des cas plus concrets (ex. : envoi de données de télémétrie).
  

Les communications sont bidirectionnelles si besoin.
Le serveur peut router les messages reçus vers d'autres clients.

Compilation des fichiers .proto

Selon le langage, la compilation diffère :

• Python :
  • Nécessite une ligne de commande avec grpc_tools.protoc.
  • Génère des fichiers Python compilés (service + messages).
• .NET :
  • La compilation se fait automatiquement au moment du build.
  • Les fichiers compilés sont intégrés au projet.

⚠️ En ProtoBuf, chaque champ est identifié par un numéro.
Il doit être unique. Deux champs avec le même numéro = erreur de compilation.

Fonctionnement côté code

Chaque message ou service défini dans .proto est :

• Converti en classe dans le langage cible.
• Accessible directement depuis le code applicatif.
  

Exemples d’appels :

• SayHello()
• GetCurrentTime()
• SendDeviceData()

Les messages sont échangés via gRPC.
Ils passent sous forme binaire, selon la structure définie.

La démo ci-dessous se fait avec une implémentation .NET côté serveur et deux clients (Python et .NET).

Spécificités pratiques

On peut transmettre des messages vides.

• Entrées ou sorties optionnelles → utiliser google.protobuf.Empty.

Adapté pour les systèmes embarqués ou à faible ressources.

• Moins lourd que du JSON.
• Moins de RAM consommée.
• Moins de CPU consommé.

Bon support multi-langage via protoc.

• Compilation possible pour C, Rust, Go, Java, etc.

A savoir avant de se lancer

• ProtoBuf impose un identifiant numérique unique par champ. Attention aux conflits à la compilation.
• Les fichiers compilés sont différents selon les langages :
  • Python → via grpc_tools.protoc
  • .NET → build automatique
• Avec gRPC, lLes messages peuvent être vides , selon les besoins.
• Avec protobuf, les champs sont par défaut optionnels mais peuvent être rendu obligatoires.
• Il est possible de faire du multi-client, multi-serveur, mais il faut gérer la redirection côté serveur.
• Ce que gRPC n’est pas :
  • Ce n’est pas un bus de messages.
  • Il ne gère pas d’abonnements ou de files d’attente nativement.
  • Il ne convient pas à tous les types d’échanges. Par exemple : moins adapté à des systèmes orientés événements ou pub/sub purs.

   

ProtoBuf + gRPC vs JSON‑RPC 

En bref, gRPC + ProtoBuf l’emportent pour les microservices à forte contrainte de perfs :

Comparé à JSON-RPC, gRPC/ProtoBuf fournit un typage strict, des messages plus compacts et le streaming sur HTTP/2, idéal pour les architectures distribuées.

Quand utiliser cette stack ?

Cette approche est adaptée si :

• Vous avez besoin d’échanges fréquents ou volumineux entre services.
• Vous devez faire communiquer plusieurs technos (ex. : Python ↔ .NET).
• Vous travaillez sur des systèmes embarqués ou à ressources limitées. (IoT, edge computing)  
• vous avez besoin de streaming de données en temps réel

Elle est moins pertinente si :

• Vous avez besoin d’un bus de messages ou d’un système pub/sub pur.
• La lisibilité manuelle du message est eqsentielle(ex. : debug rapide sans outils, log)
• Environnements où JSON est déjà imposé ou plus simple (APIs externes, front-end)

Conclusion

Lier ProtoBuf et gRPC permet :

• Une communication efficace et structurée entre services.
• Un système flexible, adaptable à différents langages.
• Une base solide pour des applications performantes, même sur systèmes limités.

Références

• gRPC documentation : https://grpc.io/
•  protobuf documentation : https://protobuf.dev/
• Guide Google API design : https://cloud.google.com/apis/design