gRPC contre REST – DZone

REST ou gRPC, lequel choisir ? Dans cet article, nous examinerons les architectures client-serveur gRPC et REST pour la communication et comparerons leurs forces et leurs faiblesses et les facteurs à prendre en compte pour faire le bon choix.

L’architecture client-serveur populaire divise la communication en deux parties :

1. Le serveur est celui qui prend en charge toutes les tâches lourdes et fournit des services.
2. Le client est l’autre qui bénéficie de ces services.

Dans la communication client-serveur générale, le client envoie simplement une requête demandant des ressources ou des services au serveur, et le serveur répond à cette requête.

Pour la communication client-serveur, les clients et les serveurs doivent disposer de bibliothèques capables de comprendre le protocole dans lequel ils communiquent. Un protocole est un langage ou un ensemble de règles de communication Internet. Ce sont des mécanismes de transport qui suivent certaines directives pour le transport de données sur Internet.

Le deuxième aspect le plus important de la communication client est le format de message sur lequel le client et le serveur peuvent s’entendre. Ce format de message est basé sur certains schémas, et en ne suivant pas ces schémas, la communication n’aurait pas lieu. Les formats de message peuvent être similaires à XML, qui adhère à un schéma, ou à un fichier JSON contenant des paires clé-valeur spécifiques.

Un autre aspect important de ce type de communication à comprendre est qu’il est basé sur un mécanisme de requête et de réponse, ce qui signifie que le serveur ne communique que lorsque le client initie la communication. Avec REST et GraphQL, c’est principalement unidirectionnel. Il s’agit d’un problème de base qui sera résolu par une technologie comme gRPC.

Pourquoi REST a-t-il vu le jour ?

Au début des années 90, un protocole client-serveur populaire appelé SOAP utilisait le format de message XML avec un schéma codé en dur. Le schéma du format de message était très rigide. Le manque de liberté est ce qui a causé l’abandon de SOAP et l’émergence de REST.

REST a vu le jour en raison de la popularité croissante de JavaScript, qui a entraîné la croissance de la popularité du format de fichier JSON. C’était simple à comprendre et pratique. Il avait juste quelques paires de clé et de valeur dans son format de message.

En termes simples, Rest est une ligne directrice pour le transfert de messages JSON sur Internet avec HTTP comme protocole (mécanisme de transport). Avec Rest, on n’a pas à se soucier de faire un schéma.

Qu’est-ce que le repos ?

Nous avons parlé de l’émergence de REST. Plongeons maintenant dans sa technologie de base. Alors laissez-moi vous dire que REST signifie Representational State Transfer. Rest est un style d’architecture logicielle standardisé, une API souvent utilisée dans l’industrie.

Raisons de la popularité et de l’utilisation généralisée de REST

• REST est simple et standardisé pour l’architecture de communication. Lors de l’utilisation de R, vous n’auriez pas à vous soucier du formatage de votre message ou de vos données. Vous n’avez pas besoin de vous soucier du format de votre message à chaque fois, car tout est standardisé et utilisé par l’industrie.
• REST est évolutif. Supposons que votre service s’agrandisse et ait besoin de plus de fonctionnalités. Dans ce cas, vous pouvez facilement réorganiser votre serveur sans vous soucier des performances de REST du serveur, et vous pouvez créer de nouvelles fonctions de manière totalement isolée, à moins qu’elles ne gâchent vos données.
• REST est sans état. Cela signifie que chaque requête contiendra des données que le serveur doit comprendre. L’architecture du serveur oblige le serveur à rappeler les informations de cette requête. Pourtant, dans l’architecture REST, l’état de la session est stocké côté client, ce qui rend le serveur plus efficace et lui donne peu de charge de travail pour un fonctionnement plus fin.
• Enfin, Rest est une architecture haute performance et prend en charge la mise en cache.

Quand utiliser REST :

Imaginez que vous créez un site Web pour un restaurant. Vous avez tous les menus en ligne, et les produits alimentaires sont divisés en trois catégories :

1. Entrées
2. Plat principal
3. Breuvages

Maintenant, disons que vous voulez voir toutes les boissons en ligne. Dans l’architecture Rest, vous pouvez partitionner facilement et de manière cohérente toutes vos ressources sur les points de terminaison d’API. Bien sûr, vous pouvez utiliser plusieurs authentifications sur eux pour les sécuriser.

Dans ce type de cas, nous envoyons une requête GET au serveur vers un point de terminaison où nous pouvons obtenir des données sur les ressources de boissons.

De même, nous pouvons effectuer tous les CRUD (créer, lire, mettre à jour, supprimer) dans l’API Rest, ce qui le rend adapté aux grands projets qui ne nécessitent pas de super-transfert de données et n’ont pas besoin d’être en temps réel.

Le repos fonctionne mieux pour les projets où un transfert de données efficace est un facteur important. La mise en cache est une autre fonctionnalité de REST qui est utile pour les applications standard telles que les applications de réservation de repas, les applications de réservation d’hôtel, les sites Web de blogs, les sites Web de forums en ligne, etc.

Limitations et problèmes avec REST

REST est génial, mais il a de nombreux inconvénients qui sont assez cruciaux dans certains cas. Parlons d’eux.

