Qu’est-ce que gRPC ?

Google Remote Procedure Call (gRPC) est un framework open source haute performance permettant d’implémenter des API via HTTP/2. Il est conçu pour faciliter le développement d’applications distribuées, notamment lorsque le code est susceptible de s’exécuter sur différentes machines.

gRPC a été initialement développé par Google comme une technologie permettant de mettre en œuvre des appels de procédure à distance (RPC). Aujourd’hui, gRPC est un projet incubé par la Cloud Native Computing Foundation, ce qui signifie qu’il est utilisé en production et bénéficie du soutien d’une communauté active de contributeurs.

Pourquoi gRPC a-t-il été créé ?

Pour comprendre pourquoi Google a développé gRPC, revenons brièvement sur l’évolution de la conception des API .

RPC est l’une des plus anciennes méthodes de conception et de création d’une API. Les RPC vous permettent d’écrire du code comme s’il devait s’exécuter sur un ordinateur local, même si vous appelez en réalité un service exécuté sur une autre machine (généralement sur votre réseau local).

En pratique, cela permet aux développeurs d’utiliser des actions directes (comme SendUserMessages, addEntry, etc.) sans avoir à tenir compte des détails du réseau. Les messages RPC sont légers et efficaces, mais ils sont également étroitement couplés au système sous-jacent. Ils sont donc difficiles à intégrer et à modifier, et risquent davantage de divulguer des informations sur le système.

Lorsque l’architecture API REST a été introduite, elle a permis de résoudre certains de ces problèmes en offrant un moyen uniforme d’accéder aux données et aux ressources à l’aide de méthodes HTTP génériques telles que GET, POST, PUT et DELETE. Bien que REST simplifie l’accès aux données, l’API renvoie souvent plus de métadonnées que nécessaire. Les API REST nécessitent également davantage d’informations sur le réseau (notamment l’adresse à laquelle envoyer une requête) ; elles sont donc moins légères et moins efficaces que les RPC.

Quels sont les avantages de gRPC ?

En adoptant des technologies plus récentes, gRPC modernise l’ancienne méthode RPC afin de la rendre interopérable et plus efficace. Aujourd’hui, il s’agit d’un choix intéressant pour développer des API destinées aux architectures de microservices .

Voici quelques-uns des avantages de gRPC :

Performances – gRPC utilise HTTP/2 comme protocole de transport et Protocol Buffers par défaut, ce qui peut offrir de meilleures performances que les communications REST et JSON.
Streaming – gRPC prend en charge le streaming de données pour les architectures événementielles, notamment le streaming côté serveur, le streaming côté client et le streaming bidirectionnel, qui permet d’envoyer simultanément les requêtes du client et les réponses du serveur.
Interopérabilité – gRPC prend en charge un large éventail de langages de programmation avec génération de code intégrée, notamment C++, Java, Python, PHP, Go, Ruby, C#, Node.js, et bien d’autres.
Sécurité – gRPC fournit des mécanismes modulaires d’authentification et de traçage, ainsi que de répartition de charge et de contrôle d’intégrité afin d’améliorer la sécurité et la résilience.
Cloud native – gRPC fonctionne parfaitement avec les déploiements basés sur des conteneurs et est compatible avec les technologies cloud modernes telles que Kubernetes et Docker.

Dans l’ensemble, gRPC offre un framework flexible et hautement performant, idéal pour les communications entre services dans les architectures de microservices fortement distribuées.

Comprendre gRPC : concepts de base

Les avantages et les bénéfices de gRPC découlent en grande partie de l’adoption de deux technologies :

Protocol Buffers pour structurer les messages
HTTP/2 comme couche de transport

Protocol Buffers pour structurer les messages

gRPC utilise Protocol Buffers (ou Protobufs) pour définir les services et les messages à la place de XML ou JSON. Il s’agit d’un mécanisme indépendant du langage permettant de sérialiser les messages structurés que les services s’échangent.

À l’instar du concept de la spécification OpenAPI pour les API REST, le contrat d’API dans gRPC est implémenté dans un fichier texte .proto, dans lequel le développeur définit la structure souhaitée pour les données. Un compilateur protoc compile ensuite automatiquement le fichier texte .proto dans n’importe quel langage pris en charge. Lors de l’exécution, les messages sont compressés et envoyés au format binaire.

Cela présente deux avantages majeurs :

gRPC sollicite moins le processeur, car les données sont représentées au format binaire, ce qui réduit la taille des messages.
Le schéma est clairement défini afin de garantir un échange fluide des messages entre le client et le serveur, ce qui réduit les erreurs.

