Catégories
Start-up et applications

Comprendre les bases du gRPC

Dans la tranche précédente de cette série, nous avons décrit les bases de gRPC en termes d'histoire et de vue d'ensemble. Nous avons expliqué comment le gRPC a émergé de la technologie d'appel de procédure à distance (RPC) et est devenu une technologie qui est en train de devenir un élément incontournable dans le paysage de l'informatique distribuée. En outre, nous avons fourni un aperçu de haut niveau du fonctionnement de la technologie.

Dans cet épisode, nous allons examiner plus en détail gRPC. Nous allons passer brièvement en revue les bases dont nous avons discuté précédemment. Nous allons couvrir l'essentiel de l'architecture gRPC en termes de spécification et d'implémentation. Ensuite, nous allons examiner en détail les concepts et pratiques sous-jacents requis pour créer une API gRPC.

Nous parlerons des différentes approches pour l'échange d'informations sous gRPC, la requête / réponse synchrone ainsi que le streaming unidirectionnel et bidirectionnel. Nous allons passer du temps à examiner la spécification des tampons de protocole, en particulier l'encodage et le décodage. (Protocol Buffers est le format binaire par lequel les données sont transmises entre les points de terminaison gRPC.) Enfin, nous allons étudier les messages et les procédures gRPC ainsi que les différentes approches pour créer du code réel pour une API gRPC.

Commençons par les concepts clés.

Concepts clés

gRPC est une technologie d'API client-serveur qui permet d'échanger des informations de trois manières. La première méthode consiste en une interaction requête / réponse synchrone typique. La deuxième méthode consiste à envoyer une requête au serveur et à renvoyer les données dans un flux. C'est ce qu'on appelle le streaming unidirectionnel. La troisième méthode consiste à envoyer des données dans un flux du client au serveur et à demander au serveur de renvoyer les données dans un flux au client. C'est ce qu'on appelle le streaming bidirectionnel.

HTTP / 2 est le protocole spécifié pour l'échange de données sous gRPC. En outre, les données sont échangées entre un client et un serveur dans un format binaire connu sous le nom de tampons de protocole. Alors que la spécification gRPC n'interdit pas l'utilisation d'autres formats de données tels que Thrift, JSON ou SOAP pour le codage des données à partager entre le client et le serveur, la plupart, sinon la totalité, des implémentations de gRPC utilisent des tampons de protocole. C'est devenu la norme de facto.

Protocol Buffers n'est pas un format de données auto-descriptif. Contrairement à JSON ou XML où l'on peut déchiffrer le champ et la valeur dans une structure de données en examinant simplement la structure de données elle-même, Protocol Buffers nécessite un "manuel de référence" commun au client et au serveur. Ce manuel de référence est le mécanisme utilisé par les sérialiseurs pour encoder et décoder les données envoyées entre le client et le serveur. Ce "manuel de référence" est le .proto fichier. (Voir la figure 1 ci-dessous)

Figure 1: La structure fondamentale d'une interaction client-serveur gRPC

Figure 1: La structure fondamentale d'une interaction client-serveur gRPC

le .proto file est la source faisant autorité qui décrit les procédures publiées par une API gRPC particulière. Également .proto fichier décrit les structures de données qu'une procédure donnée consomme et émet. Le terme pour une structure de données sous gRPC est un message. UNE .proto file est un fichier texte dont le format est conforme à la spécification de langage Protocol Buffers publiée par Google. Vous pouvez lire la spécification ici.

Création du .proto Fichier

La première chose que vous allez faire lors de la création d'une API gRPC est de créer le .proto fichier. Comme mentionné ci-dessus, le .proto Le fichier décrira les procédures (fonctions a.k.a) publiées par l'API ainsi que les messages que les procédures utiliseront.

Une fois la .proto est créé, il sera utilisé par le langage de programmation de votre choix pour encoder et décoder les données pour la transmission entre le client et le serveur au format binaire Protocol Buffers. (Voir la figure 2 ci-dessous)

Figure 2: La norme de facto pour l'échange de données entre client et serveur sous gRPC est Protocol Buffers

