Qu’est-ce que gRPC ?

Le RPC, ou appel de procédure à distance, est un modèle de communication pour l’interaction client/serveur qui permet aux appels à distance d’apparaître et de fonctionner comme des appels locaux. Il s’agit d’une technique plus ancienne, qui remonte conceptuellement aux années 1970, avec des applications initiales vues dans des projets informatiques pionniers tels que l’ARPANET et le Xerox PARC.

Dans un RPC, le client interagit avec une représentation du serveur, qui semble locale, mais qui est en fait un intermédiaire. Cet intermédiaire, communément appelé stub, est chargé de gérer les données de marshalling et de non-marshalling (c’est-à-dire la conversion des données dans un format adapté à la transmission et la conversion des résultats reçus du serveur dans leur format d’origine). Comme il s’agit d’un style d’architecture pour la communication client/serveur, il est couramment utilisé dans la conception des API.

Il existe de nombreuses implémentations différentes de cadres RPC, notamment XML-RPC et JSON-RPC. Ces implémentations utilisent HTTP comme protocole de transport, différant principalement par le type de format. Depuis les années 1990 et 2000, ces mises en œuvre ont mis en évidence les points forts du RPC : elles simplifient le développement, font abstraction des complexités de la communication réseau, sont légères, relativement simples à utiliser et lisibles par l’homme.

Cependant, de nombreux environnements modernes, en particulier ceux qui utilisent des architectures de microservices, des environnements polyglottes et des systèmes avec des charges de données élevées, ont besoin d’un cadre des exigences plus rapide et à haute performance pour connecter des applications. Dans l’idéal, ce cadre des exigences facilite un transfert de données plus efficace, en temps réel, entre les services exécutés dans différents environnements et centres de données.

gRPC a été développé pour répondre à ce besoin, offrant une faible latence et un débit élevé grâce à la sérialisation des données et il utilise le protocole HTTP/2, les capacités de diffusion bidirectionnelle, la génération de code, etc.

gRPC a été initialement publié en 2015, la même année que la version HTTP/2. Il répond aux limitations des anciennes implémentations RPC principalement en utilisant les tampons de protocole, ou Protobuf, son langage de définition d’interface (IDL). Protobuf sérialise et encode les données structurées en binaire. Les données sont ainsi plus compactes, ce qui permet une transmission plus rapide et des performances supérieures.

Protobuf permet également de modifier les champs de données sans perturber le code. Cela permet de réduire les erreurs et de partager et traiter les données en temps réel. Ces caractéristiques font des API créées avec gRPC une option fiable pour les environnements distribués modernes, les architectures de microservices, les applications de streaming et pour connecter les systèmes et appareils de l’Internet des objets.

Cela donnerait un sens si gRPC était l’abréviation de « Google Remote Procedure Call ». Mais l’équipe gRPC de grPC.io affirme avec humour qu’il s’agit de « gRPC Remote Procedure Call ». Son GitHub précise que le « g » signifie quelque chose de différent à chaque version (allant de « gregarious » à « goose » à « Guadalupe River Park Conservancy »). Quoi qu’il en soit, Google a développé gRPC et l’a publié en tant que projet open source en 2015.

gRPC présente une version moderne et mise à jour de RPC, avec une prise en charge des langages modernes et des fonctionnalités et optimisations supplémentaires. Ses fonctionnalités incluent :

• Un langage de conception d’interface (IDL) appelé Protocol Buffers
• Utilisation de HTTP/2 pour la transmission de données
• Streaming bidirectionnel
• Génération de code
• Quatre types de méthodes
• Intégration à la sécurité basée sur TLS
• Prise en charge des intercepteurs pour la journalisation, le traçage, l’authentification, etc.

Protocol Buffers, communément appelé Protobuf, est un format de données multiplateforme développé par Google et utilisé pour sérialiser des données structurées. En effet, il sert d’intermédiaire puissant entre le client et le serveur qui sérialise les demandes en code binaire pour les transmettre.