HTTP/2 comme couche de transport

Traditionnellement, les API REST utilisaient HTTP/1.1 comme couche de transport. Bien que les API REST puissent également être proposées via HTTP/2, l’utilisation exclusive de HTTP/2 par gRPC présente plusieurs avantages majeurs. L’un d’eux est la possibilité de transmettre les communications au format binaire. En outre, HTTP/2 permet de traiter plusieurs requêtes en parallèle au lieu de les gérer une par une. La communication est également bidirectionnelle, ce qui signifie qu’une même connexion peut envoyer simultanément des requêtes et des réponses.

Globalement, cela améliore les performances et réduit l’utilisation du réseau, ce qui peut s’avérer particulièrement utile dans une architecture de microservices très sollicitée. Il existe toutefois certaines limites. HTTP/2 n’est généralement pas pris en charge par les navigateurs web modernes. Vous devrez donc peut-être utiliser un proxy inverse tel que NGINX pour distribuer l’application.

gRPC vs REST : comparaison

Aujourd’hui, REST est le style de conception d’API le plus répandu. Il constitue donc un point de référence utile pour établir une comparaison avec gRPC. REST et gRPC sont deux approches valables pour créer des API destinées aux applications web et aux microservices, et aucune n’est nécessairement meilleure que l’autre. Cela dit, il est utile de comprendre leurs principales différences afin de choisir l’outil le mieux adapté à chaque situation.

Certaines des principales différences entre gRPC et REST relèvent des catégories suivantes :

Protocole
Format des données
Diffusion en continu
Conception d’API
Performances
Gestion des erreurs
Prise en charge des langues

Protocole

Bien que les API REST puissent tirer parti de HTTP/2, les services RESTful utilisent traditionnellement le protocole textuel HTTP/1.1 comme couche de transport. gRPC utilise exclusivement HTTP/2, un protocole binaire plus efficace qui permet notamment la compression des en-têtes et le multiplexage sur une seule connexion TCP.

Format des données

Les API REST utilisent généralement JSON comme format de données pour envoyer et recevoir des données. JSON est un format textuel, facile à lire et à écrire, et largement pris en charge. Les API gRPC utilisent des Protobufs, un format binaire qui permet de réduire la taille des données transmises et d’accélérer les échanges. Cependant, les Protobufs ne sont pas facilement lisibles tels quels.

Streaming

Les API REST prennent en charge un modèle requête-réponse avec une prise en charge limitée du streaming. À l’inverse, les API gRPC utilisent HTTP/2 et prennent en charge plusieurs modes de communication, notamment le mode unaire (requête-réponse), le streaming côté serveur, le streaming côté client et le streaming bidirectionnel.

Conception d’API

REST est un modèle centré sur les ressources qui prend en charge les méthodes HTTP standard telles que GET, POST, PUT et DELETE. Chaque requête doit contenir toutes les informations nécessaires à son traitement. En outre, le contrat d’API est généralement rédigé à l’aide de la spécification OpenAPI, le développement du client et du serveur étant considéré comme une étape distincte. À l’inverse, gRPC est un modèle centré sur les services, dans lequel les messages et les services sont définis dans le fichier .proto. Ce fichier peut être utilisé pour générer le code du client et du serveur de l’API.

Performances

REST peut être plus lent en raison de la transmission de données au format texte via HTTP/1.1. Chaque requête nécessite une négociation TCP, ce qui peut entraîner une certaine latence. gRPC prend en charge plusieurs flux via HTTP/2, permettant ainsi à plusieurs clients d’envoyer simultanément plusieurs requêtes sans établir de nouvelle connexion TCP. Il tire également parti de fonctionnalités de HTTP/2 telles que la compression des en-têtes.

Gestion des erreurs

REST utilise les codes d’état HTTP standard pour la gestion des erreurs. En revanche, gRPC offre une granularité bien plus fine pour définir les codes d’état des erreurs et garantir leur cohérence. Par défaut, le modèle gRPC est assez limité, mais il est le plus souvent étendu à l’aide d’un modèle d’erreur développé par Google.

Prise en charge des langages

REST est largement pris en charge par la quasi-totalité des langages, mais n’intègre aucune fonctionnalité de génération de code. Sa mise en œuvre est entièrement laissée à la charge du développeur. Grâce à son compilateur protoc, gRPC permet de générer nativement du code pour plusieurs langages de programmation.