• Le besoin de communication bidirectionnelle. Que se passe-t-il si le serveur doit envoyer des données au client ? Le serveur moyen veut initier la communication. Dans l’architecture REST, ce n’est pas possible. Bien sûr, vous pouvez utiliser quelques astuces, mais elles ne sont pas pratiques.
• Imaginez créer un site Web de score en direct. Comment allez-vous gérer le serveur pour envoyer une demande au client afin de mettre à jour les données de score ? Nous pouvons faire en sorte que les clients envoient des requêtes toutes les 10 secondes, mais ce n’est pas du tout une bonne pratique. Cela surchargera le serveur, ce qui pourrait entraîner des problèmes de vitesse.
• L’architecture REST est purement demande et réponse et ne prend pas en charge le flux de données (traitement continu des événements).
• La propriété REST d’être sans état peut être considérée comme une bénédiction et une malédiction car vous ne pouvez pas décider de l’état des données sur l’architecture REST.

Pourquoi gRPC a-t-il vu le jour ?

Pour résoudre le premier problème avec REST, qui est le besoin de communication bidirectionnelle, WebSocket a été inventé, qui permet au serveur d’initier la communication. Pourtant, le problème est qu’il n’a pas le format. Il envoie simplement des octets et n’a aucune restriction.

Les WebSockets n’ont eu aucun problème en eux-mêmes. Pourtant, le problème réel est que tout type de communication nécessite un protocole, et chaque protocole nécessite une bibliothèque cliente qui peut communiquer à l’aide de ce protocole.

Si vous créez une application Python qui fonctionne sur l’architecture Rest, vous aurez besoin d’un client HTTP capable de communiquer avec le serveur. Parfois, les bibliothèques clientes sont créées par un tiers, principalement un développeur indépendant. L’utilisation de bibliothèques tierces peut exposer votre sécurité et toute votre application dépendra d’un tiers pour la communication.

Dans le cas d’une application Web, le navigateur agit comme une bibliothèque cliente, mais pour les projets non Web, vous aurez besoin d’une bibliothèque cliente tierce. Si vous envisagez d’en créer une vous-même, rappelez-vous que ce n’est pas si facile et que vous vous chargerez de la maintenance d’une autre application.

Ainsi, pour résoudre certains problèmes avec Rest et pour résoudre les problèmes avec les bibliothèques clientes, Google a inventé gRPC en 2015.

Pour gRPC, une bibliothèque cliente est gérée par Google pour presque tous les langages populaires. Il utilise le protocole HTTP 2 sous le capot et le tampon de protocole (protobuf) comme format de message.

Vous n’avez pas à vous soucier d’une bibliothèque cliente, car Google la gère pour vous et presque tous les langages de programmation. Cependant, une bibliothèque cliente unique et centralisée est l’un des principaux atouts de gRPC.

Un autre avantage de gRPC est le format de message qu’il utilise. De plus, le tampon de protocole est indépendant de la langue, vous pouvez donc créer des clients en Python et des serveurs en Go et être toujours en mesure de communiquer sans faire d’histoires.

gRPC est essentiellement une bibliothèque cliente et un protocole qui peuvent être utilisés sur n’importe quel appareil.

Qu’est-ce que gRPC ?

gRPC utilise protobuf pour communiquer. Il sérialise les fichiers proto au format binaire et les envoie au serveur, et côté serveur, ils sont désérialisés au format d’origine. C’est comme ça que ça marche avec protobuf.

gRPC a différentes formes de communication. Vous pouvez les considérer comme des fonctionnalités de gRPC.

Fonctionnalités de gRPC

1. Demande unique

Il s’agit d’un type simple de communication requête-réponse où le client envoie une requête proto et, à sa réception, le serveur attend un certain temps pour effectuer un processus, puis renvoie une réponse.

2. Diffusion de serveur

Lors d’une seule requête, un flot de données arrive en réponse du serveur. Par exemple, lorsque vous cliquez sur une vidéo, de nombreuses données liées à la vidéo affluent du côté serveur.

3. Diffusion client

C’est l’inverse pour le streaming de serveur. Ici, le client envoie beaucoup de données à la fois au serveur. Par exemple, cela se produit lorsque vous partagez un fichier volumineux sur Internet ou téléchargez une image ou une vidéo sur Internet. Le client envoie constamment des données au côté serveur.

4. Streaming bidirectionnel

Dans ce type de communication, le client et le serveur envoient plusieurs messages. Le chat en est un excellent exemple.

Ce sont quatre fonctionnalités populaires de gRPC qui le rendent si puissant.

Quand utiliser gRPC

En ce qui concerne les fonctionnalités de gRPC, nous avons vu quelques cas d’utilisation de gRPC. Par exemple, imaginons que vous souhaitiez créer une application de chat. Vous n’allez pas utiliser l’API Rest car elle ne pourra pas permettre un streaming rapide de la communication bidirectionnelle. Pour cela, nous utiliserons le flux gRPC, qui offrira d’autres avantages que la vitesse.

Premièrement, son comportement indépendant du langage n’a pas d’importance dans le langage de programmation que le serveur ou les autres clients écrivent. La communication peut encore être établie jusqu’à ce que le format du message soit accepté.

Ainsi, avec cette fonctionnalité, la version Android de l’application de chat peut communiquer avec la version iOS et vice versa.

Problèmes avec gRPC

Il y a des problèmes avec tout, y compris gRPC.

Prise en charge limitée du navigateur

gRPC utilise HTTP 2, il est donc difficile d’appeler le service gRPC directement depuis le navigateur. ce qui nécessite parfois la mise en place d’un proxy.

Formulaire non lisible

Comme nous le savons tous, gRPC utilise un format binaire qui n’est pas lisible par les humains. C’est un inconvénient dans certains cas.

Manque de maturité

gRPC a été développé en 2015, il est donc encore un peu immature par rapport à REST, et de nombreux bugs et problèmes doivent…