gRPC vs RESTApi

Qu’est-ce que gRPC ?

gRPC est un Framework d'appel de procédure à distance haute performance développé par Google. Son principal cas d'utilisation est la communication de service à service. C'est pourquoi vous le verrez souvent utilisé avec des micro-services.

RPC signifie Remote Procedure Call (appel de procédure à distance).

D'un point de vue "développement", on exécute du code distant (sur un autre service), comme un appel de méthode locale. Les RPC sont un excellent moyen de mise en œuvre d’une communication au sein des systèmes distribués.

gRPC se distingue par Protocol Buffers pour le langage de définition d'interface (IDL). Cela permet à gRPC d'avoir un typage fort et un support de génération de code.

Protobuf est une méthode efficace de sérialisation de données structurées. C'est un format binaire qui peut être 5 fois plus rapide que JSON. De plus, gRPC utilise HTTP/2 pour une efficacité réseau améliorée et une communication en temps réel.

D'un point de vue "code", vous définissez les services qui exposent les appels RPC et les contrats de messages à l'intérieur d'un fichier Proto. Ensuite, vous pouvez générer le code client et serveur gRPC.

A ce titre, .NET prend en charge la création de services gRPC, ces derniers peuvent utiliser les fonctionnalités intégrées :

• Journalisation (log)
• Injection de dépendances (DI)
• Authentification et autorisation

À présent, vous devriez avoir une idée de ce qu'est gRPC.

Mais où devriez-vous l'utiliser ?

Les cas d'utilisations idéaux pour gRPC sont les micro-services, le streaming et l'IoT.

Chaque micro-service peut utiliser un langage de programmation différent.

gRPC est indépendant du langage, donc il convient bien à ces scénarios.

Cependant, pourquoi ne pas utiliser REST pour cela ?

Pour mieux répondre à cette question, faisons une brève comparaison entre ces deux approches.

Quelle est la différence entre REST et gRPC ?

La différence clé réside dans le format des données. REST utilise JSON (ou XML). gRPC utilise Protobuf. Les deux utilisent HTTP, mais gRPC nécessite HTTP/2 pour les opérations de streaming.  

REST est plus populaire et parfait pour les API publiques.  

gRPC est hautement efficace pour la communication distribuée entre serveurs.

Autant gRPC que REST ont leurs avantages et inconvénients, et le choix entre eux dépend des exigences spécifiques et des contraintes de l'application ou du système que vous construisez.

Peut-on faire les deux à la fois ?

Effectivement, l’un n’empêche pas l’autre. Il existe des solutions pour réconcilier les deux si on veut bénéficier du gRPC et du REST à la fois.

Parmi les solutions alternatives qui réconcilient se débat, il y a celle de l’implémentation d’un service gRPC munis d’http Endpoint, tout comme le cas d’un RestAPI grâce une notion nommée **« Transcodage » (entre gRPC et JSON).**

L’idée est de créer des API RESTful **JSON** pour les services gRPC. Le transcodage permettra aux applications d'appeler les services gRPC avec des concepts HTTP familiers :

• Verbes HTTP
• Liaison des paramètres d'URL
• Requêtes/réponses JSON

Bien entendu, gRPC peut toujours être utilisé pour appeler des services.

C’est ce qu’on va découvrir dans la suite de cet article à l’aide d’un bref tuto.

Tuto (gRPC et REST)

Pour ce faire nous allons implémenter gRPC munis d’Endpoint REST en .NET 8.0.

Prérequis

1. Installer Visual studio 2022 version 17.8+ (afin d’utiliser .NET8.0 )  
2. Création d’un projet template ASP.NET Core gRPC Service

Implémentations

1/ Ajouter au csproj la balise IncludeHttpRuleProtos  

<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
<IncludeHttpRuleProtos>true</IncludeHttpRuleProtos>
</PropertyGroup>

2/ Puis rajoute le package Microsoft.AspNetCore.Grpc.JsonTranscoding à notre csproj

 <PackageReference Include="Microsoft.AspNetCore.Grpc.JsonTranscoding" Version="8.0.0" />

3/ On importe dans greet.proto le code httpruleprotos grâce à cette instruction

import "google/api/annotations.proto";

4/ On rajoute à notre Endpoint RPC dans notre service greeter en options la description qui représente le REST endpoint  

