La plupart des applications logicielles doivent pouvoir se connecter à d'autres codes pour plusieurs raisons. Cela peut aller de l'intégration à l'ajout de nouvelles fonctionnalités. Pour s'assurer que les logiciels peuvent se lier à d'autres applications et pour garantir leur intégration dans d'autres programmes, les développeurs utilisent des API. C'est pourquoi une interface de programmation d'applications est nécessaire pour la plupart des logiciels. Grâce à leur rôle de passerelle entre les systèmes, les API permettent aux individus d'accéder à une variété de services Web. Il est donc important de choisir la technologie appropriée pour offrir une API à votre projet.
Toute organisation qui souhaite partager son application ou sa plate-forme avec ses utilisateurs doit utiliser des API. Il existe de nombreuses façons de développer et d'affiner les API pour qu'elles soient parfaitement adaptées à votre application. L'une des dernières méthodes utilisées par les programmeurs pour concevoir des API est le gRPC. Voyons ce qu'est gRPC, ses avantages et ses inconvénients.
Qu'est-ce que gRPC ?
gRPC est l'abréviation de Google Remote Procedure Call. gRPC est un cadre RPC open-source utilisé pour créer des API rapides et évolutives. Il permet le développement de systèmes en réseau et une communication ouverte entre les applications client et serveur gRPC. gRPC a été adopté par plusieurs entreprises technologiques de premier plan, notamment Google, IBM, Netflix et bien d'autres. Le cadre gRPC dépend de piles technologiques de pointe telles que HTTP/2, les tampons de protocole, etc. pour une protection optimale de l'API, des appels de procédure à distance performants et l'évolutivité.
Que sont les RPC?
RPC et REST - Representational State Transfer- ont historiquement été deux approches distinctes de la création d'API. En outre, des protocoles tels que SOAP et GraphQL sont également utilisés à cette fin. Les appels de procédure à distance vous permettent d'écrire un logiciel comme s'il s'exécutait localement, bien qu'il puisse s'exécuter sur un autre appareil.
Ils constituent le cadre le plus classiquement utilisé pour concevoir des API. Contrairement à un appel de protocole HTTP typique, un RPC utilise un appel de fonction comme principale méthode d'interaction client-serveur. RPC est une technique productive pour la création d'API car les échanges sont simples et les contenus sont légers. Les services gRPC imitent également cette architecture de communication. RPC utilise IDL - Interface Definition Language pour contracter le type de données et les méthodes qui seront invoquées. Les services gRPC adoptés des RPC sont devenus très populaires ces dernières années.
Pourquoi les services gRPC ont-ils été développés ?
Alors que de plus en plus d'entreprises ouvrent des canaux d'intégration, il devient difficile de relier ces logiciels. RPC Les API sont difficiles à intégrer et risquées à distribuer car elles peuvent divulguer des spécificités internes. Elles sont développées dans de nombreux langages de programmation et sont étroitement liées au cadre sous-jacent.
Ce problème a été résolu et l'accessibilité des API a été améliorée lorsque l'API REST a été lancée en 2000. Plus précisément, elle a donné aux utilisateurs un moyen cohérent de récupérer des informations indirectement par le biais de ressources en utilisant des techniques HTTP standard comme GET, PUT, POST, et d'autres. La principale distinction entre RPC et REST API est qu'avec RPC, les processus sont abordés, mais il n'est pas facile de prévoir ce que pourraient être les processus dans divers systèmes.
Le site REST API n'a pas pu remplacer complètement le site RPC, simple et léger, car il produisait une grande quantité de métadonnées, même s'il offrait un format amélioré pour traiter de nombreuses applications. C'est ainsi qu'ont finalement vu le jour les services GraphQL de Facebook et gRPC de Google.
Google a construit gRPC en 2015 comme un ajout au cadre RPC pour connecter de nombreuses architectures de microservices réalisées avec diverses techniques. gRPC était à l'origine étroitement lié à l'infrastructure centrale de Google, mais a finalement été rendu open source et normalisé pour être utilisé par le grand public.
Aperçu des concepts gRPC
La création et la popularité de gRPC s'expliquent par l'utilisation de technologies de pointe, qui offrent des performances supérieures à celles de JSON et XML, ainsi qu'une plus grande intégrité des API. Voici quelques-uns des concepts gRPC que vous devez connaître :
Tampons de protocole
Les tampons de protocole, également connus sous le nom de Protobuf, sont des normes de sérialisation ou de désérialisation qui facilitent la définition des applications et la génération automatique du code des bibliothèques clientes. La version la plus récente, proto3, est plus simple à utiliser et offre les plus récentes fonctionnalités pour gRPC.
.Proto Les fichiers permettent d'activer les services gRPC et les communications entre les clients gRPC et les messages du serveur. Le fichier .proto est chargé en mémoire à l'exécution par le compilateur Protobuf - protoc. Ce compilateur construit des applications client gRPC et serveur gRPC qui utilisent la structure en mémoire pour sérialiser et désérialiser les données binaires. Chaque communication est envoyée et reçue entre l'utilisateur et le service distant après la génération du code dans gRPC.
Comme les données sont traduites sous une forme binaire et que les signaux cryptés sont plus petits, l'analyse syntaxique avec Protobuf utilise moins de puissance CPU pour gRPC. Par conséquent, même sur les ordinateurs dont la puissance de CPU est faible, comme les téléphones portables, les messages sont envoyés plus rapidement avec gRPC.
HTTP/2
Le service gRPC est construit sur HTTP/2, la version de HTTP/1.1 qui présente moins de limitations. Bien qu'il fonctionne avec l'ancien protocole HTTP, HTTP/2 possède plusieurs fonctionnalités sophistiquées pour gRPC. Il s'agit notamment d'une couche d'encadrement binaire, qui divise chaque requête et réponse HTTP/2 en plus petits messages et les encadre au format binaire pour améliorer la livraison des messages. En outre, gRPC prend en charge les demandes et réponses multiples du client et du serveur gRPC en flux bidirectionnel full-duplex.
HTTP/2 dispose d'une méthode de contrôle du flux qui permet un contrôle précis de l'adresse RAM nécessaire à la mise en mémoire tampon des paquets en vol. Il offre également une compression des en-têtes pour les services gRPC. Tout dans HTTP/2 est crypté avant la transmission, même les en-têtes, ce qui permet des appels de procédure à distance très performants. gRPC offre un traitement à la fois asynchrone et synchrone avec HTTP/2, permettant l'exécution de divers types de RPC interactifs et en flux.
Grâce à toutes ces caractéristiques de HTTP/2, les services gRPC peuvent utiliser moins de ressources, ce qui se traduit par des temps de réponse plus rapides entre les applications basées sur le cloud et les services gRPC et par une plus grande autonomie des clients gRPC fonctionnant sur des appareils mobiles.
Streaming
L'une des idées essentielles prises en charge par gRPC est le streaming, qui permet l'exécution de plusieurs processus dans une seule requête. gRPC rend cela possible grâce à la fonction de multiplexage de HTTP/2, qui permet d'envoyer ou de recevoir plusieurs réponses ou requêtes simultanément sur une seule connexion TCP ( Transmission Control Protocol). Les principaux formats de streaming sont les RPC en streaming serveur, les RPC en streaming client RPCs et les RPC en streaming bidirectionnel RPCs.
Canaux
Contrairement aux flux HTTP/2, qui permettent de nombreux flux simultanés sur une seule connexion de demande, un canal avec gRPC prend en charge plusieurs flux continus sur plusieurs demandes. Ils sont utilisés pour construire un stub client et fournir un mécanisme de liaison à un serveur gRPC sur une IP et un port spécifiques.
Architecture gRPC
L'architecture gRPC se compose d'un client gRPC et d'un serveur gRPC. Chaque service client gRPC contient un stub ou un fichier généré automatiquement, qui s'apparente à une interface contenant les processus distants actifs. Le client gRPC lance un appel de procédure locale à un stub contenant des arguments à transmettre aux messages du serveur gRPC. Le stub du client gRPC envoie ensuite la requête à l'unité client-temps locale sur l'ordinateur local après avoir sérialisé les arguments à l'aide de la procédure de marshaling Protobuf.
Le système d'exploitation utilise le protocole HTTP/2 pour communiquer avec l'ordinateur serveur distant. Le système d'exploitation du serveur accepte les messages et invoque le processus de la souche du serveur, qui utilise Protobuf pour invoquer l'opération appropriée après avoir décodé les paramètres entrants. La couche de transport du client reçoit ensuite la réponse chiffrée du stub serveur. L'exécution revient à l'appelant après que le stub client gRPC a reçu les messages de réponse et déballé les arguments fournis.
Avantages de gRPC
gRPC présente plusieurs avantages par rapport aux autres mécanismes de conception d'API. gRPC améliore également la structure de RPC. Voici les avantages les plus importants des services gRPC :
- Appels de procédure à distance haute performance
Grâce à Protobuf et HTTP/2, les services gRPC offrent des performances et une protection de l'API jusqu'à 10 fois supérieures à celles des interactions REST+JSON. Grâce à l'utilisation des poussées de serveur, du multiplexage et de la compression des en-têtes, HTTP/2 fournit des classements de haute performance pour les services gRPC. Alors que le multiplexage élimine le retard en tête de ligne, le push serveur permet à HTTP/2 de pousser des éléments du serveur vers le client avant qu'ils ne soient nécessaires. Les messages sont compressés plus efficacement avec HTTP/2, ce qui se traduit par un chargement plus rapide avec les services gRPC.
- Streaming
La description du service pour les services gRPC de streaming comprend déjà les principes de streaming côté client ou côté serveur. La création de clients gRPC et de services de streaming s'en trouve considérablement simplifiée.
- Génération de code
La génération de code pour les programmes de clients gRPC et de serveurs gRPC est le composant clé de l'approche web gRPC. Pour la génération du code à partir du fichier .proto, les modules gRPC utilisent le compilateur .protoc. Le format Protobuf est contrôlé par la génération de code dans gRPC, qui est utilisé pour définir à la fois les formats de données et les points de terminaison des applications. Il peut créer des stubs de réseau côté client et des squelettes côté serveur, ce qui réduit le temps nécessaire à la conception de programmes comportant une variété de services dans les services gRPC.
- Interopérabilité
De nombreux systèmes et langages de programmation, comme Java, Ruby, GoC#, etc., sont pris en charge par les ressources et bibliothèques gRPC. Avec ces langages de programmation, les développeurs peuvent créer des applications performantes tout en utilisant une compatibilité multiplateforme complète avec gRPC. Ceci grâce à la forme de câblage binaire Protobuf et à la génération efficace de code pour presque tous les systèmes.
- Sécurité
La sécurité de l'API est assurée dans gRPC à l'aide de HTTP/2 sur une session chiffrée TLS de bout en bout. gRPC encourage l'adoption de SSL/TLS pour le chiffrement et l'authentification des données entre le serveur et le client gRPC.
- Productivité et facilité d'utilisation
Puisque gRPC est une alternative complète à RPC, il fonctionne sans problème sur un large éventail de systèmes et de langages. gRPC dispose également d'un excellent outillage, une grande partie du code passe-partout nécessaire étant généré manuellement. Les ingénieurs peuvent désormais se concentrer davantage sur les fonctionnalités de base grâce au gain de temps considérable que permet gRPC.
Les inconvénients de gRPC
Bien que nous puissions espérer que les inconvénients de gRPC seront un jour résolus, ils posent quelques problèmes à son utilisation actuelle. Voici quelques inconvénients de gRPC dont vous devez être conscient :
- Manque de maturité
Le développement d'une technologie peut constituer un obstacle important à son adoption. C'est également évident lorsque l'on utilise gRPC. GraphQL GRPC, l'un des pairs de gRPC, compte plus de 14 000 requêtes sur StackOverflow, alors que gRPC n'en compte qu'un peu moins de 4 000 pour le moment. La communauté gRPC manque de connaissances sur les meilleures pratiques, les solutions et les succès, car il n'y a pas beaucoup d'assistance aux programmeurs pour HTTP/2, ainsi que pour les tampons de protocole en dehors de Google. Toutefois, au fur et à mesure que la communauté gRPC s'étend et attire de nouveaux développeurs, cette situation finira par évoluer.
- Prise en charge limitée des navigateurs
Comme aucun navigateur Web gRPC actuel ne peut gérer les trames HTTP/2, vous ne pouvez pas appeler efficacement un service gRPC à partir d'un navigateur puisque gRPC Web dépend principalement de HTTP/2. Par conséquent, vous devez utiliser un proxy avec gRPC, ce qui présente plusieurs inconvénients.
- Indéchiffrable par les humains
Contrairement à XML et JSON, les fichiers Protobuf ne sont pas lisibles par l'homme puisque les données sont compressées dans un format binaire. Les développeurs doivent utiliser des outils supplémentaires, tels que le protocole de réflexion du serveur et l'invite de commande gRPC pour évaluer les charges utiles, effectuer le dépannage et créer des requêtes manuelles.
- Courbe d'apprentissage abrupte
Il faudra un certain temps pour se familiariser avec les tampons de protocole et découvrir les méthodes permettant de faire face aux frictions de HTTP/2, contrairement à REST et GraphQL, qui utilisent tous deux principalement JSON.
Comment AppMaster peut-il aider ?
La générationsans code est en train de changer la façon dont les gens voient la programmation. La génération sans code permet aux gens d'apprendre et de créer des logiciels plus rapidement grâce à la génération de code. La génération de code pour votre application est plus simple en utilisant des plateformes de génération sans code comme AppMaster. Il n'y a pas non plus de problème de propriété, car la génération de code est protégée, et le code que vous créez n'appartient qu'à vous. Vous pouvez créer des applications client et serveur plus rapidement et plus facilement avec AppMaster.
La plateforme de génération de code d'AppMaster permet aux développeurs d'utiliser le protocole gRPC pour effectuer des requêtes entre les microservices de l'architecture backend. L'année prochaine, nous étendrons le support gRPC en incluant l'API aux applications gRPC Web et gRPC Mobile.
Conclusion
Bien que les services gRPC présentent plusieurs avantages qui les rendent attrayants pour les entreprises et les développeurs, finalement, la décision d'utiliser les services gRPC plutôt que d'autres comme REST ou SOAP dépend de votre application. Alors que certains logiciels bénéficieront de hautes performances avec gRPC, d'autres pourraient être mieux adaptés à ses alternatives. Vous devez comprendre les inconvénients et les avantages des services gRPC et décider s'ils vous conviennent.
