Le mécanisme d’appel de procédure distante (gRPC ou Google Remote Procedure Call) est un cadre open-source très performant pour la mise en œuvre d’API via HTTP/2. Il est conçu pour faciliter la création d’applications distribuées par les développeurs, en particulier lorsque le code peut être exécuté sur différentes machines.
Initialement développé par Google à titre de technologie de mise en œuvre des appels de procédure distante (RPC), le gRPC est aujourd’hui un projet incubé de la Cloud Native Computing Foundation, ce qui signifie qu’il est utilisé en production et qu’il bénéficie du soutien d’un grand nombre de contributeurs.
Pour comprendre pourquoi Google a développé le gRPC, examinons brièvement la chronologie de la conception des API.
Les RPC constituent l’une des méthodes les plus anciennes pour concevoir et fabriquer une API. Ils permettent d’écrire du code comme s’il s’exécutait sur un ordinateur local, même si, en réalité, vous appelez un service fonctionnant sur une machine différente (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 liés au système sous-jacent, ce qui les rend difficiles à intégrer et à modifier, et plus susceptibles de laisser filtrer des détails sur le système.
Le lancement de l’architecture API REST a permis de résoudre certains de ces problèmes en fournissant 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 plus d’informations sur le réseau (par exemple, où envoyer une requête), de sorte qu’elles ne sont pas aussi légères et efficaces que les RPC.
En adoptant des technologies plus récentes, le gRPC met à jour l’ancienne méthode RPC pour la rendre interopérable et plus efficace. Aujourd’hui, c’est un choix intéressant lors du développement d’API pour les architectures microservices.
Voici quelques-uns des avantages du gRPC :
Dans l’ensemble, le gRPC offre un cadre performant et flexible, idéal pour les communications inter-services dans les architectures microservices hautement distribuées.
Les avantages et les bénéfices du gRPC découlent en grande partie de l’adoption de deux technologies :
Le gRPC utilise des tampons de protocole (ou Protobufs) pour définir les services et les messages au lieu de XML ou JSON. Il s’agit d’un mécanisme indépendant du langage pour sérialiser les messages structurés que les services s’envoient les uns aux autres.
Semblable au concept de spécification OpenAPI pour les API REST, le contrat API dans le gRPC est mis en œuvre dans un fichier texte .proto dans lequel le développeur définit la manière dont il souhaite que les données soient structurées. Ensuite, un compilateur de protocole compile automatiquement le fichier texte .proto dans n’importe quel langage pris en charge. Au moment de l’exécution, les messages sont compressés et envoyés dans un format binaire.
Cela présente deux avantages essentiels :
Traditionnellement, les API REST utilisent HTTP/1.1 comme couche de transport. Bien que les API REST puissent également être fournies via HTTP/2, l’utilisation exclusive de HTTP/2 par gRPC présente certains avantages clés. L’un de ces avantages est la possibilité d’envoyer des communications en binaire. En outre, HTTP/2 permet de traiter plusieurs demandes en parallèle au lieu de traiter une demande à la fois. La communication est également bidirectionnelle, ce qui signifie qu’une seule connexion peut envoyer à la fois des demandes et des réponses en même temps.
Dans l’ensemble, 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 active. Il existe toutefois certaines limites. HTTP/2 n’est généralement pas pris en charge par les navigateurs web modernes, il se peut donc que vous deviez utiliser un proxy inverse tel que NGINX pour fournir l’application.
REST étant aujourd’hui le style de conception d’API le plus dominant, il constitue un point de comparaison utile pour gRPC. REST et gRPC sont tous deux des approches valables pour construire des API pour les applications web et les microservices. L’une n’est pas nécessairement meilleure que l’autre. Cela dit, il est utile de comprendre leurs principales différences pour choisir le meilleur outil pour une tâche donnée.
Certaines des principales différences entre gRPC et REST relèvent de ces catégories :
Si les API REST peuvent tirer parti de HTTP/2, les services RESTful utilisent traditionnellement le protocole textuel HTTP/1.1 comme couche de transport. Le gRPC utilise exclusivement HTTP/2, un protocole binaire plus efficace qui permet des fonctionnalités telles que la compression des en-têtes et le multiplexage sur une seule connexion TCP.
Les API REST utilisent généralement JSON comme format de données pour l’envoi et la réception de données. JSON est basé sur du texte, facile à lire et à écrire, et largement pris en charge. Les API gRPC utilisent des Protobufs, qui sont dans un format binaire offrant une charge utile plus petite et une interaction plus rapide. Cependant, les Protobufs ne peuvent pas être facilement lus seuls.
Les API REST prennent en charge un modèle de demande-réponse avec une prise en charge limitée de la diffusion en continu. En revanche, les API gRPC sont fournies sur HTTP/2 et prennent en charge plusieurs modèles de communication, notamment Unary (demande-réponse), la diffusion sur serveur et sur client et la diffusion bidirectionnelle.
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 demande doit contenir toutes les informations nécessaires à son traitement. En outre, le contrat API est généralement rédigé à l’aide de la spécification OpenAPI, le codage du client et du serveur étant traité comme une étape distincte. En revanche, le 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 du code à la fois pour le client et le serveur de l’API.
REST peut être plus lent en raison de la transmission de données textuelles via HTTP/1.1. Chaque requête nécessite une connexion TCP, ce qui peut entraîner une certaine latence. Le gRPC prend en charge des flux multiples via HTTP/2, de sorte que plusieurs clients peuvent envoyer plusieurs requêtes en même temps sans établir de nouvelle connexion TCP. Il tire également parti des fonctionnalités HTTP/2, telles que la compression des en-têtes.
REST utilise les codes d’état HTTP standard pour la gestion des erreurs. En revanche, le gRPC offre une granularité beaucoup plus grande pour définir les codes d’état d’erreur et garantir leur cohérence. Par défaut, le modèle gRPC est assez limité, mais il est généralement étendu à l’aide d’un modèle d’erreur plus riche mis au point par Google.
Bien que largement pris en charge par presque tous les langages, REST ne propose aucune fonction de génération de code intégrée. La mise en œuvre est entièrement laissée au développeur. Grâce à son compilateur de protocole, le gRPC permet la génération de code natif pour de nombreux langages de programmation.
En résumé, le choix entre gRPC et REST dépend de la tâche à accomplir. Le gRPC fournit une méthode efficace et performante pour que les services communiquent dans une application distribuée. Cependant, il ne peut pas être lu directement par les navigateurs web et d’autres clients, et nécessite une passerelle API ou un proxy inverse comme NGINX pour interagir avec les clients frontaux. C’est une excellente option pour les API internes qui font partie d’une architecture de microservices axée sur les événements.
REST, en revanche, est largement adopté et pris en charge dans pratiquement tous les langages. Il est lisible par l’homme et par la machine puisque les données sont échangées via JSON ou XML. En outre, sa courbe d’apprentissage est beaucoup plus faible et il est pris en charge par de nombreux navigateurs web, ce qui en fait la solution idéale pour les API exposées au public.
Le gRPC est l’une des meilleures options de communication dans une architecture de microservices. Cela est dû en partie aux performances, mais aussi à la flexibilité de la prise en charge de langage. Les développeurs peuvent facilement construire et générer des clients et des serveurs gRPC qui fonctionnent dans leur langage préféré. Comme le gRPC décrit le contrat API dans un format binaire, les microservices peuvent communiquer indépendamment des langages utilisés pour les construire.
L’une des architectures de microservices gRPC les plus courantes consiste à placer une passerelle API en amont des microservices et à gérer toutes les communications internes via gRPC. La passerelle API traite les demandes entrantes provenant de HTTP/1.1 et les transmet par procuration aux microservices en tant que demandes gRPC via HTTP/2.
Comme l’adoption de gRPC continue de croître, les développeurs et les équipes chargées des opérations de sécurité doivent s’assurer que des solutions de sécurité efficaces sont en place. Les messages gRPC étant au format binaire, des problèmes peuvent survenir pour les appareils et les outils qui s’attendent à voir des communications basées sur le format ASCII.
Les API gRPC sont également vulnérables à la plupart des menaces les plus courantes en matière de sécurité des API. Les pratiques standard en matière de sécurité des API, telles que le contrôle d’accès, le chiffrement et la protection de l’exécution, sont tout aussi importantes dans les architectures basées sur les API gRPC.
Les applications et les API gRPC nécessitent une approche holistique de la sécurité. Voici quelques-unes des meilleures pratiques pour sécuriser les applications gRPC :
Enfin, vous devez vérifier que la passerelle API, le pare-feu d’applications web (WAF) et les autres outils de gestion et de sécurité des API sont en mesure de protéger vos applications et les API gRPC en production. Ils doivent pouvoir importer le fichier .proto pour chaque service et l’utiliser pour appliquer des protections de sécurité à l’application et aux API gRPC.
Le gRPC gagne beaucoup de terrain en tant qu’alternative populaire pour les développeurs et les grandes entreprises telles que Netflix et Lyft dans les architectures de microservices. Cela dit, il ne remplace pas les API REST et il ne constitue pas non plus la meilleure façon de construire des API. Le gRPC est simplement une alternative à considérer si vous construisez principalement des API pour un environnement de microservices interne et que vous avez besoin d’une communication efficace et en temps réel.
À l’avenir, le gRPC continuera probablement à gagner du terrain pour les applications cloud natives en raison de ses avantages en termes de performances et de facilité de développement. Parallèlement, les développeurs qui ont besoin d’exposer publiquement des API continueront à utiliser REST dans leurs applications. REST continuera également à exister dans les environnements cloud natifs en raison de sa rétrocompatibilité et de son intégration profonde avec l’infrastructure et les opérations d’API existantes.
NGINX offre une variété de ressources gratuites pour vous aider à chaque étape de votre parcours gRPC.