GraphQL : le “tueur” de l’API REST ?

Après l’implémentation du support GraphQL dans Parse, de nombreuses personnes m’ont contacté pour me poser quelques questions, certaines d’entre elles s’inquiétant de l’avenir de l’API REST.
GraphQL va-t-il la “tuer” ?
Qu’adviendra-t-il de mes méthodes REST API ? Dois-je réécrire mon code ?

Dans cet article, j’aborderai ces questions, mais la réponse courte est : non, vous n’avez pas à vous inquiéter car GraphQL ne va pas ” tuer ” l’API REST et vous n’avez pas non plus à vous soucier de la réécriture de vos méthodes REST API déjà opérationnelles.

Alors, quel est l’intérêt de GraphQL ?

La plupart des personnes qui me contactent ont une idée fausse : GraphQL n’est pas là pour remplacer l’ensemble du backend.

GraphQL ne va pas remplacer le backend. Ni le Frontend.

GraphQL est un langage de requête, un moyen pour vous de spécifier pour votre API les informations que vous recherchez, et un runtime qui obtiendra ces informations à partir de vos données préexistantes.

Il s’agit simplement d’une manière différente (meilleure, dirais-je) de dire à votre application exactement ce que vous avez besoin de savoir et de recevoir ensuite ces informations.

Vous n’avez pas à vous préoccuper de vos méthodes REST API existantes et fonctionnelles. Elles continueront à fonctionner comme elles le font actuellement, même si vous adoptez GraphQL. La seule chose à noter est que GraphQL ne fonctionne que sur Parse 3.5.0 et plus, donc, si vous venez de Parse 2.x ou plus ancien, cela implique également un changement de la structure du code de Parse.

Donc si vous utilisez Parse 3.0 ou plus, vous n’avez pas à vous inquiéter. Il vous suffit de choisir une version supérieure à 3.5.0 et vous êtes prêt à partir.
Si vous utilisez Parse 2.X, vous aurez un peu de travail de codage à faire.

Et pourquoi GraphQL si mon API REST fonctionne déjà ?

Cette question revient souvent et je pense qu’il y a quelques avantages à choisir GraphQL plutôt que REST API.

À court terme, si votre application est déjà écrite à l’aide de l’API REST et qu’elle répond à tous vos besoins, il n’y a aucune raison de migrer vers GraphQL et de réécrire le code pour de simples raisons.

En revanche, si vous démarrez maintenant ou si vous prévoyez une application évolutive, qui gagnera en complexité et que vous souhaitez être prêt pour une maintenance future simplifiée, GraphQL peut vraiment s’avérer utile et vous apporter beaucoup de valeur.

Vous avez dit “valeur” ?

Oui, j’ai bien dit cela.

GraphQL présente quelques avantages clés qui simplifient le développement du code, la maintenance au fil du temps et peuvent même vous aider à économiser sur le transfert de données ! Oui, c’est vrai ! Vous avez bien lu.

Voyons cela point par point :

• Simplifier le développement du code

  Au tout début, lorsque vous vous lancez dans l’utilisation de GraphQL, il se peut que vous ayez à produire un peu plus de code. Ne vous laissez pas effrayer par cela.
  GraphQL simplifiera l’écriture de vos requêtes, en particulier si vous utilisez notre Console GraphQL. L’utilisation des schémas que Parse crée automatiquement et la publication de méthodes génériques et spécifiques pour les requêtes et les mutations pour toutes vos classes vous feront gagner beaucoup de temps. Et je dis bien beaucoup.
  De la documentation ? Pas de problème. Nous nous en occupons également. Et elle est également générée automatiquement.
  De plus, avec GraphQL, vos développeurs pourront compter sur les schémas générés par Parse, de sorte qu’ils sauront à l’avance quelles sont les méthodes dont ils disposent, quels sont les paramètres de chaque méthode et quels sont les retours disponibles (outputs). Plus besoin de deviner ou de demander aux autres ce que fait cette méthode, quels sont les paramètres requis ou ce qu’elle renvoie. Tout est là pour vous.

