GraphQL – Changement et amélioration de la façon dont les applications communiquent

Il ne faudra pas longtemps avant que la prochaine génération n’achète des crypto-monnaies et ne vérifie son solde de fiducie dans le lobby de Fortnite entre les parties. Cela sera rendu possible grâce à de nombreux progrès technologiques.

Celui que nous discutons aujourd’hui est la façon dont les données sont transférées (lues, mises à jour, ajoutées/supprimées) entre les applications et les entreprises qui les possèdent. Les interfaces de programmation d’applications (API) sont l’architecture qui définit cette communication de données et, à mesure que ces normes se sont développées, les exigences de traitement et de stockage de données sont devenues moins fastidieuses.

Le leader du peloton en termes d’utilisation de ressources “légères” est GraphQL, un langage de requête et de manipulation de données open-source. La fondation de son écosystème est sa spécification et une collection d’outils qui ont été créés autour de lui.

Il n’est pas nouveau – le temps passe vite. Facebook l’a développé en 2012 et l’a utilisé uniquement à des fins internes pour le développement d’applications mobiles. En 2015, il a été “open source” et aujourd’hui, il est géré par la Fondation GraphQL (https://graphql.org/foundation/) qui supervise son développement ultérieur.

Alors, pourquoi écris-je à ce sujet maintenant ? Une feuille de route typique pour l’adoption d’une technologie suivra les points suivants : 1) les hobbyistes/projets personnels, 2) la mise en œuvre dans plusieurs langages, 3) les mises en œuvre dans les start-ups et les petites entreprises, 4) les entreprises de taille moyenne et utilisées dans le développement de produits, 5) les grandes entreprises et les géants de la technologie.

GraphQL a atteint le niveau 5. Actuellement, il est utilisé par GitHub, Pinterest, Shopify, Microsoft, pour n’en citer que quelques-uns, et plus récemment, en mars 2022, Salesforce.

Lorsque je cherchais un moyen de récupérer des données de manière plus efficace à partir de Salesforce, je suis tombé sur leur documentation GraphQL et j’ai commencé à lire et à regarder les moyens de l’implémenter.

Comment diffère-t-il d’une API REST traditionnelle ?

• L’un des principaux avantages est que avec GraphQL, vous pouvez interroger et n’avoir retourné que les données spécifiques. Si vous ne voulez que deux champs liés à un incident client spécifique, c’est ce que vous obtenez. Une API REST traditionnelle vous retournerait tous les champs associés à l’incident. Cela pourrait être 100 champs ou plus. Maintenant, vous devez faire quelque chose avec toutes ces données que vous n’aviez pas voulu à l’origine. C’est ce qu’on appelle la surenquête de données (la sous-enquête est également un problème).
• Ceci rend GraphQL plus rapide que les autres méthodes d’API lors du retour de données.
• GraphQL est un langage fortement typé qui, entre autres choses, signifie que les erreurs de code sont détectées avant que le programme ne s’exécute et non pendant son exécution.
• Un excellent ensemble d’outils a été construit autour de GraphQL, ce qui l’a rendu très convivial pour les développeurs.
• GraphQL a un seul point de terminaison, contrairement à l’API REST qui a plusieurs points de terminaison. Cela signifie que toutes vos données peuvent être récupérées en une seule requête.

Les deux côtés de la médaille : le demandeur (client) et le fournisseur (hôte GraphQL)

J’ai examiné GraphQL jusqu’à présent du point de vue de la “demande” de données. Lorsqu’une entreprise comme Salesforce ou Microsoft configure une API GraphQL que vous pouvez utiliser pour interroger et manipuler des données (lire, mettre à jour, ajouter).

Par exemple, si nous voulions inclure des données de Salesforce liées aux incidents clients dans un portail client, la façon la plus efficace de procéder serait de demander les données exactes que nous recherchons via une requête GraphQL du portail au serveur GraphQL de Salesforce. Vous obtiendrez exactement les données que vous voulez, sans surenquête ni sous-enquête, et, par conséquent, aucun traitement ou stockage de données supplémentaires ne sera nécessaire.

L’autre côté de la médaille est l’organisation qui configure l’architecture GraphQL afin que vos clients aient une méthode efficace pour accéder aux données qu’ils souhaitent.

Lors de la construction de l’API GraphQL, une organisation crée un modèle qui intègre tous ses systèmes en un seul modèle. Il unifie ces systèmes et, une fois le travail terminé, l’interrogation des données devient transparente via l’API.

Lorsque je compare des applications ou des fournisseurs, je regarde les fonctions qu’ils m’offrent pour récupérer mes données. Je ne veux pas avoir à leur envoyer un e-mail ou me fier à des rapports prédéfinis rigides. Je veux pouvoir “me connecter” à mes données en les interrogeant de manière flexible et en temps opportun. Si cela se résume à deux applications/fournisseurs qui sont similaires sur d’autres points de comparaison, et que l’un offre soit une API REST soit une API GraphQL, je choisirai certainement celui avec l’API.