Ce mécanisme est flexible et efficace et permet l’indépendance vis-à-vis du langage de programmation, la réduction de la taille des messages et l’accélération de l’analyse et de la transmission, en même temps. Une application qui utilise Java peut communiquer avec une application qui utilise Python, car la requête est convertie en dans un langage commun binaire. Bien qu’ils ne soient pas lisibles par les humains, les fichiers binaires sont plus rapides à transmettre et à décoder avec des ordinateurs qu’un format textuel tel que JSON.

En d’autres termes, les développeurs créent un fichier texte avec le suffixe « .proto » qui contient toutes les informations sur la structure des données. Ces informations sont basées sur des schémas, ce qui signifie qu’elles définissent les paramètres, les méthodes et les sorties possibles, une description de la structure des données. Par exemple, vous pouvez avoir une entrée pour « utilisateur », qui note que ces données incluront « nom », « adresse e-mail » et « pizza préférée ».

D’après la documentation de Protobuf, c’est comme le XML, « mais plus petit, plus rapide et plus simple. Vous définissez comment vous souhaitez que vos données soient structurées une fois, puis vous pouvez utiliser un code source spécialement généré pour écrire et lire facilement vos données structurées vers et à partir de divers flux de données et en utilisant une variété de langages. » En tant qu’intermédiaire, Protobuf permet également l’installation de diverses mesures d’authentification et de sécurité.

Les développeurs peuvent utiliser un compilateur, appelé Protoc, pour générer du code dans n’importe lequel des langages pris en charge, notamment C#, C++, Dart, Go, Java, Kotlin, Node.js, Objective-C, PHP, Python et Ruby. Ce code remplit de nombreuses fonctions : il comprend généralement des classes ou des modules, gère la sérialisation en binaire et la désérialisation du binaire et élimine les complexités de l’échange de données. Les développeurs n’ont pas à se soucier du conditionnement réseau, du marshalling, des mises à jour de compatibilité et de l’implémentation ; Protobuf s’occupe de tout.

La conception basée sur des schémas de Protobuf permet aux développeurs d’ajouter de nouveaux champs de données aux structures existantes sans casser l’ensemble du système. Il réduit également considérablement les efforts nécessaires pour mettre à jour, maintenir et gérer les tâches fastidieuses liées aux API, telles que l’ajustement du code antérieur après l’ajout de nouveaux champs de données. Cela dit, les fichiers .proto peuvent mobiliser beaucoup de temps et d’efforts.

HTTP/2 est un protocole de transport (une méthode que les ordinateurs et les serveurs utilisent pour échanger des informations) qui utilise un format binaire pour envoyer des messages, qui réduit les connexions TCP et utilise la compression des en-têtes, ce qui le rend plus rapide et plus efficace que son prédécesseur ( HTTP/1.1). Il permet également le multiplexing, c’est-à-dire la possibilité d’envoyer plusieurs flux simultanés sur une seule connexion. gRPC utilise ce qu’on appelle des canaux pour permettre plusieurs flux sur ces connexions multiples. Les messages sont envoyés sous forme de trames de données HTTP/2, chacune pouvant contenir plusieurs messages gRPC.

gRPC offre un streaming bidirectionnel, dans lequel le client et le serveur peuvent envoyer des messages dans un flux de lecture/écriture de manière indépendante. Cette méthode permet autorise une grande flexibilité : un serveur et un client peuvent échanger des réponses de manière séquentielle, ou un serveur peut attendre que tous les messages du client aient été reçus avant de répondre. Cette fonctionnalité peut être ajustée selon des applications spécifiques.

gRPC utilise un outil de compilation appelé protoc pour générer automatiquement le code client et le code serveur dans différents langages, en fonction des définitions de service et des structures de message définies dans un fichier .proto. Les plug-ins peuvent être utilisés pour étendre la prise en charge de nombreux autres langages.

Protoc génère des classes d’accès aux données dans le langage défini dans la définition de Proto. Ces classes fournissent des accesseurs simples pour les champs tels que [nom], ainsi que des méthodes pour sérialiser et analyser la structure vers et depuis les octets bruts.¹

gRPC prend en charge quatre types de méthodes différents pour la transmission de données : unaire, streaming côté client, streaming côté serveur et streaming bidirectionnel.

gRPC dispose d’une intégration intégrée avec TLS (Transport Layer Security), qui chiffre les échanges de données entre les clients et le serveur et permet aux utilisateurs de sécuriser les connexions.

