D’après une étude de l’écosystème Github, GraphQL est considéré comme l’une des technos à surveiller de près depuis 2018 au même titre que ReactiveX, les PWAs, Webpack ou ReactJS.

De nombreuses grandes sociétés à travers le monde ont décidé de remplacer leurs API RESTful par GraphQL (par exemple : IBM, Twitter, Walmart Labs, The New York Times…) pour leurs usages internes. D’autres tels que Yelp, Github, Facebook… ; s’en  servent pour un usage externe.

GraphQL est-il devenu le futur des APIs ? est-il un réel acteur du changement ? C’est ce que HaiRun Technology va tenter de développer à travers cet article.

Qu’est-ce que GraphQL ?

GraphQL est un langage de requête créé en 2012 pour une utilisation interne de Facebook puis rendu public en 2015 (Facebook Manifest). Il permet de se plugger à n’importe quel type de base de données ou d’API. Son objectif est de décrire les données et les fonctions disponibles entre les applications client-server.

Il possède un environnement d’exécution permettant de répondre à ces requêtes avec vos données existantes. GraphQL ne stocke donc pas de données. Il va uniquement décrire la donnée et savoir comment aller la récupérer sur vos différentes applications backend.

Il fournit une description complète et compréhensible des données de votre API, donne aux clients le pouvoir de demander exactement ce dont ils ont besoin et rien de plus, facilite l’évolution des API au fil du temps et offre de puissants outils de développement.

Qu’est-ce qu’un API ?

API est l’acronyme d’Application Programming Interface, un logiciel intermédiaire qui permet à deux applications de communiquer entre elles. Chaque fois que vous utilisez une application comme Facebook, envoyez un message instantané ou vérifiez la météo sur votre téléphone, vous utilisez une API.

Lorsque vous utilisez une application sur votre téléphone portable, l’application se connecte à Internet et envoie des données à un serveur. Le serveur récupère ensuite ces données, les interprète, effectue les actions nécessaires et les renvoie à votre téléphone. L’application interprète ensuite ces données et vous présente les informations souhaitées de manière lisible. C’est ce qu’est une API – tout cela se produit via une API.

Comment GraphQL fonctionne ?

GraphQL n’est lié à aucune base de données ni à aucun moteur de stockage spécifique, mais est soutenu par votre code et vos données existantes.

Un service GraphQL est créé en définissant des types et des champs sur ces types, puis en fournissant des fonctions pour chaque champ de chaque type. 

Une fois qu’un service GraphQL est en cours d’exécution (généralement au niveau d’une URL sur un service Web), vous pouvez envoyer des requêtes GraphQL à valider et à exécuter. Une requête reçue est d’abord vérifiée pour s’assurer qu’elle ne fait référence qu’aux types et aux champs définis, puis exécute les fonctions fournies pour produire un résultat.

GraphQL est-il l’avenir?

Depuis le début du Web, le développement d’API était une tâche difficile pour les développeurs.
La façon dont nous développons nos API doit évoluer avec le temps afin de
pouvoir toujours construire de bonnes API, intuitives et bien conçues. GraphQL
connaît depuis quelques années une popularité croissante parmi les développeurs et de nombreuses entreprises ont commencé à adopter cette technologie pour développer leurs API.

Auparavant, lorsque nous devions modifier la conception de nos API de SOAP à REST, nous pensions que ce changement donnerait aux développeurs plus de flexibilité dans leur travail. Nous ne pouvons pas nier que cela a assez bien fonctionné pendant un certain temps et que c’était un bon coup à l’époque. Alors que les applications et le Web sont de plus en plus sophistiqués, les API ont également évolué naturellement, à la suite de ces changements.

C’est alors que beaucoup ont remarqué que REST avait beaucoup de problèmes :

Récupération de données :Source : www.howtographql.com

Avec une API REST, vous devez généralement collecter les données en accédant à plusieurs points de terminaison. Dans l’exemple ci-dessus, il peut s’agir de /users/ point de terminaison pour extraire les données utilisateur
initial. Deuxièmement, il y aura probablement un /users//postsnoeud
final qui renvoie toutes les publications pour un utilisateur.