Faut-il utiliser gRPC plutôt que REST ?

En résumé, le choix entre gRPC et REST dépend de vos objectifs. gRPC offre aux services un moyen efficace et performant de communiquer au sein d’une application distribuée. Cela dit, il ne peut pas être interprété directement par les navigateurs web et autres clients, et nécessite une passerelle API ou un proxy inverse tel que NGINX pour interagir avec les clients front-end. C’est une excellente option pour les API internes qui s’inscrivent dans une architecture de microservices pilotée par les événements.

REST, en revanche, est largement adopté et pris en charge dans pratiquement tous les langages. Il est lisible aussi bien par les humains que par les machines, puisque les données sont échangées au format JSON ou XML. De plus, sa prise en main est beaucoup plus facile et il est pris en charge par de nombreux navigateurs web, ce qui le rend idéal pour les API accessibles au public.

Architecture de microservices gRPC

gRPC est l’une des meilleures solutions pour assurer la communication au sein d’une architecture de microservices. Cela s’explique en partie par ses performances, mais aussi par sa prise en charge flexible de nombreux langages. Les développeurs peuvent facilement créer et générer des clients et des serveurs gRPC qui s’exécutent dans le langage de leur choix. Comme gRPC décrit le contrat d’API dans un format binaire, les microservices peuvent communiquer indépendamment des langages utilisés pour les développer.

L’une des architectures de microservices basées sur gRPC les plus courantes consiste à placer une passerelle API devant les microservices, puis à gérer toutes les communications internes via gRPC. La passerelle API traite les requêtes entrantes via HTTP/1.1 et les transmet aux microservices sous forme de requêtes gRPC via HTTP/2.

Problématiques de sécurité liées à gRPC

À mesure que l’adoption de gRPC se généralise, les développeurs et les équipes chargées des opérations de sécurité doivent veiller à mettre en place des solutions de sécurité efficaces. Les messages gRPC étant au format binaire, des problèmes peuvent survenir avec les appareils et les outils conçus pour traiter des communications au format ASCII.

Les API gRPC sont également vulnérables à bon nombre des menaces de sécurité les plus courantes visant les API. Les pratiques standard de sécurité des API, telles que le contrôle d’accès, le chiffrement et la protection à l’exécution, sont tout aussi importantes dans les architectures basées sur gRPC.

Recommandations de sécurité pour gRPC

La sécurité des applications et des API gRPC nécessite une approche globale. Voici quelques-unes des bonnes pratiques permettant de sécuriser les services gRPC :

Validation du schéma – Bloquez les tentatives d’exploitation malveillantes en vérifiant que chaque champ du message gRPC présente le type correct et le contenu attendu.
Masquage des données – Masquez ou bloquez les données sensibles, telles que les numéros de carte bancaire et les numéros de sécurité sociale, afin d’empêcher qu’elles ne quittent le système.
Limitation du débit – Appliquez des limites strictes à la taille et au nombre de requêtes afin d’empêcher les attaques par déni de service (DoS) visant à épuiser les ressources.
Contrôle d’accès – Exigez une authentification et une autorisation avant d’accorder au client l’accès au service.
Chiffrement – Sécurisez les messages en transit à l’aide du protocole Transport Layer Security (TLS).

Enfin, vous devez vérifier que votre passerelle API, votre pare-feu d’applications web (WAF) et vos autres outils de gestion et de sécurité des API sont en mesure de protéger vos applications et API gRPC en production. Ils doivent pouvoir importer le fichier .proto de chaque service et l’utiliser pour appliquer des mesures de sécurité à l’application et aux API gRPC.

Résumé

gRPC gagne fortement en popularité auprès des développeurs et de grandes entreprises comme Netflix et Lyft qui l’utilisent dans des architectures de microservices. Cela dit, gRPC ne remplace pas les API REST et ne constitue pas intrinsèquement une meilleure façon de créer des API. gRPC est simplement une solution à envisager si vous développez principalement des API pour un environnement interne de microservices et avez besoin de communications efficaces en temps réel.

À l’avenir, gRPC devrait continuer à gagner du terrain dans les applications cloud natives grâce à ses performances et à sa facilité de développement. Parallèlement, les développeurs qui doivent exposer publiquement des API continueront à utiliser REST dans leurs applications. REST restera également présent dans les environnements cloud natifs en raison de sa rétrocompatibilité et de son intégration étroite avec les infrastructures et les opérations d’API existantes.

Contenu associé