gRPC prend en charge l’authentification, le traçage, la journalisation, les indicateurs, l’équilibrage de charge, le contrôle de la santé, etc. 

gRPC dispose de quatre types de méthodes différents, qui indiquent comment un message est envoyé et reçu par un client gRPC et un serveur gRPC. Ces types sont les suivants :

Unaire : un appel simple au cours duquel un client envoie une seule requête et un serveur répond avec une seule réponse.

Streaming côté serveur : un appel au cours duquel un client envoie une requête, mais le serveur répond avec plusieurs réponses.

Streaming côté client : un appel dans lequel un client envoie plusieurs requêtes et un serveur répond avec une seule réponse. Le serveur peut choisir d’attendre que l’ensemble du flux de demandes des clients s’arrête avant de traiter et de répondre.

Streaming bidirectionnel : le client et le serveur envoient tous deux plusieurs appels simultanément, ce qui permet une communication en temps réel.

gRPC et REST sont tous deux des styles d’architecture couramment utilisés dans la conception d’API. Ils présentent de nombreuses similitudes : les deux suivent une architecture client/serveur, s’appuient sur une communication basée sur HTTP, sont sans état et compatibles avec tout les langages. Mais ils diffèrent également de manière essentielle, ce qui les rend utiles pour différents cas d’utilisation.

Format de données : les API REST utilisent des formats de texte brut tels que JSON et XML. gRPC utilise Protobuf pour encoder les données en binaire.

Modèle de communication : gRPC prend en charge quatre méthodes : unaire, streaming sur serveur, streaming client et streaming bidirectionnel. REST utilise un système unifié de requête et de réponse.

Génération de code : gRPC offre une génération de code intégrée, ce qui n’est pas le cas de REST, bien que des modules d’extension soient disponibles.

Modèle de conception : gRPC a une conception orientée service, dans laquelle les opérations de serveur appelables sont définies comme des services ou des fonctions. Dans REST, la conception est orientée ressources, dans laquelle les méthodes HTTP sont utilisées pour accéder aux ressources du serveur via des points de terminaison définis par des URL.

Protocole : gRPC utilise HTTP/2, tandis que REST s’appuie sur HTTP/1.1.

Couplage : le client et le serveur de gRPC sont étroitement liés, ce qui signifie que le client et le serveur doivent avoir accès au même fichier prototype du middleware. Tout changement dans l’un implique un changement dans l’autre. REST est couplé de manière souple. Cette indépendance signifie que les changements dans un composant n’affectent pas l’autre.

gRPC est souvent utilisé pour les API complexes qui connectent plusieurs services dans un environnement distribué. Sa capacité de diffusion en temps réel et ses hautes performances font de gRPC un bon choix pour plusieurs cas d’utilisation, notamment les microservices, la diffusion en continu et la connexion des clients de l’Internet des objets.

En raison de sa performance, de sa faible latence, de sa capacité à gérer de grands volumes de données et de sa capacité de diffusion bidirectionnelle en temps réel, gRPC est souvent utilisé pour créer des API pour les microservices.

Comme gRPC est indépendant du langage, il peut permettre la communication entre des services écrits dans différents langages de programmation. En outre, les définitions Protobuf fournissent un schéma fortement typé qui permet de protéger l’intégrité des données des microservices.

Les capacités de diffusion bidirectionnelle de gRPC signifient qu’il peut simultanément diffuser des données dans les deux directions entre le client et le serveur via une seule connexion réseau. Cette capacité fait de gRPC une option idéale pour les processus continus tels que les vidéoconférences ou lorsqu’un utilisateur souhaite utiliser une partie d’un jeu de données pendant que d’autres données sont en cours de transfert.

L’Internet des objets fait référence à un réseau d’appareils ou de clients connectés. Les appareils IdO, appelés « objets intelligents », peuvent inclure des appareils « domestiques intelligents » simples, tels que des thermostats, des appareils portables tels que des montres connectées et des vêtements compatibles RFID, ainsi que des machines industrielles et des systèmes de transport complexes.² Les API gRPC sont souvent utilisées pour faciliter l’échange de données cohérente entre ces appareils.