Le troisième point d’extrémité sera alors celui /users//followersqui renvoie une liste d’abonnés par utilisateur.

Source : www.howtographql.com

Dans GraphQL, par contre, vous envoyez simplement une seule requête au serveur GraphQL qui inclut les exigences de données concrètes. Le serveur répond ensuite avec un objet JSON où ces exigences sont remplies.

Gestion des versions :

Un des points douloureux de REST, est la gestion des versions. Avec les API REST, il est très courant de voir beaucoup d’API avec v1 ou v2, mais dans GraphQL, c’est inutile, car vous pouvez faire évoluer vos API en ajoutant de nouveaux types ou en supprimant d’anciens.

Dans GraphQL, tout ce que vous avez à faire pour faire évoluer votre API est d’écrire du nouveau code. Vous pouvez écrire de nouveaux types, requêtes et mutations sans avoir besoin d’expédier une autre version de votre API.

Plus de surexploitation et de sous-extraction :

L’un des problèmes les plus courants avec REST est celui de la surexploitation et de la sous-extraction. Cela est dû au fait que la seule façon pour un client de
télécharger des données consiste à atteindre les ordinateurs d’extrémité
renvoyant des structures de données fixes . Il est très difficile de concevoir
l’API de manière à pouvoir fournir aux clients leurs besoins en données exactes.

Itérations rapides de produits sur le frontend :

Un modèle courant avec les API REST consiste à structurer les points de terminaison en fonction des vues que vous avez dans votre application. Cela permet au client d’obtenir toutes les informations requises pour une vue particulière en accédant simplement au terminal correspondant.

L’inconvénient de cette approche est qu’elle ne permet pas d’itérations rapides sur le front-end. Avec chaque modification apportée à l’interface utilisateur, il
y a un risque élevé que davantage de données (ou moins) soient nécessaires
qu’auparavant. Par conséquent, le backend doit également être ajusté pour
prendre en compte les nouveaux besoins en données. Cela tue la productivité et ralentit considérablement la possibilité d’intégrer les commentaires des utilisateurs dans un produit.

Avec GraphQL, ce problème est résolu. Grâce à la nature flexible de GraphQL, les modifications côté client peuvent être effectuées sans aucun travail supplémentaire sur le serveur. Étant donné que les clients peuvent
spécifier leurs exigences exactes en matière de données, aucun ingénieur
back-end n’a besoin de procéder à des ajustements lorsque la conception et les besoins en matière de données changent.

Analytique perspicace sur le backend :

GraphQL vous permet d’avoir des informations détaillées sur les données demandées sur le backend. Chaque client spécifiant exactement les informations qui l’intéressent, il est possible de mieux comprendre comment les données disponibles sont utilisées. Cela peut par exemple aider à faire évoluer
une API et à déprécier des champs spécifiques qui ne sont plus demandés par
aucun client.

Avec GraphQL, vous pouvez également contrôler les performances de bas niveau des requêtes traitées par votre serveur. GraphQL utilise le concept de fonctions de résolveur pour collecter les données demandées par un client. L’instrumentisation et la mesure des performances de ces résolveurs fournissent des informations cruciales sur les goulots d’étranglement de votre système.

Avantages d’un schéma et d’un système de types :

GraphQL utilise un système de type fort pour définir les fonctionnalités d’une API. Tous les types exposés dans une API sont écrits dans un schéma à
l’aide du langage SDL (GraphQL Schema Definition Language). Ce schéma sert de contrat entre le client et le serveur pour définir comment un client peut
accéder aux données.

Une fois le schéma défini, les équipes travaillant sur les interfaces frontend et backend peuvent effectuer leur travail sans autre communication, dans la mesure où elles sont toutes deux conscientes de la structure définie des données envoyées sur le réseau.

Les équipes frontales peuvent facilement tester leurs applications en se moquant des structures de données requises. Une fois le serveur prêt, vous pouvez basculer le commutateur pour que les applications client puissent charger les données à partir de l’API réelle.