Figure 2: La norme de facto pour l'échange de données entre le client et le serveur sous gRPC est Protocol Buffers

Également .proto Le fichier peut être utilisé comme source pour la génération automatique de code passe-partout dans le langage de programmation de votre choix. (Nous aborderons le code de génération automatique plus loin dans cet article.) La liste 1 ci-dessous montre le .proto fichier de démonstration de l'API gRPC SimpleService qui accompagne cet article. Notez que le .proto file définit un package nommé simplegrpc à la ligne 3. Les messages sont définis des lignes 6 à 55 et les procédures sont définies aux lignes 58 à 66.

Listing 1: Le fichier .proto pour l'API de démonstration SimpleService

Liste 1: le .proto fichier pour l'API de démonstration SimpleService

Nous allons couvrir les messages, les procédures et les espaces de noms dans les sections qui suivent. Les particularités de l'implémentation de l'API SimpleService basée sur le .proto Les fichiers affichés ci-dessus dans le listing 1 sont traités dans les articles correspondants de cette tranche qui décrivent la création d'API gRPC à l'aide de la génération automatique de code et de la programmation avec des bibliothèques et des frameworks.

Définition des messages

Un message représente un type de données gRPC personnalisé décrit dans le format Protocol Buffers. Un message est composé de champs. Le type d'un champ peut être l'un des types scalaires Protocol Buffers. En outre, le type d'un champ peut être un autre message. Le tableau 1 ci-dessous répertorie les types scalaires définis par la spécification Protocol Buffers. Une description des types complexes est fournie dans la section Comprendre le format de message des tampons de protocole qui suit.

Type Exemple Commentaire
double 2,5 double a 15 chiffres décimaux de précision
flotte 11,23 double a 7 chiffres décimaux de précision
int32 -4 Plage: -2,147,483,648 à 2,147,483,647
int64 4 Gamme -9,223,372,036,854,775,808 à 9,223,372,036,854,775,807
uint32 564 0 à 4 294 967 295; Utilise un codage de longueur variable.
uint64 3 0 à 18 446 744 073 709 551 615; Utilise un codage de longueur variable.
sint32 -99 Valeur int signée. Ceux-ci encodent plus efficacement les nombres négatifs au format binaire Protocol Buffer que les int32 réguliers
sint64 99 Valeur int signée. Ceux-ci encodent plus efficacement les nombres négatifs dans le format binaire Protocol Buffer que le standard int64
fixe32 45 Toujours quatre octets. Plus efficace que uint32 si les valeurs sont souvent supérieures à 228
fixe64 45 Toujours huit octets. Plus efficace que uint64 si les valeurs sont souvent supérieures à 256
sfixed32 -76 Toujours quatre octets
sfixed64 76 Toujours huit octets
booléen VRAI Vrai ou faux, 0 ou 1
chaîne "Bonjour le monde"
octets

Tableau 1: Les valeurs scalaires prises en charge par les spécifications des tampons de protocole

Comprendre le format de message des tampons de protocole

Un message est construit selon la structure définie par le format Protocol Buffers. Chaque message se voit attribuer un nom unique. Chaque champ d'un message est également nommé. Un champ est défini avec un type de données et un numéro d'index. Les numéros d'index sont attribués en séquence. L'utilisation d'un numéro d'index est essentielle pour le format de message Protocol Buffers car lorsqu'un message est codé au format binaire, les champs sont identifiés en fonction de leurs numéros d'index. Quand vient le temps de décoder le message, la logique de désérialisation utilise le numéro d'index comme clé par laquelle déchiffrer la structure de données en texte lisible par l'homme. C'est encore là que vous voyez l'accent mis sur les performances dans l'architecture de gRPC. Le référencement des champs par index par rapport aux noms de champ produira toujours un avantage en termes de performances. Il en sera de même pour l'ordre des champs qui est inhérent à une telle indexation par rapport à un format où les champs peuvent être dans n'importe quel ordre (et les champs sont identifiés par leur nom de champ). Les concepteurs de gRPC ont clairement cherché des moyens de réduire le temps machine consacré à la sérialisation et à la désérialisation. (Nous aborderons l'identification des champs plus loin dans cet article lorsque nous aborderons le codage binaire selon la spécification Protocol Buffers.)

