Google Remote Procedure Call (gRPC) est un framework open source hautes performances pour l'implémentation d'API via HTTP/2. Il est conçu pour permettre aux développeurs de créer plus facilement des applications distribuées, en particulier lorsque le code peut être exécuté sur différentes machines.
gRPC a été initialement développé par Google comme technologie de mise en œuvre d'appels de procédure à distance (RPC). Aujourd'hui, gRPC est un projet incubé de la Cloud Native Computing Foundation , ce qui signifie qu'il est utilisé en production et soutenu par un vivier sain de contributeurs.
Pour comprendre pourquoi Google a développé gRPC, examinons brièvement la chronologie de la conception de l'API .
Le RPC est l'une des méthodes les plus anciennes de conception et de création d'API. Les RPC vous permettent d'écrire du code comme s'il s'exécutait 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 liés au système sous-jacent. Cela les rend difficiles à intégrer, à modifier et plus susceptibles de divulguer des détails sur le système.
Lorsque l’architecture de l’API REST a été introduite, elle a résolu certains de ces défis 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 davantage d'informations sur le réseau (par exemple, où envoyer une requête), elles ne sont donc pas aussi légères et efficaces que les RPC.
En adoptant des technologies plus récentes, gRPC met à jour l’ancienne méthode RPC pour la rendre interopérable et plus efficace. Aujourd’hui, c’est un choix attrayant lors du développement d’API pour les architectures de microservices .
Certains des avantages de gRPC incluent :
Dans l’ensemble, gRPC offre un cadre flexible et hautes performances, idéal pour les communications interservices dans les architectures de microservices hautement distribuées.
Les avantages et bénéfices du gRPC découlent en grande partie de l’adoption de deux technologies :
gRPC utilise des tampons de protocole (ou Protobufs ) pour définir des services et des messages au lieu de XML ou JSON. Il s'agit d'un mécanisme neutre du point de vue du langage permettant de sérialiser les messages structurés que les services s'enverront les uns aux autres.
Similaire au concept de la spécification OpenAPI pour les API REST, le contrat API dans gRPC est implémenté dans un fichier texte .proto où un développeur définit la manière dont il souhaite que les données soient structurées. Ensuite, un compilateur protoc compile 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 dans un format binaire.
Cela présente deux avantages clés :
Traditionnellement, les API REST utilisaient 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 utilisant du binaire. De plus, HTTP/2 prend en charge la possibilité de traiter plusieurs requêtes parallèles au lieu de gérer une requête à la fois. La communication est également bidirectionnelle, ce qui signifie qu'une seule connexion peut envoyer à la fois des requêtes 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 être particulièrement précieux dans une architecture de microservices très fréquentée. Il existe cependant 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 comme NGINX pour diffuser l'application.
Aujourd’hui, REST est le style de conception d’API le plus dominant, il fournit donc un point de référence utile pour comparer avec gRPC. REST et gRPC sont tous deux des approches valables pour créer des API pour les applications Web et les microservices, et 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 le travail.
Certaines des principales différences entre gRPC et REST se répartissent en plusieurs catégories :
Alors que les API REST peuvent tirer parti de HTTP/2, les services RESTful utilisent traditionnellement HTTP/1.1 basé sur du texte comme couche de transport. gRPC utilise exclusivement HTTP/2, un protocole binaire plus efficace qui permet des fonctionnalités telles que la compression d'en-tête 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 qui fournit 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 requête-réponse avec une prise en charge limitée du streaming. En revanche, les API gRPC sont fournies via HTTP/2 et prennent en charge plusieurs modèles de communication, notamment unaire (requête-réponse), le streaming serveur, le streaming client et le streaming bidirectionnel.
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. De plus, 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, gRPC est un modèle centré sur les services où les messages et les services sont définis dans le fichier .proto. Le fichier peut être utilisé pour générer du code pour le client et le serveur API.
REST peut être plus lent en raison de sa transmission de données textuelle via HTTP/1.1. Chaque requête nécessite une négociation TCP qui peut introduire une certaine latence. gRPC prend en charge plusieurs flux sur HTTP/2 afin que plusieurs clients puissent 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 d'en-tête.
REST utilise des codes d'état HTTP standard pour la gestion des erreurs. En revanche, gRPC offre beaucoup plus de granularité 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 le plus souvent étendu à l'aide d'un modèle d'erreur plus riche développé par Google .
REST est largement pris en charge par pratiquement tous les langages, mais ne fournit aucune fonctionnalité de génération de code intégrée. La mise en œuvre est entièrement laissée au développeur. Avec son compilateur protoc, gRPC fournit une génération de code natif pour plusieurs langages de programmation.
En résumé, le choix entre gRPC et REST dépend de ce que vous devez accomplir. gRPC fournit une méthode efficace et performante pour que les services communiquent dans une application distribuée. Cela dit, il ne peut pas être lu directement par les navigateurs Web et 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 pilotée par é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 à l’aide de JSON ou de XML. De plus, sa courbe d’apprentissage est beaucoup plus faible pour démarrer et il est pris en charge par de nombreux navigateurs Web, ce qui le rend idéal pour les API exposées publiquement.
gRPC est l’une des meilleures options de communication dans une architecture de microservices. Cela est dû en partie aux performances, mais aussi à sa flexibilité dans la prise en charge linguistique. Les développeurs peuvent facilement créer et générer des clients et des serveurs gRPC qui s'exécutent dans leur langage préféré. Étant donné que gRPC décrit le contrat API dans un format binaire, les microservices peuvent communiquer indépendamment des langages utilisés pour les créer.
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 gère les requêtes entrantes provenant de HTTP/1.1 et les transmet aux microservices sous forme de requêtes gRPC via HTTP/2.
À mesure que l’adoption de gRPC continue de croître, les développeurs et les équipes d’opérations de sécurité doivent s’assurer que des solutions de sécurité efficaces sont en place. Étant donné que les messages gRPC sont au format binaire, des problèmes peuvent survenir pour les appareils et les outils qui s’attendent à voir des communications basées sur ASCII.
Les API gRPC sont également vulnérables à la plupart des menaces de sécurité des API les plus courantes . Les pratiques de sécurité des API standard telles que le contrôle d’accès, le chiffrement et la protection d’exécution sont tout aussi importantes dans les architectures basées sur gRPC.
Les applications et API gRPC nécessitent une approche holistique de la sécurité. Voici quelques-unes des meilleures pratiques pour sécuriser les gRPC :
En fin de compte, vous devez vérifier que votre passerelle API , votre pare-feu d’application Web (WAF) et vos autres outils de gestion et de sécurité des API sont capables de protéger vos applications gRPC et vos API en production. Ils devraient pouvoir importer le fichier .proto pour chaque service et l’utiliser pour appliquer des protections de sécurité pour l’application gRPC et les API.
gRPC gagne beaucoup de terrain en tant qu'alternative populaire pour les développeurs et les grandes entreprises comme Netflix et Lyft à utiliser dans les architectures de microservices. Cela dit, gRPC ne remplace pas les API REST et ne constitue pas non plus une meilleure façon de créer des API. gRPC est simplement une alternative à considérer si vous créez principalement des API pour un environnement de microservices interne et que vous avez besoin d'une communication efficace en temps réel.
À l’avenir, gRPC continuera probablement à gagner du terrain pour les applications cloud natives en raison de ses avantages en termes de performances et de sa facilité de développement. Pendant ce temps, les développeurs qui ont besoin d’exposer publiquement des API continueront d’utiliser REST dans leurs applications. REST continuera également d'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 API existantes.
NGINX propose une variété de ressources gratuites pour vous accompagner à tout moment de votre parcours gRPC.