// The greeting service definition.
service Greeter {
// Sends a greeting
rpc SayHello (HelloRequest) returns (HelloReply){
option (google.api.http) = {
get: "/hello/{name}"
};
};
}

5/ Ne pas oublier de rajouter le service AddJsonTranscoding au service grpc dans le program.cs afin que le transcodage puisse être pris en compte

builder.Services.AddGrpc().AddJsonTranscoding();

6/ Préciser au kestrel au niveau de appsettings de prendre en charge le protocole http1 aussi au long du protocole http2

 "Kestrel": {
"EndpointDefaults": {
"Protocols": "Http1AndHttp2"
}

Et voilà !

Vous pouvez maintenant tester votre Endpoint depuis votre navigateur 😎 !

Résumé/Comparatif

Récapitulatif

• gRPC (gRPC Remote Procedure Calls)
• REST (Representational State Transfer)

Ce sont deux approches différentes pour la création d'APIs (Interfaces de Programmation d'Applications) en termes d'architecture, de communication et de fonctionnalités.

Principales différences

Protocole de Communication

• gRPC :

  • Utilise le protocole HTTP/2 pour la communication.
  • Hautes performances et à faible latence
  • Streaming bidirectionnel
  • Multiplexage
  • Compression des en-têtes
    

• REST :

  • Utilise généralement HTTP/1.1 ou HTTP/2 pour la communication.
  • Reposent sur des méthodes HTTP standard (GET, POST, PUT, DELETE) et des codes d'état.

Format de données

• gRPC :

  • Utilise les Protobuf (protobuf) comme format de sérialisation.
  • Format binaire à la fois compact et efficace.
    

• REST :

  • Utilise souvent JSON ou XML comme format d'échange de données
  • JSON est plus couramment utilisé en raison de sa simplicité et de sa lisibilité humaine.

Définition de Service

• gRPC :

  • Utilise les Protobuf pour définir de manière indépendante du langage

  • Les méthodes de service

  • Les types de messages.

     

• REST :

  • Utilise les méthodes HTTP (GET, POST, PUT, DELETE)
  • Documentation et spécification OpenAPI (anciennement appelée Swagger) est une manière courante de documenter les APIs REST.

Gestion des Requêtes et Réponses

• gRPC :

  • Prend en charge le streaming bidirectionnel

  • Prise ne charge des structures de données et des types de messages plus complexes.

     

• REST :

  • Utilise un modèle de requête-réponse sans état. Les clients envoient des requêtes aux serveurs, et les serveurs répondent avec les informations demandées.
  • Les APIs REST peuvent également prendre en charge le streaming, mais utilisent généralement des techniques telles que le long polling ou WebSocket pour une communication bidirectionnelle.

Génération de Code

• gRPC : Il implique souvent la génération de code pour créer du code client et serveur dans divers langages de programmation en fonction de la définition de service dans le fichier. Proto.
  
• REST : Les clients interagissent avec les APIs REST en utilisant des méthodes HTTP standard, et le code côté serveur peut être implémenté dans divers langages de programmation sans avoir besoin d'une génération de code spécifique.

Cas d'Utilisation

• gRPC : Il est souvent préféré dans des scénarios où la haute performance, la faible latence et la communication efficace entre les micro-services sont cruciales. Il est couramment utilisé dans les architectures de micro-services et avec des technologies telles que Kubernetes.  
  
• REST : Il est largement utilisé pour des APIs web de type général et est un bon choix lorsque la simplicité, la facilité d'utilisation et la compatibilité avec l'infrastructure web existante sont des priorités.

Conclusion subjective

Les cas d’utilisations de gRPC se limitent aujourd’hui aux systèmes internes avec une architecture en micro-services. Le but est de favoriser les échanges continus et en masse des données entre les services du système qui bénéficient de la même infrastructure en termes de réseau, de sécurité et de qualité 0

À la différence des cas d’utilisation des RESTApi qui sont représentés essentiellement par les besoins qui s’attachent aux échanges de données externes/publiques conventionnés et souvent éventuels

L’évolution de ces deux technologies restent très largement suivie par les communautés IT

Faut-il donc privilégier les RESTApi au gRPC ou inversement ?

La réponse à cette question et tout aussi semblable aux réponses typiques aux problématiques d’ingénieries... cela reste un choix de contexte.