LIsting 2 ci-dessous montre un exemple de deux messages Protocol Buffers, Adresse et La personne.

message Address {
  string address = 1
  string city = 2
  string state_province = 3
  string country = 4
  string postal_code = 5
}
message Person {
  string first_name = 1;
  string last_name = 2
  int32 age = 3;
  Address address = 4
}

Liste 2: Un exemple de messages Protocol Buffers

Notez dans le Listing 2, ci-dessus, que le message nommé Address contient cinq champs, qui sont tous une chaîne de type scalaire. Le message nommé Person contient quatre champs, dont trois sont des types scalaires (Prénom, nom de famille, et âge). Le type du champ nommé adresse est le type de message Adresse. La création de messages contenant des types scalaires et complexes est assez courante. L'utilisation d'un message comme type de données favorise la réutilisation du code.

La spécification Protocol Buffers prend également en charge les messages imbriqués. Liste 3 ci-dessous un exemple d'imbrication d'un message dans un autre.

message Person {
  message Address {
    string address = 1
    string city = 2
    string state_province = 3
    string country = 4
    string postal_code = 5
  }
  string first_name = 1;
  string last_name = 2
  int32 age = 3;
  Repeated Address addresses = 4
}

Liste 3: Un exemple de message de tampons de protocole imbriqués

Notez que dans le listing 3, le Adresse le message est imbriqué dans le La personne message. Notez également que Adresse est le type attribué aux adresses de champ du La personne message. Le mot réservé Répété est utilisé dans le cadre de la déclaration du champ adresses. Répété indique que le champ est un tableau d'un type donné, dans ce cas, Adresse. Champs marqués Répété renvoie toutes les valeurs d'un tableau à la fois, dans le cadre du message. Cependant, si le tableau était marqué du mot réservé Courant, les valeurs du tableau seront renvoyées une par une dans un flux. (Nous aborderons les flux plus loin dans cet article.)

Comprendre la sérialisation des tampons de protocole

Comme mentionné ci-dessus, toutes les données se déplaçant entre le client et le serveur sont codées dans et à partir du format binaire Protocol Buffers. (Vous pouvez lire les détails du guide de langage des tampons de protocole ici.) Le codage et le décodage des tampons de protocole (a.k.a. sérialisation et désérialisation) utilisent le schéma défini dans un .proto fichier pour convertir un message texte en et à partir de données binaires.

Le concept critique à comprendre est que le codage et le décodage binaire Protocol Buffer dépendent de l'accès au schéma défini dans un .proto fichier. Comme vous le lirez plus tard dans cet article, le code qui encode et décode les données binaires échangées dans une interaction gRPC est généralement créé à l'aide d'un outil spécial nommé protocole. protocole peut générer automatiquement un code client et serveur intégrant la logique de codage et de décodage. protocole peut créer du code qui intègre un modèle logique du schéma gRPC. Ce modèle logique élimine le besoin d'avoir le réel .proto fichier disponible pour encoder et décoder un message binaire pendant l'exécution. Cela s'appelle la génération automatique de code statique.

Aussi, protocole peut générer automatiquement un code client et serveur qui charge le .proto en mémoire lors de l'exécution, puis utilise le schéma en mémoire pour coder et décoder un message binaire. Cette approche est l'approche de génération de code dynamique de gRPC. Bien que ProgrammableWeb n'a pas pu trouver de preuve d'une telle implémentation dynamique de gRPC dans le monde réel, cette approche pourrait être utile dans les situations où le contrat technique de l'API gRPC devrait changer régulièrement. Cela s'apparente un peu à la flexibilité offerte aux API REST via l'hypermédia, bien que très peu d'implémentations REST exploitent réellement cette capacité. Ce dynamisme maintient le client consommateur et le serveur fournisseur en synchronisation les uns avec les autres lorsqu'il s'agit de leur compréhension mutuelle de ce contrat.