Avec sa prise en charge du streaming bidirectionnel et ses capacités de compatibilité avec les microservices (et son statut de projet CNCF), gRPC est de plus en plus utilisé pour les API cloud natives.

gRPC est utilisé pour générer des bibliothèques clientes dans de nombreux langages de programmation différents. Ces bibliothèques sont générées selon la définition de service fournie dans les fichiers .proto. Une fois le service défini, gRPC génère automatiquement du code client dans le langage de programmation choisi.

Cette fonctionnalité simplifie le travail des développeurs, leur permettant de se concentrer sur la logique d’application plutôt que sur le code de communication de bas niveau.

gRPC offre de nombreux avantages aux entreprises et aux développeurs qui créent des API avec des exigences de performance élevées. Ces avantages comprennent :

Une transmission plus rapide et plus efficace : plusieurs facteurs contribuent aux performances élevées de gRPC. D’une part, la sérialisation Protobuf réduit la taille des messages et les paquets plus petits peuvent être transmis plus rapidement. Le format binaire est également plus efficace que les formats de texte brut tels que JSON ou XML.

De plus, gRPC utilise HTTP/2, qui est plus rapide et plus efficace que HTTP/1.1, ce qui permet de réduire davantage la latence et la consommation de bande passante.

Une plus grande portabilité : comme gRPC utilise des tampons de protocole (un mécanisme de sérialisation indépendant du langage et de la plateforme) pour décrire les structures de données et les interfaces RPC, il peut être utilisé pour permettre la communication entre les services écrits dans différents langages sur différentes plateformes.

Réduction des erreurs d’exécution : Protobuf propose une saisie robuste, ce qui signifie qu’il applique une structure de données ferme et clairement définie. Le typage fort favorise la cohérence et la détection plus rapide des erreurs, réduisant ainsi les risques d’erreurs lors de l’exécution.

Personnalisation flexible : la prise en charge intégrée des middlewares permet la personnalisation et l’ajout de fonctionnalités, telles que des mesures de sécurité et d’authentification ou des outils d’analytique.

Bien que gRPC présente de nombreux avantages, il n’est pas sans poser de problèmes. Dans certains cas, par exemple, les API destinées au public avec des sources de données simples et où la facilité d’utilisation est un critère essentiel, la complexité introduite par gRPC peut être inutile. Les défis du gRPC sont les suivants :

Complexité : définir les structures de message et les services dans les fichiers .proto, comme l’exige gRPC, peut être plus difficile que de travailler avec des formats de texte tels que XML et JSON.

Facilité d’utilisation : gRPC, les tampons de protocole et HTTP/2 peuvent imposer une période d’apprentissage ardue pour les développeurs habitués à travailler avec REST.

Débogage : l peut être difficile d’inspecter, de déboguer et d’enregistrer les applications gRPC car le format binaire n’est pas lisible par l’homme. Certains outils peuvent convertir des fichiers binaires, mais ils nécessitent une étape supplémentaire par rapport à XML ou JSON.

Récence et prise en charge : gRPC n’est pas aussi ancien que les autres styles architecturaux populaires tels que REST et ne dispose pas d’une telle communauté ou d’un tel niveau de prise en charge de la documentation et des plug-ins. En tant que cadre des exigences plus récent, il y a moins d’outils (tels que des outils de scanner de sécurité) disponibles pour gRPC par rapport à certains styles plus établis.

Absence de prise en charge des navigateurs : les navigateurs Web ne prenant pas en charge le protocole gRPC en mode natif, il n’est pas possible d’appeler directement un service gRPC depuis une application basée sur un navigateur. Un moyen de contourner ce problème est d’utiliser un proxy tel que gRPC-Web. gRPC-Web agit essentiellement comme une couche de traduction entre le protocole HTTP et gRPC d’un navigateur.

L’application Web démarre un appel gRPC en utilisant la bibliothèque de clients JavaScript gRPC-Web pour envoyer une requête gRPC adaptée à la compatibilité du navigateur. La requête est envoyée à un serveur proxy qui la convertit en une requête gRPC standard et la transmet au serveur backend gRPC. Le serveur gRPC traite la requête, renvoie une réponse au serveur proxy et le proxy convertit une fois de plus la réponse au format gRPC-Web avant de la transmettre au client.