Qu’est-ce que gRPC ?

gRPC est un framework d’appel de procédure distante (Remote Procedure Call) indépendant du langage. Implémenté par Google en 2015, il est open-source (les tiers sont autorisés et même encouragés à optimiser le développement) et surtout multi-langages (GO, C++, Java, Python, C# et d’autres). Il offre des fonctionnalités telles que l’authentification, la transmission bidirectionnelle et le contrôle de flux, par le blocage ou non des communications (annulation ou délais d’attente). gRPC permet la construction de liaisons client/serveur multiplateformes pour de nombreux langages.

A quoi sert gRPC ?

gRPC, Web Services (tels que WCF) et API sont donc des protocoles de communication. Ils définissent un langage d’échange pour que deux systèmes devant échanger des informations puissent le faire de manière compréhensible et sécurisée : par une syntaxe, un codage numérique et des procédures de contrôle d’erreurs ou de perte de données transmises, et de répétitions lorsque nécessaire.

La popularité croissante d’architectures de type microservices a conduit à la création de plus en plus d’API privées. Les API agissent comme une solution légère servant aux microservices individuels à communiquer entre eux en complément d’un potentiel bus de message.

D’un point de vue technique, les API envoient généralement des données au moyen de requêtes HTTP. Ceux-ci renvoient une réponse textuelle, souvent au format JSON, que les développeurs peuvent utiliser à leur guise. Les types de styles de conception d’API incluent REST , SOAP , GraphQL , gRPC et autres. Beaucoup utilisent des formats de spécification comme OpenAPI , RAML ou AsyncAPI pour définir les interactions d’API dans des formats lisibles par l’homme et la machine.

L’API REST est depuis longtemps un pilier de la programmation Web. Mais récemment, la gRPC a commencé à empiéter sur son territoire…ci-après quelques explications.

Différences entre gRPC et REST

Le format de la charge utile

Une des plus grandes différences entre REST et gRPC est le format de la charge utile. Les messages REST contiennent généralement du JSON, même si en théorie vous pouvez envoyer n’importe quoi comme réponse, en pratique, tout l’écosystème REST est axé sur JSON. Or JSON est un format textuel que vous pouvez certes compresser au risque cependant de perdre l’avantage du format textuel, sa lisibilité.

gRPC, en revanche, accepte et renvoie les messages sérialisés avec Protobuf qui, du point de vue des performances, est un format de message binaire très efficace et complet, à la fois dans l’envoi et la réception. Protobuf sérialise et désérialise très rapidement sur le serveur et le client.

Comme le précise Ange, Expert Microservices

Cette sérialisation entraîne des charges utiles de petits messages, importantes dans des scénarios de bande passante limitée comme les applications mobiles ou encore dans le cadre d’échange de gros volumes de données comme par exemple des données de comptage, la sérialisation de chiffres en binaire est en effet très efficace et permet de gagner de la bande passante en limitant les flux réseaux rendant ainsi la solution plus rapide et efficace.

L’approche contractuelle

Un fichier principal, le .proto fichier, définit le contrat des services et des messages gRPC. À partir de ce fichier, les frameworks gRPC génèrent une classe de base de services et des messages au sein d’architectures client/serveur.

En partageant le fichier entre le serveur et le .proto client, les messages et le code peuvent être générés de bout en bout. La génération de code élimine la duplication des messages sur le client et le serveur. Cela permet également à gRPC de générer automatiquement des bibliothèques clientes pour vous..  et fait potentiellement gagner beaucoup de temps.

Cette technologie est relativement simple à mettre en œuvre, dans la mesure où elle utilise un IDL simple et très facile d’utilisation pour la création des fichiers .proto. De cette manière, même des programmes anciens peuvent être facilement complétés par une interface gRPC performante et il est ainsi possible de transférer beaucoup plus rapidement des fichiers volumineux.

La structure multi-couches est fortement normalisée, le format d’un service gRPC est donc cohérent entre les plateformes et les implémentations. Cela élimine le débat des développeurs sur le meilleur format des URL, des verbes http et des codes de réponse et leur économise du temps précieux. Ils peuvent ainsi se concentrer en priorité sur l’implémentation des méthodes.

Code First

Comme le précise Ange, expert Microservices

Dans ce cas, il est possible d’ajouter l’utilisation de protobuf sur du code existant, cela est très utile dans le cadre d’applications Legacy dont le code existant peut représenter plusieurs centaines de milliers, voire plusieurs millions de lignes de code. Cette approche permet, via une numérotation simple des propriétés des objets échangés, de profiter de la sérialisation de protobuf. Cette numérotation permet au serialiseur/désérialiseur de savoir dans quel ordre sont classées les propriétés.

On voit donc ici que gRPC et Protobuf peuvent être utilisés aussi bien pour des nouveaux projets que pour des projets plus anciens que l’on souhaiterait mettre à jour pour profiter de performances améliorées ou encore de fonctionnalités non présentes, par exemple la bidirectionnalité dans le cadre de WCF qui, si elle est existante, est limitée en terme d’usage.

Prise en charge des échéances

Etant conçu pour http/2 qui fournit une base pour les flux de communication en temps réel et de longue durée, gRPC permet de spécifier au serveur une durée maximale d’attente avec la prise en charge des échéances et de l’annulation.

Evolutivité

Par ailleurs, le gRPC a fait l’objet de nombreux tests et est hautement évolutif, ce qui lui permet de mener à bien les communications les plus complexes et exhaustives, au sein d’architectures client/serveur connectées à l’échelle internationale par exemple. HTTP/2 augmente ses performances, entre autres, grâce à ses capacités de multiplexage et de streaming bidirectionnel. Des compressions d’en-têtes sont également possibles lorsque le volume de données des requêtes et réponses doit être significativement réduit dans le réseau.

Communication sans limite

Les Protocol Buffers et les compilateurs Protobuf correspondants permettent, par ailleurs, une communication sans limite : les divers systèmes d’exploitation, les composants variés des architectures client/serveur et les différents langages de programmation ne font plus obstacle à la communication. Ainsi, un logiciel écrit en C peut communiquer avec le logiciel Java. Des compilateurs Protobuf sont désormais disponibles pour de nombreux autres langages, par exemple pour C#, C++, Go, Objective-C, Java, Python, Node.js, Android Java, Swift, Ruby et PHP.

Comme le précise Ange

Il est à noter que Protobuf peut aussi s’utiliser de manière totalement décorélée de gRPC, il existe par exemple en .Net un portage nommé Protobuf-Net supporté depuis de nombreuses années et permettant d’utiliser la sérialisation binaire par exemple dans le cadre de WCF (Windows Communication Foundation).

Flexibilité

La flexibilité de gRPC présente également un gros avantage : il peut par exemple être utilisé de la même manière pour l’échange de données de microservices ou le partage de données d’applications mobiles avec des serveurs.

Sécurité

Autre point positif : le protocole permet l’implémentation de technologies de sécurité modernes. Le gRPC dispose ainsi d’une fonction d’authentification intégrée et promeut l’utilisation de SSL/TLS pour l’authentification et le cryptage des échanges.

En synthèse

Le modèle conceptuel utilisé par gRPC consiste à disposer de services dotés d’interfaces claires et de messages structurés pour les demandes et les réponses. Ce modèle traduit directement des concepts de langage de programmation tels que les interfaces, les fonctions, les méthodes et les structures de données. Cela permet également à gRPC de générer automatiquement des bibliothèques clientes pour vous..

• Bonne documentation
• Performance
• Gestion des flux (unitaire, flux unidirectionnel ou bidirectionnel)
• « Fire and forget » Réponse des requêtes non obligatoire
• Code first : Facilité de se lier à des classes existantes (pas besoin de tout redéclarer) contexte .NET préservé, bonne maitrise de l’ensemble

Les faiblesses de gRPC

Les messages gRPC sont encodés par défaut avec Protobuf. Bien que Protobuf soit efficace pour envoyer et recevoir, son format binaire n’est pas lisible par l’homme. Protobuf nécessite la description de l’interface du message spécifiée dans le .proto fichier pour désérialiser correctement.

Lors de l’analyse du trafic de données et, notamment, lors de la recherche d’erreurs et des opérations de dépannage (débogage), des instances supplémentaires doivent donc être utilisées pour retranscrire le code sous une forme compréhensible et pour localiser les sources d’erreurs.

Cependant, les messages Protobuf prennent en charge la conversion vers et depuis JSON. La conversion JSON intégrée offre un moyen efficace de convertir des messages Protobuf vers et à partir d’un formulaire lisible par l’homme lors du débogage.

D’autres inconvénients sont liés à la mise en réseau d’architectures client/serveur distribuées. En connectant à des ordinateurs à distance, gRPC est peut-être plus vulnérable que des systèmes locaux. Cela nécessite un réseau performant d’une part, et expose davantage aux éventuelles attaques…Par ailleurs, le gRPC ne prend pas en charge la multidiffusion.

Scénarios recommandés gRPC

gRPC est bien adapté aux scénarios suivants :

• Microservices : gRPC est idéal pour les microservices légers pour des créer des applications rapides et efficaces
• Communication en temps réel et bidirectionnelle : les services gRPC peuvent envoyer des messages en temps réel sans interrogation.
• Environnements multi-langages : l’outil gRPC prend en charge une majorité de langages de développement (GO, C++, Java, Python, C# et d’autres).
• Communication inter-processus (IPC) : les transports IPC tels que les sockets de domaine Unix et les canaux nommés peuvent être utilisés avec gRPC pour communiquer entre les applications sur le même ordinateur..

Pour information WCF n’étant plus maintenu, Microsoft et la communauté redirige vers gRPC qui supporte les dernières versions de .NET, dont .NET Core.

gRPC peut aussi être complémentaire avec le message queuing, gRPC pourra par exemple être utilisé pour des échanges synchrones et légers, là ou le message queuing pourra par exemple être utile dans le cas de messages asynchrones ne nécessitant pas un traitement immédiat.