Cependant, cette approche dynamique signifie également qu'un ou plusieurs.proto les fichiers avec un contenu identique doivent être physiquement accessibles au client et au serveur au moment de l'exécution, ce qui pourrait être un défi. Par exemple, si le client et le serveur sont topologiquement (en termes de réseau) ou géographiquement séparés l'un de l'autre, cela irait probablement à l'encontre de la nature haute performance de gRPC pour le client d'interroger un emplacement central. .proto fichier à partir d'un réseau au moment de l'exécution. Une solution à ce problème serait de s'assurer que le client et le serveur ont un accès local à leurs propres copies identiques du .proto fichier au moment de l'exécution. Mais cela nécessiterait un processus de synchronisation / réplication rapide et fiable qui, pour autant que nous puissions le dire, n'est pas fourni par le gRPC lui-même. En conséquence, une telle approche dynamique est probablement la mieux adaptée aux interactions de service backend au sein du même système physique où un seul .proto Le fichier est local à la fois pour le client consommateur et le serveur fournisseur.

De plus, gardez à l'esprit que la génération automatique dynamique crée uniquement du code de travail pour l'encodage et le décodage des messages binaires. Si la .proto ajoute une nouvelle procédure au schéma gRPC, la logique métier de cette nouvelle procédure doit encore être écrite par un développeur. Encore une fois, comme mentionné ci-dessus, avoir un processus de développement logiciel qui est synchronisé avec les changements dans le .proto le fichier est critique.

Jetons un coup d'œil à un exemple de .proto fichier correspond à un encodage binaire. La figure 3 ci-dessous montre une partie d'un .proto qui définit un anniversaire de message de Protocol Buffers. L'anniversaire a trois champs de données: journée, mois et année. Chaque champ est de type int32. Notez que le champ jour reçoit l'index 1, le champ mois a l'index 2 et le champ année a l'index 3. Le processus de codage est tel que la logique de sérialisation examinera une instance d'un message et convertira chaque champ en un binaire tronçon. Le bloc binaire du champ aura son numéro d'index, son type de données et sa valeur disposés sous forme de tableau d'octets en séquence. Ce qu'il n'aura PAS, c'est le nom du champ. Comme mentionné précédemment, les champs sont identifiés par numéro d'index.

Figure 3: La spécification du format binaire Protocol Buffers encode et décode en données binaires selon la définition du message dans le fichier .proto

Figure 3: La spécification de format binaire Protocol Buffers code et décode en données binaires selon la définition du message dans le .proto fichier

Quand vient le temps de désérialiser le message binaire dans un format texte, la logique de désérialisation obtient le numéro d'index du tableau d'octets binaires et recherche le nom du champ en fonction du numéro d'index défini dans la définition du message dans le .proto fichier. Ensuite, la logique extrait le nom du champ du .proto en conséquence et associe le nom du champ aux données correspondantes comme illustré à la figure 3 ci-dessus. Il ne reste plus qu'à créer une représentation textuelle du nom du champ et de la valeur du champ. La représentation textuelle peut être dans n'importe quel format pris en charge par le sérialiseur / désérialiseur tel que XML, YAML ou JSON, comme ceci:

  {
    day: 7
    month: 5,
    year: 1971
  }

Sachez que le travail de sérialisation et de désérialisation des données en binaire Protocol Buffers implique une programmation de bas niveau avec des bits et des octets. Une telle programmation nécessite un certain ensemble de compétences et une certaine façon de penser. Et c'est laborieux. Bien que le fait de pouvoir encoder des tampons de protocole puisse être un défi intrigant pour certains, c'est un travail qui est plus facile à faire en utilisant les bibliothèques existantes. Tous les frameworks de langage populaires pour gRPC ont des bibliothèques de sérialiseur / désérialiseur intégrées. Ainsi, il n'est pas nécessaire de réinventer la roue.

Cependant, il existe des situations réelles dans lesquelles il est nécessaire pour un programmeur de se confronter directement à un binaire Protocol Buffer. N'oubliez pas que l'un des principaux avantages du gRPC est qu'il est très rapide et efficace lorsqu'il s'agit d'utiliser les ressources de la machine. Cela rend le gRPC très attractif pour les entreprises qui ont un besoin extraordinaire de vitesse, un désir de plus petites empreintes de centre de données à grande échelle (par exemple: échelle Web), ou les deux.