• Simplifier la maintenance

  La maintenance avec GraphQL est très simple. Comme les appels à l’API sont essentiellement les mêmes, il suffit de modifier la requête ou la mutation que vous transmettez, d’ajouter ou de supprimer des valeurs ou des paramètres renvoyés pour modifier la requête ou la mutation qui les reçoit ou les délivre.
  Il n’est pas nécessaire de modifier un grand nombre d’appels, de blocs ou de promesses. Changez la requête ou la mutation : C’EST FAIT !

• Economiser sur le transfert de données

  Après un certain temps de travail dans Back4app, il est assez courant d’aider les clients à optimiser leur code pour obtenir des réponses plus rapides. Et de tous les problèmes que je trouve dans les codes de mes clients, la grande majorité est due à la récupération de données dont l’application n’a pas besoin à ce moment-là.
  Une erreur très fréquente avec les API REST ou même les frameworks Parse est de récupérer toutes les informations d’un objet et de n’utiliser qu’une partie de ces informations. Par exemple :
  Vous avez une classe nommée Personne avec quelques propriétés : nom, téléphone, adresse, numéro de sécurité sociale, courriel, parmi quelques autres.
  Habituellement, les personnes qui utilisent l’API REST ou le Parse Frameworks essaient d’interroger l’objet Personne dans son intégralité, en récupérant toutes ses propriétés, puis en n’utilisant qu’une ou deux d’entre elles.
  Avec GraphQL, comme vous devez spécifier exactement les informations que vous avez besoin de récupérer, le développeur n’a aucune chance de récupérer des informations inutiles, ce qui se traduit par des charges utiles beaucoup plus petites, et donc des réponses plus rapides, moins de consommation de plans de données et moins de trafic sortant dans l’ensemble. C’est génial, non ?

Faites un essai

La meilleure façon de voir les avantages que GraphQL peut apporter à votre processus de développement est de l’essayer.
Voici quelques scénarios avec lesquels vous pouvez jouer et voir comment il se comporte :

• Essayez de créer une requête GraphQL sans spécifier exactement ce que vous voulez récupérer

  Vous ne pourrez pas le faire. Il vous demandera obligatoirement de spécifier ce que vous voulez et ne récupérera que cela. Rien d’autre.
  Si vous ou vos développeurs oubliez de le faire, GraphQL ne les laissera pas s’en sortir.

Manque ce que je récupère

Et voilà !

• J’essaie de modifier un objet à l’aide d’une requête

  Non. Vous voulez modifier quelque chose ? Utilisez la bonne méthode : Mutation.
  Si vous ou vos développeurs utilisez la mauvaise méthode, GraphQL ne les laissera pas continuer.

Une requête pour modifier des données ? Non, non, non !

La mutation vous couvre !

• Plusieurs objets, plusieurs requêtes ? Non, pas du tout ! Une seule requête !

  GraphQL permet de récupérer très facilement des informations sur plusieurs objets à l’aide d’une seule requête, ce qui simplifie le développement et rend le code moins sujet aux erreurs.
  Imaginons que vous ayez une classe Personne et qu’une personne puisse avoir un chien, à partir de la classe Chien. Vous devez extraire des informations de ces deux classes : le nom et l’âge de la personne, ainsi que le nom et la race du chien. Simple comme bonjour :

Le versionnage ? Pourquoi ?

Le code de versionnement, c’est tellement 2018.
Ajoutez de nouveaux champs à votre requête. Les anciens appels fonctionneront toujours :

Ceci fonctionne

Ceci fonctionne également. Les appels à l’ancien type continueront à fonctionner.

Champs dépréciés, avez-vous dit ? Facile aussi :

Conclusion

GraphQL n’est pas là pour tuer quoi que ce soit. Il est là pour apporter une nouvelle façon de faire les choses. Meilleure, plus rapide, plus facile à maintenir et moins sujette aux erreurs.

Il vous maintiendra sur la bonne voie lorsque vous dérapez. Il vous dira ce que vous pouvez faire et ce que vous ne pouvez pas faire.

Avec Parse, les méthodes auto-générées (génériques et spécifiques) et la documentation, il vous permettra d’apprendre sa façon de faire en un clin d’œil.

Si vous n’avez jamais essayé, vous devriez le faire. Tous les jeunes branchés le font.

Si vous voulez en savoir plus sur GraphQL vs REST, consultez notre article sur Medium.