L’architecture client-serveur populaire divise la communication en deux parties : celle qui s’occupe de toutes les tâches lourdes et fournit des services, appelée le serveur, et l’autre qui profite de ces services, appelée le client.
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 qui peuvent 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 transporter des 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’accorder. Ce format de message est basé sur certains schémas, et en ne suivant pas ces schémas, la communication ne se produirait pas. Les formats de message peuvent être similaires à XML, qui adhère à un schéma, ou à un fichier JSON, qui doit contenir 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. C’est un problème de base qui sera résolu par des technologies comme gRPC.
Pourquoi REST est-il apparu?
Au début des années 90, un protocole client-serveur populaire appelé SOAP utilisait un format de message XML avec un schéma codé en dur. Le schéma du format de message était très rigide. C’est cette absence de liberté qui a conduit à l’abandon de SOAP et à l’émergence de REST.
REST est apparu en raison de la popularité croissante de JavaScript, ce qui a entraîné une augmentation de la popularité du format de fichier JSON. Il était simple à comprendre et pratique. Il comportait simplement quelques paires clé-valeur dans son format de message.
En termes simples, Rest est une directive pour transférer des messages JSON sur Internet avec HTTP en tant que protocole (mécanisme de transport). Avec Rest, on n’a pas besoin de s’inquiéter de créer un schéma.
Qu’est-ce que REST?
Nous avons parlé de l’émergence de REST. Voyons maintenant de plus près sa technologie de base. Laissez-moi vous dire que REST signifie Representational State Transfer. Rest est un style d’architecture logicielle standardisé, une API très utilisée dans l’industrie.
Raison de la popularité et de la large utilisation de REST
- REST est simple et standardisé pour l’architecture de communication. En utilisant R, vous n’aurez pas à vous soucier de la mise en forme de votre message ou de vos données. Vous n’avez pas besoin de vous préoccuper de votre format de message à chaque fois, car tout est standardisé et utilisé dans l’industrie.
- REST est évolutif. Si votre service devient plus grand et a besoin de fonctionnalités supplémentaires, vous pouvez facilement réaménager votre serveur sans vous soucier de la performance de REST du serveur, et vous pouvez créer de nouvelles fonctions en toute isolation à moins qu’elles ne perturbent vos données.
- REST est sans état. Cela signifie que chaque requête contiendra des données qui doivent être comprises par le serveur. L’architecture du serveur permet au serveur de se souvenir des informations de cette requête, mais dans l’architecture REST, l’état de la session est stocké côté client, ce qui rend le serveur plus efficace et lui laisse peu de charge de travail pour fonctionner de manière plus fine.
- Enfin et surtout, Rest est une architecture de haute performance et prend en charge le cache.
Quand utiliser REST
Imaginez que vous créez un site web pour un restaurant. Vous avez tous les menus en ligne, et les articles de nourriture sont divisés en trois catégories:
- Entrées
- Plat principal
- Boissons
Disons maintenant que vous voulez voir toutes les boissons en ligne. Dans l’architecture Rest, vous pouvez facilement et de manière cohérente partitionner tous vos ressources sur des points de terminaison d’API. Bien sûr, vous pouvez utiliser plusieurs authentifications pour les rendre sécurisés.
Dans ce type de cas, nous envoyons une requête GET au serveur vers un point de terminaison où nous pouvons obtenir les données des ressources des boissons.
De même, nous pouvons effectuer toutes les opérations CRUD (Créer, Lire, Mettre à jour, Supprimer) dans l’API Rest, ce qui en fait un choix approprié pour de grands projets qui n’exigent pas une transfert de données supérieur et n’ont pas besoin d’être en temps réel.
Rest fonctionne le mieux pour les projets où l’efficacité de transfert de données est un facteur important. Le cache est une autre fonctionnalité de REST qui est utile pour les applications standard comme les applications de réservation de repas, les applications de réservation d’hôtel, les sites de blogs, les sites de forums en ligne, etc.
Limites et problèmes avec REST
REST est génial, mais il présente de nombreux inconvénients qui sont assez cruciaux dans certains cas. Parlons-en.
- Le besoin de communication bidirectionnelle.
Et si le serveur a besoin de transmettre des données au client? Le serveur veut initier la communication. Dans l’architecture REST, cela 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 scores en direct. Comment allez-vous gérer le serveur pour envoyer une requête au client afin d’actualiser les données des scores? Nous pourrions faire en sorte que les clients envoient des requêtes toutes les 10 secondes, mais ce n’est vraiment pas une bonne pratique. Cela surchargerait le serveur, ce qui pourrait entraîner des problèmes de vitesse.
- L’architecture REST est purement basée sur des requêtes et des réponses et ne prend pas en charge le streaming de données (traitement continu d’événements).
- La propriété REST d’être sans état peut être considérée à la fois comme une bénédiction et une malédiction, car vous ne pouvez pas déterminer l’état des données dans l’architecture REST.
Pourquoi gRPC est-il apparu?
Pour résoudre le premier problème avec REST, qui est le besoin de communication bidirectionnelle, WebSocket a été inventé, ce qui permet au serveur d’initier la communication, mais le problème avec cela est qu’il n’a pas de format. Il envoie simplement des octets et n’a pas de restrictions.
Les WebSockets n’avaient pas de problèmes en eux-mêmes, mais le vrai problème est que tout type de communication nécessite un protocole, et chaque protocole nécessite une bibliothèque cliente capable de communiquer à l’aide de ce protocole.
Si vous créez une application Python qui fonctionne selon l’architecture Rest, vous aurez besoin d’un client HTTP capable de communiquer avec le serveur. Dans de nombreux cas, 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 pensez en créer une vous-même, rappelez-vous que ce n’est pas si simple, et vous vous retrouverez à devoir maintenir une autre application.
Ainsi, pour résoudre certains problèmes liés à Rest et aux bibliothèques clientes, Google a inventé gRPC en 2015.
Pour gRPC, une bibliothèque cliente est maintenue par Google pour presque toutes les langues populaires. Elle utilise le protocole HTTP 2 en coulisse et le protocole de buffer (protobuf) comme format de message.
Vous n’avez pas à vous soucier de la bibliothèque cliente, car Google la maintient pour vous et pour presque toutes les langues de programmation. Une bibliothèque cliente unique et centralisée est l’une des principales forces de gRPC.
Un autre avantage de gRPC est le format de message qu’il utilise. Le buffer de protocole est indépendant de la langue, vous pouvez donc créer des clients en Python et des serveurs en Go tout en pouvant communiquer sans faire de bruit.
gRPC est essentiellement une bibliothèque cliente et un protocole qui peut être utilisé sur n’importe quel appareil.
Qu’est-ce que gRPC?
gRPC utilise le protocole protobuf pour communiquer. Il transforme les fichiers proto en format binaire et les envoie au serveur, où ils sont ensuite désérialisés pour retrouver leur format d’origine. C’est ainsi que fonctionne le protocole protobuf.
gRPC propose différentes formes de communication. Vous pouvez les considérer comme des fonctionnalités de gRPC.
Fonctionnalités de gRPC
- Requête unique : Il s’agit d’un type simple de communication requête-réponse où le client envoie une requête proto et, après sa réception, le serveur attend un certain temps pour effectuer un processus, puis retourne une réponse.
- Streaming du serveur : En faisant une seule requête, un flot de données arrive en réponse du serveur. Par exemple, en cliquant sur une vidéo, beaucoup de données liées à la vidéo affluent du côté serveur.
- Streaming du client : C’est l’inverse pour le streaming du serveur. Ici, le client envoie beaucoup de données en une seule fois au serveur. Par exemple, cela se produit lorsque vous partagez un gros fichier sur Internet ou téléchargez une image ou une vidéo sur Internet. Le client envoie constamment des données du côté serveur.
- Streaming bidirectionnel : Dans ce type de communication, le client et le serveur envoient plusieurs messages. Les conversations en chat en sont un excellent exemple.
Ce sont quatre fonctionnalités populaires de gRPC qui en font un outil si puissant.
Quand utiliser gRPC
En ce qui concerne les caractéristiques de gRPC, nous avons vu quelques cas d’utilisation pour gRPC. Imaginons que vous souhaitez créer une application de chat. Vous n’allez pas utiliser l’API Rest car elle ne permettra pas une diffusion en streaming rapide de la communication bidirectionnelle. Pour cela, nous utiliserons le flux gRPC, qui offrira des avantages supplémentaires en plus de la vitesse.
Premièrement, son comportement indépendant du langage n’a pas d’importance dans quelle langue de programmation le serveur ou les autres clients sont écrits. La communication peut toujours être établie tant que le format de message est accepté.
Ainsi, grâce à 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.
- Support limité des navigateurs : gRPC utilise HTTP 2, il est donc difficile d’appeler directement le service gRPC à partir du navigateur, ce qui nécessite parfois la mise en place d’un proxy.
- Format 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 bogues et problèmes doivent être résolus.
- Problèmes d’apprentissage : Rest et GraphQL utilisent JSON, qui est plus facile à apprendre. La plupart des gens essaieront de s’y tenir car protobuf reste un sujet nouveau et complexe, il sera donc difficile de trouver des experts en gRPC.
REST vs. gRPC:
Nous allons maintenant discuter de la différence technique entre REST et gRPC.
Format du message :
Le format de message utilisé par REST est principalement JSON (parfois en format XML), qui est une forme plus lisible et plus facile à manipuler. Vous n’aurez pas à vous soucier du schéma en Rest. D’un autre côté, gRPC utilise un protocole de buffer pour sérialiser les données. La forme compressée est plus légère et plus rapide à transporter. Il est en format binaire, donc il sérialise et désérialise les données pour les transmettre.
HTTP 1.1 vs. HTTP 2 :
L’API Rest utilise généralement le protocole HTTP 1.1, tandis que gRPC utilise HTTP 2 en coulisse. L’API Rest peut toujours utiliser HTTP 2 mais reste limitée en raison du mécanisme de requête-réponse. gRPC utilise HTTP 2 et tire parti du support de HTTP 2 pour la communication bidirectionnelle et client-réponse. C’est un autre aspect qui rend les performances de gRPC meilleures que celles de REST. Il peut gérer les requêtes unidirectionnelles comme HTTP 1.1 et les requêtes bidirectionnelles simultanément comme HTTP 2.
Latence :
La faible latence et la grande vitesse de communication de gRPC en font un outil utile pour se connecter à des systèmes composés d’une architecture de microservices légers, ce qui augmente l’efficacité de la transmission des messages. Dans la plupart des cas du réseau, la latence de REST est de 25 ms, tandis que la latence de gRPC est beaucoup moins élevée que celle de REST.
Limite de charge utile :
Rest a une limite de charge utile maximale de 45 Mo lors de l’envoi de messages sortants, tandis que gRPC n’a aucune limite, ce qui signifie que votre message sortant peut être aussi lourd que vous le souhaitez.
Sécurité:
En matière de sécurité, Rest sera en retard car il utilise HTTP 1.1 et le format JSON, qui sont faciles à décrypter et à accéder. En revanche, gRPC utilise HTTP 2, qui est beaucoup plus sécurisé, et utilise protobuf, qui est au format binaire et difficile à décrypter.
Vitesse:
Là encore, gRPC l’emporte, car il offre 10 fois plus de vitesse que Rest, et c’est pour la même raison, en utilisant HTTP 2 en tant que protocole et protobuf en tant que format de message.
La fonction de génération de code
Rest ne fournit pas de fonctionnalités de génération de code intégrées, ce qui signifie que le développeur a besoin d’applications tierces pour produire du code API, tandis que gRPC dispose de fonctionnalités de génération de code natives en raison de son compilateur protobuf, qui est compatible avec plusieurs langages de programmation. C’est un autre avantage, notamment pour les architectures de microservices.
Memphis REST Gateway
Pour permettre la production de messages via des appels HTTP pour diverses utilisations et facilité d’utilisation, Memphis a ajouté un gateway HTTP pour recevoir des requêtes basées sur REST (=messages) et produire ces messages à la station requise.
Les cas d’utilisation courants qui bénéficient du REST Gateway sont:
- Produire des événements directement à partir d’une interface frontend
- Connecter Debezium en utilisant un serveur HTTP
- Webhooks ArgoCD
- Intégration PostHog
- Recevoir des données de Fivetran/Rivery/N’importe quel plateforme ETL à l’aide d’appels HTTP
Memphis REST Gateway + un schéma JSON peut être une combinaison puissante pour améliorer la qualité des données et garantir une communication saine entre les applications ou services.
Memphis prendra bientôt en charge gRPC également.
Conclusion
En fin de compte, je tiens à dire que REST est toujours l’architecture la plus utilisée et populaire, et il est impossible d’y renoncer. REST présente de nombreux inconvénients, tels que l’absence de streaming de données, l’absence de communication bidirectionnelle, la lenteur, etc., mais c’est le meilleur choix pour les applications standard que nous voyons au quotidien.
D’un autre côté, gRPC, étant jeune et difficile à apprendre, offre de nombreuses choses comme un haut débit de streaming de données côté client et serveur, un bon streaming de données bidirectionnel, est rapide et compact, et utilise HTTP 2. En raison de sa performance rapide, gRPC convient le mieux aux applications à forte charge de travail, telles que la diffusion en continu de vidéos, la diffusion en continu de chansons, les jeux en ligne, le partage de fichiers et les applications de chat.