En conséquence, il existe des situations dans lesquelles il est inacceptable de prendre le temps de désérialiser un binaire entier de Protocol Buffers en texte. Plutôt que de désérialiser le binaire entier, il est plus rapide d'entrer simplement dans le binaire et d'extraire exactement le champ d'intérêt en fonction du numéro d'index. Encore une fois, il s'agit d'une option d'amélioration des performances qui n'est tout simplement pas disponible dans d'autres architectures d'API telles que REST.

L'accès au binaire avec le degré de granularité nécessite un code personnalisé. Vous devez connaître le numéro d'index du champ que vous recherchez ainsi que le type de données de ce champ. Et puis vous devez effectuer une analyse au niveau des bits et des octets. C'est un travail exigeant. Mais, étant donné la nature particulière de la situation d'écriture, la désérialisation personnalisée peut en valoir la peine. C'est une question de coût par rapport aux avantages.

Définition des procédures

Au cœur de gRPC est l'idée que les clients appellent des procédures (fonctions a.k.a) directement selon la définition de procédure décrite dans le .proto fichier. gRPC spécifie que les procédures sont regroupées sous une unité d'organisation appelée service. Le listing 4 ci-dessous décrit un service nommé SimpleService. Le listing 4 est un extrait du .proto fichier répertorié ci-dessus dans la liste 1.

service SimpleService {
   rpc Add (Request) returns (Response) { }
   rpc Subtract (Request) returns (Response) { }
   rpc Multiply (Request) returns (Response) {}
   rpc Divide (Request) returns (Response) { }
   rpc Chatter (ChatterRequest) returns (stream ChatterResponse) {}
   rpc Blabber (stream BlabberRequest) returns (stream BlabberResponse) { }
   rpc Ping (PingRequest) returns (PingResponse) { }
}

Liste 4: Les méthodes qui composent le service, SimpleService

Un service gRPC est défini dans le .proto fichier utilisant le mot réservé un service suivi du nom du service. Ensuite, les méthodes du service sont placées entre deux accolades. Chaque méthode du service est précédée du mot réservé rpc suivi du nom de la méthode et du type de message d'entrée. Le type de message d'entrée est suivi du mot réservé Retour suivi du type de message à renvoyer par la procédure. Si le type de message d'entrée doit être soumis dans un flux, le travail réservé courant précède la déclaration du type de message d'entrée. La même chose est vraie si la méthode doit renvoyer des valeurs dans un flux.

Prenons un exemple concret. Le code ci-dessous montre la déclaration pour le SimpleService méthode Blabber tiré du Listing 4 ci-dessus.

 rpc Blabber (stream BlabberRequest) returns (stream BlabberResponse) { }

rpc est un gRPC un mot réservé indiquant une méthode gRPC

Blabber est le nom de la méthode défini par le programmeur

(flux BlabberRequest) indique que les instances d'un BlabberDemande le type de message sera soumis dans un flux au serveur. (Le BlabberDemande Le message est défini dans le listing 1 présenté au début de cet article.)

Retour est un gRPC un mot réservé indiquant que le type de retour doit suivre

(flux BlabberResponse) indique que les instances d'un BlabberResponse le type de message sera renvoyé dans un flux du serveur. (Le BlabberResponse message est également défini dans le listing 1 présenté au début de cet article.)

Sachez que l'exemple ci-dessus illustre une méthode qui soumet des données au serveur dans un flux, puis renvoie également les données du serveur dans un flux. Cependant, les données peuvent être soumises sous la forme d'une simple demande accompagnée d'une réponse comme indiqué dans le code suivant pour la méthode Ping qui est tirée du Listing 4 ci-dessus.

rpc Ping (PingRequest) returns (PingResponse) { }

Dans ce cas, le Ping méthode envoie une instance du type de message PingRequest au serveur gRPC et le serveur renvoie une instance du type de message PingResponse.

