API REST Vs GraphQl vs gRPC : les differences et leurs usages

API REST Vs GraphQl vs gRPC parlons en peu?

Le software moderne de nos jours ne se limite pas à prendre un probleme et se mettre immediatement à tapper le code, mais de savoir utiliser les instruments qu'il faut pour developper une solution qui peut respecter les exigences du probleme posé non seulement dans l'immediat mais aussi sur la durée. Pour permettre ce qu'on appelle l'intereopeabilité ou mieux la flexibilité du logiciel qu'on est entrain de mettre sur pied ce qui veut dire le rendre modulable et facile à etre integré dans des solutions existentes, on a toujours depuis la nuit des temps voulu un RPC (Remote procedure call ou mieux Requete à distance en français) optimisé c'est à dire la possibilité de pouvoir integrer une fonctionalité externe dans un code pour eviter de ré-inventer la roue c'est ca qu'on appelle RPC, par exemple si je veux integrer un system de géolocalisation dans mon code que ce soit en back comme en front, au lieu d'inventer la roue.. je peux faire appelle à une RPC existante comme les API REST de geolocalisation de google.

Il existe de nos jours plusieurs maniere d'exposer des fonctionalités en mode RPC de maniere qu'elles soient consomées externement:

1. Les API REST:

Depuis deja pas mal d'années, surtout avec la venue des smartphone, on a tendance à diviser les applications en backend pour la logique metier et frontend pour l'experience utilisateur, pour integrer backend et frontend, on utilise des RPC basés sur les API REST qui comme je l'ai decrit plusieurs fois ici sur ma page, n'est autre que d'utiliser le protocole Http avec ses methodes (get, post, patch, put, delete) pour exposer ses fonctionalités coté backend ainsi les rendre accessible à travers json/xml aux differents frontend mobile, web, desktop..l'avantage ici est d'exploiter un protocole existant à savoir le http mais dans un contexte non web, on ne peut pas utiliser les REST API.

2. SoAP:

le protocole SoAP va dans la meme ligne que les REST API à la seule difference qu'une couche au format xml enveloppe les données à faire passer sur http et du coup apporte sa part de complications.

3.GraphQl:

c'est une technique de RPC mis sur pied par facebook et qui cherche à resoudre l'epineux probleme des API REST ou pour chaque fonctionalités, on a une URL ou mieux un lien different ce qui signifit que si le front-end a besoin des données eparpillées sur plusieurs endpoint API rest donc plusieurs URL, il faudra les interroger toutes avant de les consomer ce qui signifit plusieurs requetes http ce qui n'est pas du tout efficient, par ailleur, le plus souvent le front-end peut faire recourt a un endpoint REST pour obtenir plus de données que ce qu'il en avait rellement besoin ce qui n'est pas efficace, GraphQl resoud cette problematique en laissant le consomateur dans ce cas le front-end filtrer lui meme les donnees donc il a besoin c'est un peu comme si la query sql est decidé du coté frontend et non backend et ainsi le backend expose juste un seul endpoint/url/lien et c'est le frontend qui decide ce qu'il veut quand et comment.

4.gRPC:

mis sur pied par google, ce RPC utilise http/2 pour chercher de resoudre le probleme de performance que rencontre les points1, 2, 3 car http/2 contrairement a http/1 supporté par les navigateurs et serveur web, utilise le format binaire et non le format texte comme le http/1 pour l'échange de données ce qui est très efficient en phase de sérialisation et déserialisation, en plus http/1 ouvre plusieurs connections tcp car il est unidirectionnel c'est à dire par exemple du moment ou vous demandez une page web sur http/1 au serveur et jusqu'au moment ou vous avez son affichage complet, il y a plusieurs requetes http effectuées par votre navigateur donc ouverture de plusieurs connections TCP ce qui est couteux en terme de performance, http/2 par contre utilise une technique de multiplexing pour ouvrir une seule connection TCP et ainsi faire plusieurs requetes http dans la meme connection TCP, c'est un gain enorme en terme d'efficacite et de performance pour toutes les applications fait sur http par exemple les flux video..gRPC exploite donc ces avantages de http/2 pour faire du RPC en utilisant un format/protocole appellé protbouf, c'est absolument le future et surtout quand navigateurs et serveurs seront tous sur http/2.

Happy coding

---

---

Share

Comments (0)

Leave A Comment

Your Name:
Comment: