Définition d'un service gRPC avec des tampons de protocole
Home » FR » Blog » Définition d'un service gRPC avec des tampons de protocole
* Ce billet est le troisième de la série sur le gRPC
La première étape de la construction d'un service gRPC consiste à créer la définition de l'interface du service avec les méthodes exposées par ce service, ainsi que les paramètres d'entrée et les types de retour.
Définition d'un service gRPC avec des tampons de protocole
gRPC utilise des tampons de protocole (protocol buffers ou protobufs) comme IDL pour définir l'interface du service. Les tampons de protocole sont un mécanisme extensible, indépendant du langage et de la plate-forme, permettant de sérialiser des données structurées. La définition de l'interface de service est spécifiée dans un fichier proto, qui n'est rien d'autre qu'un fichier texte simple avec une extension .proto. Les services gRPC sont définis dans un format de tampon de protocole ordinaire, les paramètres des méthodes RPC et les types de retour étant spécifiés sous forme de messages de tampon de protocole. La définition du service étant une extension de la spécification du tampon de protocole, un plug-in gRPC spécial est utilisé pour générer du code à partir de son fichier .proto.
❝ Un fichier proto, qui n'est rien d'autre qu'un fichier texte brut avec une extension .proto, est utilisé pour générer du code à partir de son fichier .proto. ❞
Dans l'exemple, l'interface de service DrinkInfo, appelée DrinkService, est définie à l'aide de protobuf, comme le montre l'extrait suivant. Le DrinkService consiste en une définition d'interface de service dans laquelle nous spécifions les méthodes distantes (addCreate et Get), leurs paramètres d'entrée et de sortie, ainsi que la définition du type (ou des formats de message) de ces paramètres.
syntax = "proto3";
message DrinkMessage {
string id = 1;
string name = 2;
string desc = 3;
}
message DrinkMessages {
repeated DrinkMessage drinks = 1;
}
message Empty {}
service DrinkService {
rpc addCreate (DrinkMessage) returns (DrinkMessage);
rpc Get (Empty) returns (DrinkMessages);
}Comme vous pouvez le constater, un service est un ensemble de méthodes (par exemple, addProduct et getProduct) qui peuvent être invoquées à distance. Chaque méthode a des paramètres d'entrée et des types de retour que nous définissons comme faisant partie du service ou qui peuvent être importés dans la définition du protobuf.
Les paramètres d'entrée et de retour peuvent être un type défini par l'utilisateur (par exemple, les types DrinkMessage et DrinkMessages) ou un type de données standard comme une chaîne de caractères. Ces types sont structurés en messages, chaque message étant un petit enregistrement logique d'informations contenant une série de paires nom-valeur. Ces champs sont des paires nom-valeur avec des numéros de champ uniques (par exemple, string id = 1) qui sont utilisés pour identifier leurs champs dans le format binaire du message.
Cette définition de service est utilisée pour construire le côté serveur et client d'une application gRPC. Dans le prochain billet, je vous donnerai plus de détails sur l'implémentation du serveur gRPC.
J'aimerais profiter de cette occasion pour vous recommander quelques livres qui pourraient vous intéresser :