Les inconvénients de GraphQL?

Même si GraphQl présente divers avantages tels que ceux présentés précédemment (liste non exhaustive) le langage n’est pas parfait, les rubriques suivantes présentent certains des inconvénients de l’utilisation de GraphQL.

Complexité de la requête GraphQL

Les gens confondent souvent GraphQL avec le remplacement des bases de données côté serveur, mais c’est juste un langage de requête. Lorsqu’une requête doit être résolue avec des données sur le serveur, une implémentation indépendante de GraphQL effectue généralement un accès à la base de données. GraphQL n’a pas d’opinion à ce sujet. De plus, GraphQL ne supprime pas les goulots d’étranglement des performances lorsque vous devez accéder à plusieurs champs (auteurs, articles, commentaires) dans une requête. Que la demande ait été faite dans une architecture RESTful ou GraphQL, les ressources et les champs variés doivent toujours être extraits d’une source de données. En conséquence, des problèmes surviennent lorsqu’un client demande trop de champs imbriqués en même temps.
Les développeurs frontaux ne sont pas toujours conscients du travail qu’une
application côté serveur doit effectuer pour récupérer des données. Il doit
donc exister un mécanisme tel que la profondeur maximale des requêtes, la
pondération de la complexité des requêtes et l’évitement de la récursivité.

Limitation de débit de GraphQL

Un autre problème est la limitation du taux. Alors que dans REST, il est plus simple de dire «nous n’autorisons qu’un nombre limité de demandes de ressources en une journée», il est difficile de faire une telle déclaration pour des opérations GraphQL individuelles, car il peut s’agir de tout, d’une opération peu coûteuse ou coûteuse. C’est à ce stade que les sociétés dotées d’API GraphQL publiques proposent leurs calculs spécifiques de limitation de débit, qui se résument souvent aux profondeurs de requête maximales et à la pondération de la complexité des requêtes mentionnées précédemment.

Mise en cache de GraphQL

L’implémentation d’un cache simplifié avec GraphQL est plus complexe que son implémentation dans REST. Dans REST, les ressources sont accessibles avec des URL. Vous pouvez donc mettre en cache au niveau des ressources, car vous avez l’URL de la ressource comme identificateur. Dans GraphQL, cela devient complexe, car chaque requête peut être différente, même si elle opère sur la même entité. Vous ne pouvez demander que le nom d’un auteur dans une requête, mais vous souhaitez connaître l’adresse e-mail lors de la suivante. C’est là que vous avez besoin d’un cache plus fin au niveau du terrain, ce qui peut être difficile à implémenter.
Cependant, la plupart des bibliothèques construites sur GraphQL offrent des
mécanismes de mise en cache prêts à l’emploi.

Pour conclure :

Pour les entreprises qui traitent des données en constante évolution et qui disposent des ressources techniques nécessaires pour réarchiver leurs plates-formes d’API, GraphQL peut résoudre bon nombre des problèmes rencontrés avec les API REST.

GraphQL fournit une solution intéressante aux problèmes courants rencontrés lors de l’utilisation des API REST. Bien que l’utilisation de GraphQL présente
plusieurs inconvénients, si vous travaillez avec des données évoluant
rapidement à grande échelle, cela pourrait être une excellente solution pour
votre entreprise.

GraphQL est destiné à être utilisé pour les applications clientes, où la bande passante et la latence du réseau sont essentielles. Il offre aux clients la possibilité d’interroger un graphe d’objets (une structure hiérarchique d’objets associés).
À l’aide de GraphQL, les clients peuvent également choisir les champs à inclure dans la réponse. Cela simplifie énormément l’utilisation et la gestion de
l’extraction des données chez le client.

Si vous avez des questions ou un projet a réalisé, n’hésitez pas a faire appel a des spécialistes tels que HaiRun Technology. Vous bénéficierez alors d’un
accompagnement sur mesure, ainsi que d’une équipe d’ingénieurs pouvant vous proposer LA SOLUTION qui vous convient.

Sources :

Venez découvrir nos derniers articles :