Autre fait à noter en termes de définition de service dans un .proto est que la technologie de génération automatique de code ainsi que les bibliothèques et le cadre spécifiques au langage utilisent les procédures définies dans la section service du .proto fichier pour créer un code de procédure standard. L'utilisation d'un code standard réduit le travail de programmation car tout ce qu'un programmeur doit faire est de créer la logique propre à la procédure.

Par exemple, dans l'API gRPC de démonstration qui accompagne cet article et comme indiqué dans le listing 4 ci-dessus, il y a Ajouter(), Soustraire(), Multiplier() et Diviser() procédures définies dans le .proto fichier qui font des procédures mathématiques simples comme leur nom l'indique. Si un générateur de code ou une bibliothèque n'était pas utilisé, le programmeur devrait écrire toute la logique de bas niveau HTTP / 2 et de routage. Cependant, lorsqu'un générateur de code ou une bibliothèque est utilisé, il suffit au programmeur de fournir la logique mathématique. Ainsi, tout ce qu'un programmeur doit faire pour implémenter le Ajouter() La procédure, si Node.js est leur langage de choix, consiste à utiliser la bibliothèque Node.js pour gRPC et à fournir le code comme suit:

function add(call, callback) {
    const input = call.request.numbers;
    const result = input.reduce((a, b) => a + b, 0);
    callback(null, {result});
}

Liste 5

Comme vous pouvez le voir, alors qu'un .proto est une nécessité implicite pour tout travail de développement gRPC, en tirer parti pour faciliter le travail de programmation offre un avantage supplémentaire qui est significatif.

Packages et espaces de noms

La spécification Protocol Buffers fournit un moyen d'organiser les services selon un paquet. UNE paquet est une unité organisationnelle logique qui se trouve dans une variété de langages de programmation et de formats de données. Le terme réel pour un package dans gRPC est paquet. Le langage de programmation Java utilise également le terme paquet comme moyen d'organiser le code sous un nom commun. Deux des packages Java les plus connus sont java.lang et java.io.

.NET d'autre part organise le code en utilisant le terme espace de noms. Système est un espace de noms .NET. le Système namespace contient des classes fréquemment utilisées telles que Console, Tampon et Tuple. C ++ est également un langage de programmation qui utilise le terme espace de noms.

Selon la spécification Protocol Buffers, la façon dont vous déclarez un nom de package dans un fichier .proto consiste à utiliser le mot réservé paquet. le .proto Le fichier affiché dans le listing 1 au début de cet article déclare le package nommé simplegrpc ainsi:

package simplegrpc;

Alors que la spécification Protocol Buffers vous permet de déclarer un nom de package dans le .proto et donc associer implicitement ce package à un service et à des méthodes, la manière dont les méthodes sont concrètement organisées sous un nom de package dans le code est laissée au langage de programmation ou au framework implémentant l'API gRPC particulière.

Maintenant que nous avons couvert l'essentiel du gRPC et des tampons de protocole, examinons comment créer une API gRPC basée sur les types et les méthodes définis dans un .proto fichier.

Créer du code

Il existe trois façons de créer une API gRPC. Une façon est d'utiliser le protocole outil fourni par la CNCF pour générer automatiquement les objets spécifiques au langage qui correspondent aux messages gRPC définis dans le .proto fichier. Ces objets ont une logique de sérialisation et de désérialisation intégrée. Ainsi, vous pouvez les utiliser en conjonction avec un code serveur gRPC associé fonctionnant sous HTTP / 2 pour implémenter l'API gRPC. Pour en savoir plus sur l'utilisation protocole pour générer automatiquement du code gRPC, lisez le ProgrammableWeb article sur le sujet ici.

Une autre façon consiste à utiliser un projet spécifique à un langage qui contient les bibliothèques qui fournissent un serveur HTTP / 2 et effectue les appels de routage vers et depuis les procédures sur le serveur gRPC.ProgrammableWeb fournit un article détaillé sur l'utilisation de frameworks et de bibliothèques pour implémenter une API gRPC ici.

La troisième façon est de partir de zéro et d'écrire l'API à partir de zéro.

