Présentation de GraphQL lors d'une soirée

GraphQL et REST sont deux paradigmes utilisés pour créer des API pour des applications Web.

REST est un ensemble d'identifiants uniques (URL) que les applications utilisent pour demander et envoyer des données.

GraphQL est un langage de requête qui permet aux applications clientes de spécifier précisément les données dont elles ont besoin à partir d'un seul point de terminaison.

Ce sont des technologies liées, elles sont utilisées principalement pour les mêmes choses (ou elles peuvent coexister), mais elles sont très différentes.

Cela semble un peu frais, non? Expliquons leurs différences de manière plus intéressante, ce qui peut vous aider à mieux comprendre GraphQL, et peut-être simplement l'amuser.

Êtes-vous à un cocktail

Vous êtes venu à la fête pour faire du réseautage, vous avez donc besoin d'informations sur les gens qui vous entourent. A proximité, il y a cinq autres invités.

Leurs tags de nom sont les suivants:

Richy REST
Ami de Richy REST
Employeur de Richy REST
Géorgie GraphQL

Étant un fêtard actif et sociable, vous allez directement à Richie Rest et dites: "Salut, je suis Adam Epilation, et qui êtes-vous?" La réponse de Richie Resta est:

{ name: "Richy REST", age: 33, married: false, hometown: "Circuits-ville", employed: true // ... 20 other things about Richy REST } 

Vous vous êtes dit: "Wow, trop d'informations tout de suite." En essayant d'éviter un silence gênant, vous vous souvenez que Richie Rest a mentionné qu'il travaille et demande: "Où travaillez-vous?"

Étonnamment, Richie Rest n'a aucune idée de l'endroit où il travaille. Peut-être que l'employeur Richie Resta est au courant?

Vous posez la même question à l'employeur Ritchie Resta, qui est heureux de répondre à votre question:

 { company: "Mega Corp", employee_count: 11230, head_quarters: "1 Main Avenue, Big City, 10001, PL" year_founded: 2005, revenue: 100000000, // ... 20 other things about Richy REST Employer } 

À ce stade, vous êtes déjà épuisé. Vous ne voulez même pas rencontrer un ami de Richie Resta! Cela peut prendre une éternité, gaspiller toute votre énergie, et en plus, vous n'avez plus de temps.

Cependant, Georgia GrafKewel est très proche et vous décidez de discuter avec elle.

"Salut, quel est ton nom?"

 { name: "Georgia GraphQL" } 

"D'où venez-vous et quel âge avez-vous?"

 { hometown: "Pleasant-Ville", age: 28 } 

"Combien de passe-temps et d'amis avez-vous et quel est le nom de vos amis?"

 { hobbies_count: 12, friends_count: 50, friends: [ { name: "Steve" }, { name: "Anjalla" }, // ...etc ] } 

Georgia GrafKewEl est incroyable, articule clairement ses pensées, concises et précises. Vous voulez certainement échanger des cartes de visite avec elle et travailler ensemble sur de futurs projets.

Cette histoire comprend l'expérience des développeurs travaillant avec GraphQL et REST. GraphQL permet aux développeurs de formuler ce qu'ils veulent avec une requête soignée et d'obtenir uniquement ce qu'ils spécifient en réponse. Ces requêtes sont dynamiques, donc un seul point de terminaison est requis. REST, au contraire, a des réponses prédéfinies et nécessite que les applications utilisent plusieurs points de terminaison pour interroger complètement les données.

Terminez avec les métaphores. Passons aux choses sérieuses

Pour plus de détails sur les concepts présentés dans la métaphore de la partie, nous nous tournons spécifiquement vers deux limitations qui surviennent souvent lors de l'utilisation de REST.

1. Résultats multiples sur l'obtention de ressources connexes

La gestion des données pour les applications mobiles et Web nécessite souvent des ressources et des ensembles de données associés. Ainsi, l'obtention de données à l'aide de l'API REST peut entraîner de nombreuses demandes pour plusieurs points de terminaison. Par exemple, une demande de publication et son auteur associé peuvent être effectués par deux demandes à des points de terminaison différents:

 someServer.com/authors/:id someServer.com/posts/:id 

Les appels répétés à l'API affectent les performances de l'application. Cela est encore plus important pour les appareils à faible bande passante (par exemple, les montres intelligentes, l'IoT, les anciens appareils mobiles, etc.).

2. Trop chercher et trop peu chercher

La sur-récupération / sous-récupération est inévitable lors de l'utilisation de l'API RESTful. En utilisant l'exemple ci-dessus, le point de terminaison domainName.com/posts/:id récupère des données pour un enregistrement spécifique. Chaque entrée se compose d'attributs tels que id, corps, titre, publishingDate, authorId et autres. Dans REST, une réponse est prédéfinie et le même objet de données est toujours renvoyé.

Dans les situations où seuls le titre et le texte de l'enregistrement sont requis, la récupération excessive se produit car plus de données sont envoyées sur le réseau qu'elles ne sont réellement utilisées.

Lorsque l'intégralité de la publication est requise, ainsi que les données associées sur son auteur, la sous-récupération est insuffisante, car moins de données sont envoyées sur le réseau qu'elles ne sont réellement utilisées. La sous-récupération insuffisante des données entraîne une augmentation du nombre de demandes d'API et, par conséquent, une utilisation excessive des ressources Internet.

Requêtes client avec GraphQL

GraphQL représente une approche unique qui donne une grande flexibilité aux applications clientes. Avec GraphQL, la requête est envoyée à votre API, et exactement ce dont vous avez besoin est retourné - ni plus, ni moins - en une seule requête. Les résultats de la requête sont renvoyés sous la même forme que la requête elle-même, garantissant que la structure de réponse est toujours prévisible. Ces facteurs permettent aux applications de s'exécuter plus rapidement et d'être plus stables car elles contrôlent les données qu'elles reçoivent, pas le serveur.

"Les résultats sont retournés sous la même forme que les requêtes"

 /* Query */ { myFriends(first: 2) { items { name age } } } 

 /* Response */ { "data": { "items": [ { "name": "Steve", "age": 27 }, { "name": "Kelly", "age": 31 } ] } } 

Vérification de la réalité

Maintenant, vous pensez probablement que travailler avec GraphQL est aussi simple que de couper du beurre chaud avec une épée de samouraï. Cela peut être vrai pour les développeurs frontaux. Cependant, quand il s'agit de configurer le côté serveur, quelqu'un doit faire le travail le plus difficile. Notre amie Georgia GrafKewEl a déployé beaucoup d'efforts pour devenir un professionnel chic.

La création de l'API GraphQL côté serveur prend du temps, des efforts et de l'expérience. Néanmoins, ceux qui sont prêts pour les tests peuvent y faire face. Il existe de nombreuses façons de procéder, par exemple:

Seul: si vous voulez vraiment tout faire vous-même, essayez de créer l'API GraphQL avec des packages. Vous utilisez Rails? Essayez graphql-ruby. Vous aimez Node.js? Essayez express-graphql.

Avec l'aide : si la configuration d'hébergement flexible est une priorité pour vous, alors quelque chose comme Graph.cool peut vous aider à démarrer avec le projet GraphQL.

Instantané : Fatigué d'écrire un modèle CRUD et vous souhaitez commencer rapidement? 8base fournit une API GraphQL instantanée et un serveur principal qui peut être étendu.

En conclusion

Pour les services Web, REST a été un pas en avant significatif, facilitant la création d'API pour accéder aux ressources nécessaires. Cependant, sa conception ne tenait pas compte de la prolifération actuelle des appareils mobiles, avec diverses restrictions sur le volume et les exigences de téléchargement de données. Cette omission a conduit à la popularité croissante de GraphQL, que Facebook a rendu open source en 2015, principalement en raison de la flexibilité qu'il offre aux développeurs front-end. Travailler avec GraphQL est une expérience fantastique pour les développeurs individuels et les équipes.