Lorsque vous aurez besoin de créer une API, votre esprit se tournera probablement vers REPOS, le de facto standard pour la création d'API. Cependant, cette situation est en train de changer avec l'augmentation de GraphQL popularité.
Tout le monde ne comprend pas parfaitement ce qu'est GraphQL ni pourquoi il est déclaré successeur de REST. C'est précisément ce que je vais clarifier dans cet article. Ici, je vais me montrer Principales fonctionnalités de GraphQL et ses avantages par rapport à REST, en soulignant quelques points sur lesquels les deux diffèrent.
L'objectif est de fournir une brève explication à tous ceux qui ne connaissent pas encore GraphQL, de clarifier ce qu'il fait mieux que REST pour ceux qui sont encore sceptiques quant à cette technologie, et dans quels cas nous devrions utiliser GraphQL ou REST.
GraphQL est un langage de requête pour les API qui permet la récupération déclarative des données afin de donner au client le pouvoir de spécifier exactement les données dont l'API a besoin. Cela facilite l'évolution des API au fil du temps.
Maintenant que nous savons ce qu'est GraphQL, je tiens à clarifier ce qu'il n'est pas, car je pense qu'il y a encore une certaine confusion à ce sujet.
Tout d'abord, cela n'a rien à voir avec les bases de données. Ce n'est pas une alternative à SQL ou à un tout nouvel ORM.
Deuxièmement, il ne s'agit pas d'un remplacement REST, mais c'est une alternative. Vous n'avez pas à choisir entre l'un et l'autre, ils peuvent coexister avec bonheur dans le même projet.
Enfin et surtout, GraphQL n'est ni compliqué ni effrayant. Il est assez facile de comprendre son caractère déclaratif et de comprendre exactement comment il est possible d'en tirer le meilleur parti.
GraphQL a été développé en interne par Facebook en 2012 avant d'être open source en 2015, et sa version stable n'a été publiée qu'en juin 2018. Le 7 novembre 2018, le projet GraphQL a été transféré de Facebook à la toute nouvelle GraphQL Foundation, hébergée par la Linux Foundation, une organisation à but non lucratif.
Lee Byron, le créateur de GraphQL, vise à rendre GraphQL omniprésent sur les plateformes Web.
GraphQL est utilisé par équipes de toutes tailles, dans de nombreux environnements et langues différents. Les principales entreprises qui utilisent GraphQL sont Facebook, Github, Pinterest et Shopify.
Avant de passer à la comparaison avec REST, je vais passer en revue une simple requête GraphQL où nous pouvons récupérer un utilisateur ainsi que son nom et son âge :
Et la réponse JSON que nous en obtiendrons :
Comme je l'ai indiqué précédemment, la nature déclarative de GraphQL permet de comprendre incroyablement facilement ce qui se passe à tout moment, car nous écrivons essentiellement JSON objets sans valeurs.
REST a été défini par Roy Fielding, un informaticien qui a présenté les principes REST dans son Thèse de doctorat en 2000.
REST (Representational State Transfer) est un style architectural logiciel qui définit un ensemble de contraintes qui font de tout service Web une véritable API RESTful. Les contraintes REST sont les suivantes :
L'architecture client-serveur signifie que les problèmes d'interface utilisateur doivent être séparés des problèmes de stockage des données afin d'améliorer la portabilité des interfaces utilisateur sur plusieurs plateformes.
Un serveur sans état ne conserve aucune information concernant l'utilisateur qui utilise l'API. Cela signifie que le serveur ne se souvient pas si l'utilisateur envoie sa première demande ou non.
Les réponses de l'API REST doivent se définir comme pouvant être mises en cache ou non afin d'empêcher les clients de fournir des données inappropriées susceptibles d'être utilisées lors de futures demandes.
Un système en couches signifie que si un mandataire ou équilibreur de charge est placé entre le client et le serveur, les connexions entre eux ne devraient pas être affectées et le client ne savait pas s'il était connecté au serveur final ou non.
Une interface uniforme suggère qu'il doit s'agir d'une manière uniforme d'interagir avec un serveur donné quel que soit le type d'appareil ou d'application (site Web, application mobile). La principale directive est que chaque ressource doit être identifiée sur demande.
Compte tenu de toutes les contraintes REST, l'image suivante illustre le style architectural REST :
Il y a deux raisons principales pour lesquelles des entreprises telles que Facebook, Netflix et Coursera a commencé à développer des alternatives à REST :
1. Au début des années 2010, l'utilisation de la téléphonie mobile a connu un essor, ce qui a entraîné certains problèmes liés aux appareils à faible consommation et à la lenteur des réseaux. REST n'est pas la solution optimale pour résoudre ces problèmes ;
2. À mesure que l'utilisation des appareils mobiles augmentait, le nombre de frameworks et de plates-formes frontaux différents qui exécutent des applications clientes augmentait également. Étant donné la rigidité de REST, il était plus difficile de développer une API unique capable de répondre aux exigences de chaque client.
Si nous allons encore plus loin, nous nous rendons compte que la principale raison pour laquelle une solution alternative a été identifiée est que la plupart des données utilisées dans les applications Web et mobiles modernes ont la forme d'un graphique. Par exemple, les articles d'actualité contiennent des commentaires, et ces commentaires peuvent comporter des fonctionnalités telles que des likes ou des drapeaux de spam, qui sont créés ou signalés par les utilisateurs. Cet exemple décrit à quoi ressemble un graphique.
En conséquence, Facebook a commencé à développer GraphQL. Dans le même temps, Netflix et Coursera travaillaient également eux-mêmes sur des alternatives. Après l'open source GraphQL de Facebook, Coursera a abandonné ses efforts et a adopté la nouvelle technologie. Netflix a toutefois continué à développer sa propre alternative REST, puis open source Falcor.
Dans les sections suivantes, j'expliquerai pourquoi GraphQL offre plus de flexibilité que REST, mais examinons d'abord son architecture.
Est-ce que GraphQL est meilleur que REST ? GraphQL fournit un langage de requête qui permet aux clients de demander uniquement les données dont ils ont besoin et permet des mises à jour en temps réel. REST repose sur des points de terminaison et des structures de données rigides. La « meilleure » qualité de GraphQL dépend des exigences spécifiques et de la flexibilité requises dans un projet piloté par API.
Dans cette section, je vais passer en revue point par point un exemple pratique, comparaison de REST à GraphQL afin de démontrer la flexibilité du langage de requête de Facebook.
Imaginez que vous avez un bloguer, et vous voulez que la page d'accueil affiche tous les derniers articles. Pour ce faire, vous devez récupérer les messages, vous allez donc probablement faire quelque chose comme ceci :
OBTENIR /api/posts
Mais que faire si vous voulez aussi voir l'auteur ? Pour y parvenir, trois options s'offrent à vous :
Chacune de ces approches créera un problème qui lui est propre, alors examinons-les une par une pour voir comment GraphQL est capable de résoudre les problèmes suivants.
Avec la première approche, qui consiste à récupérer les auteurs à partir d'une autre ressource, vous vous retrouverez avec deux requêtes de serveur au lieu d'une, et à mesure que vous continuez à évoluer, vous pourriez avoir encore plus de requêtes vers différents points de terminaison afin de récupérer toutes les données nécessaires.
Avec GraphQL, cela ne se produirait pas. Tu n'aurais fait que une seule demande, et vous n'aurez pas à effectuer plusieurs allers-retours vers le serveur, comme indiqué ci-dessous :
En regardant la deuxième approche, qui consiste à modifier la ressource pour renvoyer également l'auteur, vous pouvez voir qu'elle a assez bien résolu le problème. Toutefois, la modification d'une ressource peut avoir un effet secondaire sur d'autres aspects de votre application. Plus précisément, trop farfelu.
Revenons à votre blog, mais cette fois, vous avez également une barre latérale affichant les meilleurs articles mensuels avec leurs titres, leurs sous-titres et leur date, qui utilisent la ressource /api/articles. Puisque vous avez modifié la ressource, elle affiche désormais également l'auteur. Cependant, nous n'en avons pas besoin pour la barre latérale.
Bien que cela ne semble pas être un problème, pour les utilisateurs disposant de forfaits de données limités, il n'est pas idéal qu'un site Web récupère des données inutiles. Depuis GraphQL permet au client de récupérer uniquement les données nécessaires, ce problème n'existerait pas :
Enfin, examinons la dernière approche, qui consiste à créer une ressource qui renvoie les articles avec l'auteur, car il s'agit d'un modèle courant pour structurer les points de terminaison en fonction des vues de votre projet.
Bien que cela puisse résoudre des problèmes tels que celui décrit ci-dessus, cela ralentit également développement front-end, car chaque vue spécifique nécessite son point de terminaison spécifique. Si, à tout moment, une vue a besoin de nouvelles données, le développement doit ralentir jusqu'à ce que le point de terminaison soit mis à jour.
Encore une fois, puisque GraphQL donne au client le pouvoir de récupérer uniquement les données nécessaires, rien ne ralentit, car il est très simple d'ajouter un nouveau champ.
Vous obtiendriez à partir de là :
À cela :
Récapitulons brièvement les différences entre REST et GraphQL :
Comme indiqué précédemment, GraphQL ne remplace pas REST. Malgré leurs différences, GraphQL et REST présentent également des similitudes :
OBTENIRdemande avec une URL et renvoie la demande sous forme de données JSON.Mutationet le Requête types) est identique à la liste des points de terminaison d'un API REST.De nos jours, presque toutes les entreprises ont pour objectif de créer des applications mobiles multiplateformes, car l'interaction du client avec le produit augmente considérablement s'il peut y accéder via son téléphone. Lorsque vous utilisez une application mobile, vous vous attendez à ce qu'elle soit réactive et présente une faible latence.
En utilisant GraphQL, vous pourrez atteindre ces objectifs de manière très simple. Il aide le client à récupérer la quantité de données nécessaire pour afficher une vue spécifique.
Jusqu'à présent, j'imagine que nous partageons la même opinion selon laquelle GraphQL est génial, mais ce n'est pas tout à fait vrai. Il manque encore quelques éléments pour le rendre parfait. Si vous souhaitez intégrer l'un des points suivants de votre projet, vous devriez envisager d'utiliser REST.
De nos jours, chaque navigateur fournit une implémentation d'un cache HTTP pour éviter facilement de récupérer des ressources et pour identifier si deux ressources sont identiques.
Lorsque vous utilisez GraphQL, il n'est pas possible d'obtenir un identifiant global unique pour un objet donné car nous utilisons la même URL pour toutes les requêtes. Pour avoir du cache sur GraphQL, vous devez configurer votre propre cache.
Lorsque vous utilisez REST, vous pouvez créer un système de surveillance basé sur les réponses de l'API. Sur GraphQL, vous n'avez pas cela, car il renvoie toujours 200 OK réponse d'état. Une erreur GraphQL typique ressemble à ceci :
En regardant cette réponse, vous pouvez constater qu'il est très difficile de gérer et de surveiller les différents scénarios d'erreur.
Comme vous le savez maintenant, avec GraphQL, vous pouvez interroger exactement ce que vous voulez quand vous le souhaitez, mais nous devons être conscients que cela entraîne des implications complexes en matière de sécurité. Si un acteur malveillant tente de soumettre une requête imbriquée coûteuse pour surcharger votre serveur ou votre base de données et que votre serveur ne dispose pas des protections appropriées, vous serez vulnérable à DDoS (attaque par déni de service) attaques.
Maintenant que nous savons comment il se compare à REST, parlons de certaines des fonctionnalités propres à GraphQL.
GraphQL utilise son propre système de types pour définir le schéma d'une API, avec sa syntaxe appelée Langage de définition de schéma (SDL). Le schéma sert de contrat entre le serveur et le client pour définir la manière dont un client peut accéder aux données.
Une fois le schéma défini, le front-end et back-end les équipes peuvent travailler de manière indépendante, car le front-end peut être facilement testé à l'aide de données fictives. Le front-end peut également obtenir des informations utiles à partir du schéma, telles que ses types, ses requêtes et ses mutations en utilisant GraphiQL ou introspection. Le Le schéma de GraphQL assure également la sécurité des types, ce qui est un avantage pour le développement front-end et back-end, car il détecte les erreurs de type à un stade précoce.
Exemple de schéma :
GraphQL IDE est l'une des fonctionnalités les plus utiles du développement GraphQL. Il tire parti de sa nature auto-documentée pour faciliter le développement.
À l'aide de GraphiQL ou Terrain de jeu GraphQL, vous pouvez simplement inspecter votre schéma et même exécuter des requêtes et des mutations pour tester votre API.
GraphQL fournit un environnement de développement fluide et rapide avec sa nature déclarative et flexible, offrant de nombreuses améliorations par rapport à REST.
Il possède déjà une grande communauté et un écosystème dynamique, et a déjà été mis en œuvre en plusieurs langues populaires, tels que JavaScript, Allez-y et Java.
Bien que cet article ne fasse que plonger les orteils dans l'océan qu'est GraphQL, son site web contient une pléthore d'informations et constitue un endroit formidable pour apprendre et commencer à utiliser GraphQL.
Si vous souhaitez développer une API à utiliser sur une application mobile tu aurais dû GraphQL comme première option car l'utilisation de la bande passante est importante. Si votre l'application nécessite une API robuste, avec mise en cache et système de surveillance tu devrais opter pour REST.
Cela étant dit, ce n'est pas une technologie parfaite et elle présente tout de même quelques inconvénients par rapport à REST. Mais compte tenu de sa jeunesse, l'avenir s'annonce incroyablement prometteur pour GraphQL.
Développeur Web, on trouve couramment qu'il tape null au lieu de nil. J'adore explorer le style fonctionnel de Javascript.
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