Partir de zéro comprend l'écriture non seulement des sérialiseurs et des désérialiseurs pour coder et décoder les messages Protocol Buffers vers et à partir du format binaire, mais cela inclut également l'écriture de tous les mécanismes nécessaires pour acheminer une demande vers la méthode gRPC particulière, puis renvoyer une réponse une fois créée . De plus, si vous travaillez avec des flux, votre code «de départ de zéro» doit prendre en charge le streaming unidirectionnel et bidirectionnel sous HTTP / 2. C'est beaucoup de travail.

Compte tenu de la complexité du démarrage à partir de zéro, l'approche n'est pas typique du monde réel. Cela demande trop d'expertise et de travail juste pour faire des choses simples. L'approche adoptée par la plupart des entreprises consiste à générer automatiquement du code standard ou à créer un code personnalisé qui exploite des bibliothèques préexistantes pour fournir des fonctionnalités spécifiques à gRPC.

Mettre tous ensemble

Le but de cet article a été de fournir une discussion sur les concepts et les pratiques de base liés à l'utilisation de gRPC. Nous avons couvert les 3 différents types d'interactions gRPC: demande / réponse, unidirectionnelle et bidirectionnelle. Nous avons décrit comment gRPC utilise les tampons de protocole pour échanger des données entre le client et le serveur et vice versa. Nous avons décrit le but et la structure du .proto fichier, Le .proto est le «manuel de référence» qui pilote la sérialisation et la désérialisation de gRPC.

Nous avons examiné la structure des messages et des procédures gRPC tels que définis dans un .proto fichier. En outre, nous avons discuté de différentes approches pour créer le code qui implémente une API gRPC telle que définie dans un .proto fichier. Nous avons abordé le code de génération automatique ou la programmation avec des bibliothèques et des frameworks.

À ce stade, vous devez avoir le vocabulaire et la compréhension de base de RPC nécessaires pour comprendre les détails de la prochaine tranche de cette série. Dans le prochain épisode, nous allons examiner comment gRPC est utilisé dans le monde réel. Nous verrons comment diverses entreprises et technologies tirent parti du gRPC pour déplacer les données à la vitesse requise pour répondre aux demandes critiques.

Epilog: comprendre l'API de démonstration

L'API de démonstration gRPC qui accompagne cet article a été créée à l'aide des bibliothèques gRPC Node.js créées par Google. Le projet de démonstration de l'API gRPC s'appelle SimpleService. Le but de SimpleService est de fournir des exemples des blocs de construction de base généralement trouvés dans une API gRPC. L'API est composée des procédures suivantes:

  • Ajouter
  • Soustraire
  • Multiplier
  • Diviser
  • Bavarder
  • Blabber
  • Ping

Les quatre premières procédures, Ajouter, Soustraire, Plusieurs, et Diviser se comportent comme leur nom l'indique. Ils font des opérations mathématiques. Ces méthodes facilitent la communication entre le client et le serveur à l'aide d'une interaction demande / réponse synchrone. La procédure Bavarder est un exemple de streaming unidirectionnel entre serveur et client. La procédure, Blabber, est un exemple de streaming bidirectionnel entre client et serveur. (Nous couvrirons les détails de la diffusion unidirectionnelle et bidirectionnelle plus tard dans cette série.) La méthode Ping est une procédure pratique qui retourne la chaîne qui lui a été transmise à partir d'une demande de lancement. Ping prend en charge la communication synchrone de demande / réponse.

En outre, le projet de démonstration est livré avec un outil CLI que vous pouvez utiliser pour travailler directement avec les procédures de l'API.

Obtenir le code source

Le code source de l'API et de l'outil CLI se trouve dans le projet, simple-node-grpc version 1.0.1, qui se trouve dans le ProgrammableWeb Dépôt GitHub, ici.

Obtenir une expérience pratique

Vous pouvez obtenir une expérience pratique directe en utilisant l'API de démonstration et l'outil client CLI associé en prenant le scénario interactif d'accompagnement sur Katacoda. Ce scénario vous montre comment installer l'API gRPC SimpleService sur une machine virtuelle exécutée sous Katacoda. De plus, vous pouvez utiliser l'outil CLI dédié dans la machine virtuelle Katacoda pour exercer les différentes procédures publiées par l'API.

Capture d'écran de Katacoda

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *