Smashing Podcast Épisode 31 Avec Eve Porcello : Qu'est-ce que GraphQL ?

Dans cet épisode, nous parlons de GraphQL. De quoi s'agit-il et comment résout-il certains problèmes d'API courants ? J'ai parlé avec l'expert Eve Porcello pour le savoir.

Afficher les remarques

• Eve sur Twitter
• La compagnie d'Eve Moon Highway
• Apprendre GraphQL avec O'Reilly
• Découvrez votre chemin à travers le GraphQL Wilderness - Lancement de l'atelier GraphQL d'Eve début 2021

Mise à jour hebdomadaire

• Comment utiliser MDX stocké dans Sanity dans un site Web Next.js
  écrit par Jason Lengstorf
• Construire un chatbot conversationnel activé par la PNL à l'aide du Dialogflow de Google
  écrit par Nwani Victoire
• Considérations éthiques dans la recherche UX : le besoin de formation et de révision
  écrit par Victor Yocco
• Rendre les sites Web plus faciles à consulter
  écrit par Frederick O'Brien
• Comment concevoir une interface utilisateur simple lorsque vous avez une solution complexe
  écrit par Suzanne Scacca

Transcription

Drew McLellan : Elle est ingénieure en logiciel, instructrice, auteure et cofondatrice de la société de formation et de développement de programmes, Moon Highway. Sa carrière a débuté par la rédaction de spécifications techniques et la création de conceptions UX pour des projets Web. Depuis le lancement de Moon Highway en 2012, elle a créé du contenu vidéo pour egghead.io et LinkedIn Learning, et a co-écrit les livres Learning React et Learning GraphQL pour O'Reilly's Media.

Drew: Elle est également une conférencière fréquente et a présenté des conférences telles que React Rally, GraphQL Summit et OSCON. Nous savons donc qu'elle est une experte en GraphQL, mais saviez-vous qu'elle a déjà appris à un ours polaire à jouer aux échecs ? Mes chers amis, veuillez accueillir Eve Porcello.

Drew : Salut Eve, comment vas-tu ?

Eve Porcello : Je fracasse.

Drew : Comme je l'ai mentionné là-bas, vous êtes vraiment un éducateur dans des choses comme JavaScript et React, mais je voulais vous parler aujourd'hui de l'un de vos autres domaines de spécialisation, GraphQL. Beaucoup d'entre nous ont entendu parler de GraphQL dans une certaine mesure, mais ne savent peut-être pas exactement ce qu'il est, ou ce qu'il fait, et en particulier, quel type de problème il résout dans la pile Web.

Drew : Alors préparez-nous le terrain, si vous voulez, si je suis un développeur frontal, où GraphQL s'intègre-t-il dans l'écosystème et quelle fonction remplit-il pour moi ?

Ève : Ouais. GraphQL s'intègre en quelque sorte entre le front-end et le backend. C'est une sorte de vie au milieu entre les deux et donne beaucoup d'avantages aux développeurs front-end et aux développeurs back-end.

Eve : Si vous êtes un développeur frontal, vous pouvez définir toutes vos exigences en matière de données frontales. Donc, si vous avez une grande liste de composants React, par exemple, vous pouvez écrire une requête. Et cela va définir tous les champs dont vous auriez besoin pour remplir les données de cette page.

Eve : Maintenant, avec le backend, c'est vraiment propre, parce que nous pouvons collecter beaucoup de données à partir de nombreuses sources différentes. Nous avons donc des données dans les API REST, les bases de données et tous ces différents endroits. Et GraphQL nous fournit cette jolie petite couche d'orchestration pour vraiment donner un sens au chaos de l'endroit où se trouvent toutes nos données. C'est donc vraiment utile pour tout le monde partout dans la pile.

Drew : Il s'agit donc essentiellement d'une technologie basée sur une API, n'est-ce pas ? Il se situe entre votre front-end et votre back-end et fournit une sorte d'API, n'est-ce pas ?

Eve : Ouais, c'est tout à fait ça. Exactement.

Drew : Je pense qu'au cours de la dernière décennie, l'étalon-or pour les API a été le repos. Donc, si vous avez une application côté client et que vous devez la remplir avec des données du backend, vous créerez un point de terminaison d'API REST et vous l'interrogerez. Alors, où ce modèle tombe-t-il? Et quand pourrions-nous avoir besoin de GraphQL pour résoudre cela pour nous ?

Eve : Eh bien, le problème avec lequel GraphQL nous aide vraiment, une sorte de problème en or, la solution en or, je suppose, que GraphQL fournit, c'est qu'avec REST, nous récupérons trop de données. Donc, si j'ai des utilisateurs ou des produits slash, cela me rendra toutes les données à chaque fois que je prendrai la route.

Eve : Avec GraphQL, nous pouvons être un peu plus pointilleux sur les données que nous voulons. Donc, si je n'ai besoin que de quatre champs d'un objet qui en a cent, je vais pouvoir vraiment identifier ces champs et ne pas avoir à charger de données, ou charger toutes ces données, je devrais dire, dans votre appareil, parce que c'est beaucoup de démarches supplémentaires, pour votre téléphone en particulier.

Drew : J'ai vu et travaillé avec des API REST dans le passé qui ont un champ facultatif où vous pouvez transmettre une liste des données que vous souhaitez récupérer, ou vous pouvez augmenter ce qui revient avec des éléments supplémentaires. Et donc je suppose que cela identifie ce problème, n'est-ce pas? Cela dit, vous ne voulez pas toujours récupérer les mêmes données à chaque fois. Alors est-ce que GraphQL formalise cette approche permettant au frontal de spécifier ce que le backend va retourner, en termes de données ?

Eve : Ouais, exactement. Ainsi, votre requête devient alors comment vous demandez, comment vous filtrez, comment vous saisissez n'importe quel type d'information de n'importe où.

Eve : Je pense également qu'il est important de noter que nous n'avons pas besoin de démonter toutes nos API REST pour travailler avec GraphQL vraiment avec succès. Un grand nombre des implémentations les plus réussies de GraphQL que j'ai vues, ce sont des wrappers autour des API REST. Et la requête GraphQL vous donne vraiment un moyen de réfléchir aux données dont vous avez besoin. Et puis peut-être que certaines de vos données proviennent de nos utilisateurs et de nos produits, par exemple, certaines des données proviennent de REST, certaines d'entre elles proviennent d'une base de données.

Drew : Je suppose que le scénario le plus courant est que vous pourriez avoir un point de terminaison sur votre site Web qui renvoie des informations sur un utilisateur pour afficher l'en-tête. Cela pourrait vous donner leur nom d'utilisateur et leur avatar. Et vous supprimez cela sur chaque page et remplissez les données, mais vous trouvez ensuite ailleurs dans votre application que vous devez afficher leur nom complet.

Drew : Donc, vous ajoutez cela au point de terminaison et il commence à le renvoyer. Et puis vous faites votre section de gestion de compte, et vous avez besoin de leur adresse postale. Donc, cela est également renvoyé par ce point de terminaison.

Drew : Et avant que vous ne vous en rendiez compte, ce point de terminaison renvoie toute une charge utile lourde qui coûte assez cher en backend à assembler, et évidemment beaucoup à télécharger.

Drew : Et cela a été supprimé sur chaque page uniquement pour montrer un avatar. Donc je suppose que c'est le genre de problème qui grandit avec le temps, dans lequel il était si facile de tomber, en particulier dans les grandes équipes, que GraphQL, c'est en plus de ce problème. Il sait comment résoudre cela, et il est conçu pour résoudre cela.

Ève : Exactement. Et oui, je pense que toute cette idée d'un schéma GraphQL, je pense que c'est vraiment, on en parle moins que la partie langage de requête de GraphQL. Mais j'ai vraiment l'impression que le schéma en particulier nous donne ce joli système de type pour l'API.

Eve : Ainsi, n'importe quel membre de l'équipe, les managers, les développeurs front-end, les développeurs back-end, toute personne qui s'occupe vraiment de données peut se réunir, se regrouper autour des données que nous voulons réellement servir sur cette API, et alors tout le monde sait ce que cette source la vérité est qu'ils peuvent créer leurs propres parties de l'application en fonction de cela.

Eve : Il y a donc des problèmes de gestion de schéma délicats qui en découlent également. Mais en ce qui concerne le retour des microservices aux monolithes, nous le faisons en quelque sorte, mais nous obtenons toujours tous les avantages que nous aimons des microservices.

Drew : Et ai-je bien compris que la façon typique de configurer un système GraphQL est que vous auriez essentiellement une route, qui est le point de terminaison auquel vous envoyez toutes vos requêtes pour que vous n'ayez pas à… Souvent l'un des la chose la plus difficile est de savoir quoi nommer et quel devrait être le chemin vers lequel cette requête particulière devrait se trouver. Il revient aux utilisateurs et aux produits, devrait-il s'agir de réduire quelque chose aux utilisateurs ou de réduire quelque chose au produit ?

Drew : Avec GraphQL, vous n'avez qu'un point de terminaison sur lequel vous lancez vos requêtes et vous obtenez une réponse appropriée.

Ève : Exactement. Ouais. C'est un point final unique. Je suppose que vous avez toujours affaire à des problèmes de nommage parce que vous nommez tout dans le schéma. Mais en ce qui concerne, j'ai l'impression que beaucoup d'entreprises qui ont fait de gros paris sur les microservices, tout le monde est comme, quels terminaux avons-nous ? Où sont-elles? Comment sont-ils documentés ? Et avec GraphQL, nous avons un seul endroit, un seul type de dictionnaire pour rechercher tout ce que nous voulons savoir sur le fonctionnement de l'API.

Drew : Donc, je connais très bien les autres langages de requête, comme SQL, qui est un exemple évident de langage de requête que de nombreux développeurs Web connaissent. Et les requêtes en cela prennent presque la forme d'une commande. C'est une chaîne de texte, n'est-ce pas, Sélectionnez ceci à partir de cela, où, peu importe. Quel format les requêtes prennent-elles avec GraphQL ?

Eve : C'est toujours une chaîne technique, mais elle ne définit pas d'où vient cette logique. Et une grande partie de la logique est renvoyée au serveur. Ainsi, le serveur GraphQL, l'API GraphQL est vraiment chargé de dire : "Allez chercher ces données là où elles se trouvent, filtrez-les en fonction de ces paramètres."

Eve : Mais dans le langage de requête, c'est très orienté terrain. Nous ajoutons donc simplement des champs pour tout ce que nous voulons récupérer. Bien sûr, nous pouvons aussi mettre des filtres sur ces requêtes. Mais je pense que c'est un peu moins direct quant à l'origine de cette information. De nombreuses fonctionnalités sont intégrées au serveur.

Drew : Vous pouvez donc mélanger et assortir dans une requête. Vous pouvez faire une requête qui ramène de nombreux types de données différents en une seule requête. Est-ce correct?

Eve : Oui, c'est tout à fait vrai. Vous pouvez donc envoyer une requête pour autant de champs que votre serveur le permet et ramener toutes sortes de données imbriquées. Mais c'est vraiment comme ça que ça marche, on connecte différents types sur les champs. Je suppose donc que nous allons recycler mon idée d'utilisateurs et de produits, mais l'utilisateur peut avoir un champ de produits qui renvoie une liste de produits. Tous ces éléments sont également associés à d'autres types. Donc, aussi profondément imbriqué que nous voulons que la requête aille, nous le pouvons.

Drew : Cela signifie-t-il donc qu'il faut récupérer les données d'une vue typique de votre application Web qui peut avoir toutes sortes de choses, que vous pouvez simplement faire une demande au backend et obtenir tout cela en une seule fois sans avoir besoin de faire différentes requêtes à différents points de terminaison, car tout cela ne fait qu'un ?

Ève : Ouais. C'est exactement tout l'objectif, c'est juste une seule requête, définissez chaque champ que vous voulez, puis renvoyez-le en une seule réponse.

Drew : Et les requêtes sont basées sur JSON, n'est-ce pas ?

Eve : la requête elle-même est une chaîne de texte, mais elle renvoie généralement des données JSON. Donc, si j'ai les champs, alors ma réponse JSON correspond exactement, et il est donc très clair ce que vous obtenez lorsque vous envoyez cette requête, car la réponse de données est exactement la même.

Drew : Beaucoup de requêtes semblent concerner presque des objets nus, comme un client ou un produit. Existe-t-il un moyen de spécifier des requêtes plus complexes où la logique métier est contrôlée au niveau du backend ? Supposons que je souhaite obtenir une liste d'équipes pour un utilisateur, mais uniquement lorsque cet utilisateur est l'administrateur d'une équipe et que le plan d'équipe n'a pas expiré, et toutes ces sortes de contraintes réelles auxquelles nous sommes confrontés dans le développement quotidien d'applications Web. Cela peut-il être réalisé avec GraphQL ?

Ève : Absolument. C'est donc ce qui est vraiment excitant et puissant avec GraphQL, c'est que vous pouvez déplacer une grande partie de cette logique vers le serveur. Si vous aviez une requête complexe, un type d'utilisateur vraiment spécifique que vous vouliez obtenir, tout ce que vous auriez à faire dans le schéma est de dire "Obtenir un utilisateur compliqué", puis sur le serveur, il y aurait une fonction où vous pouvez écrire toute la logique dans la langue de votre choix. JavaScript est en quelque sorte le langage d'implémentation GraphQL le plus populaire, mais vous n'êtes pas obligé de l'utiliser du tout. Donc Python, Go, C++, tout ce que vous voulez utiliser, vous pouvez construire un serveur GraphQL avec ça. Mais oui, vous pouvez définir une requête aussi complexe que vous le souhaitez.

Drew : Et je suppose que cela vous permet d'encapsuler une grande partie de la logique métier dans de nouveaux types d'objets. Est-ce juste? Vous savez, vous configurez un utilisateur compliqué et vous n'avez pas besoin de penser à ce qu'est un utilisateur compliqué, mais vous pouvez simplement continuer à utiliser cet utilisateur compliqué et savoir que la logique métier est implémentée dessus. Est-ce correct?

Eve : C'est tout à fait ça. Je pense donc que c'est vraiment bien pour les gens du front-end car ils peuvent commencer à prototyper sur cette base. Et ensuite, l'équipe backend pourrait implémenter ces fonctions pour que cela fonctionne. Et puis il y a une sorte de compréhension partagée de ce qu'est réellement ce type et de qui ils sont, et "Quels sont les champs de ce type?" Et tout peut être géré par n'importe quel endroit de la pile où GraphQL fonctionne. Et c'est pourquoi ce n'est pas vraiment une technologie frontale ou dorsale. C'est vraiment un peu les deux, et ni l'un ni l'autre.

Drew : On dirait qu'il s'agit en quelque sorte de formaliser l'API et la relation entre le front-end et le back-end, de sorte que tout le monde obtient une interface prévisible et standardisée.

Ève : Exactement.

Drew : Ce qui, je suppose, dans les organisations où le front-end et le back-end appartiennent à des équipes différentes, ce qui n'est pas du tout rare, je suppose que cette approche permet également d'apporter des modifications, par exemple, sur le front-end, cela peut nécessiter différents données, sans avoir besoin de quelqu'un qui travaille sur le backend pour faire les changements qui correspondent à cela. Vous avez toujours cette API personnalisable presque à l'infini sans qu'aucun travail ne soit nécessaire pour la modifier si vous avez besoin de nouvelles données.

Eve : Oui, tout à fait.

Drew : Alors, le serveur GraphQL est-il responsable du formatage de la réponse, ou avez-vous besoin de le faire dans votre logique côté serveur ?

Eve : Donc, le serveur GraphQL définit deux choses. Il définit le schéma lui-même qui vit sur le serveur, puis il définit les fonctions de résolution. Ce sont des fonctions qui récupèrent les données où qu'elles se trouvent. Donc, si j'ai une API REST que j'enveloppe avec GraphQL, le résolveur extrait de cette API, transforme les données comme il le faut, puis les renvoie au client dans cette fonction. Vous pouvez également utiliser toutes les fonctions de base de données que vous souhaitez sur ce serveur. Donc, si vous avez des données dans un tas d'endroits différents, c'est un très bel endroit cohérent pour mettre toutes ces données et pour concevoir toute la logique autour, « Où viennent ces données ? Comment voulons-nous le transformer ?

Drew : Le client dit : "Je veux un utilisateur complexe", le serveur le reçoit dans une requête et peut dire : "Bien, je vais rechercher le résolveur d'utilisateur complexe". Est-ce correct?

Eve : Mm-hmm (affirmative).

Drew : Quelle est la fonction, puis vous écrivez votre logique pour que votre équipe backend, ou quiconque écrit la logique à l'intérieur de cette fonction, fasse tout ce qui est nécessaire pour renvoyer un utilisateur complexe.

Eve : Ouais, exactement.

Drew : Cela pourrait donc appeler d'autres API, interroger une base de données, rechercher des éléments dans le cache ou à peu près n'importe quoi.

Eve : À peu près n'importe quoi. Et puis, tant que ce retour de la fonction correspond aux exigences du schéma, correspond à quels champs, quels types, y retournaient, alors tout fonctionnera bien et harmonieusement.

Drew : Je suppose que cela vous donne un format de réponse cohérent sur l'ensemble de votre API, juste par défaut. Vous n'avez pas à concevoir à quoi cela ressemble. Vous obtenez juste un résultat cohérent.

Eve : Ouais, exactement.

Drew : Je pense que cela pourrait être vraiment une victoire, car il peut être très difficile de maintenir la cohérence sur une large gamme de points finaux d'API, en particulier dans les grandes équipes. Différentes personnes travaillent sur différentes choses. À moins d'avoir une gouvernance assez stricte en place, cela peut devenir très complexe très rapidement, n'est-ce pas ?

Ève : Oui, tout à fait. Et je pense que Schema est juste un si joli petit document pour tout décrire. Vous bénéficiez automatiquement de la possibilité de voir tous les champs de ce schéma chaque fois que vous essayez d'y envoyer des requêtes, car vous pouvez envoyer des requêtes d'introspection et il existe toutes sortes d'outils sympas pour cela, comme GraphQL et GraphQL Playground, petits outils que vous pouvez utiliser pour interagir avec les données de l'API.

Eve : Mais aussi, si vous avez déjà joué avec Postman, comme envoyer un ping à une API REST, beaucoup d'entre elles, la documentation n'existe pas vraiment ou elle est difficile à trouver, ou des choses comme ça. GraphQL vous donne vraiment cette belle couche cohérente pour décrire tout ce qui pourrait faire partie de cette API.

Drew : Concrètement, comment ça marche côté serveur ? Je veux dire, je suppose que vous devez exécuter un service GraphQL dans le cadre de votre infrastructure, mais quelle forme cela prend-il ? Est-ce un serveur entier fonctionnant sur son propre port ? Ou est-ce juste comme une bibliothèque que vous intégrez dans votre Express ou Apache existant ou quoi que ce soit avec une route qui résout ce service ? Comment l'implémentez-vous ?

Eve : Ouais, c'est un vrai serveur. Les implémentations GraphQL les plus populaires sont donc les serveurs Node.js. Lorsque GraphQL en tant que spécification a été publié, l'équipe a publié cette implémentation de référence en JavaScript, une sorte de serveur Node qui a servi de guide à tous ces autres qui ont surgi. Mais oui, vous pouvez exécuter ces serveurs sur leurs propres instances. Vous pouvez les mettre sur Lambda. Il y a donc Apollo Server Express, il y a Apollo Server Lambda ; toutes sortes de différents types d'implémentations que vous pouvez utiliser pour exécuter réellement cette chose.

Drew : Vous avez donc mentionné brièvement le concept de schéma dont dispose le serveur.

Ève : Ouais.

Drew : Cela vous donne la possibilité de décrire vos types plus strictement que simplement, vous savez, mapper un nom sur un résolveur. Il y a plus impliqué là-bas, n'est-ce pas?

Ève : Ouais. Il y a un langage complet. J'ai donc fait référence à la spécification et je n'ai pas décrit ce que c'est. GraphQL lui-même est une spécification qui décrit le langage de requête et le langage de définition de schéma. Il a donc sa propre syntaxe. Il a ses propres règles pour définir ces types.

Eve : Lorsque vous utilisez le langage de définition de schéma, vous utilisez essentiellement toutes les fonctionnalités de ce langage pour réfléchir, quels sont les types qui font partie de l'API ? C'est aussi là que vous définissez les requêtes, les mutations, qui sont les verbes, comme les actions, créez une connexion de compte, des choses comme ça. Et même les abonnements GraphQL, qui sont une autre chose intéressante, GraphQL en temps réel que vous pouvez définir directement dans le schéma.

Eve : Alors oui, le schéma est vraiment super important. Et je pense que cela nous donne cette belle application de type dans notre application Stack complète, car dès que vous commencez à vous écarter de ces champs et de ces types, vous commencez à voir des erreurs, ce qui est, dans ce cas, bien, parce que vous 'suis les règles du schéma.

Drew : Y a-t-il un croisement entre cela et TypeScript ? Y a-t-il une sorte de synergie entre les deux là-bas ?

Ève : Absolument. Donc, si vous êtes une personne qui parle beaucoup de GraphQL, parfois les gens vous diront que c'est mauvais, et ils vous parleront publiquement, quand vous pourriez le faire, et vous diront que GraphQL n'est pas bon. Mais souvent, ils sautent sur les trucs sympas que vous obtenez des types. Donc, en ce qui concerne la synergie avec TypeScript, vous pouvez absolument générer automatiquement des types pour votre application frontale en utilisant les types du schéma. C'est donc une énorme victoire car vous pouvez non seulement le générer la première fois, ce qui vous donne une grande interopérabilité avec votre application frontale, mais aussi, à mesure que les choses changent, vous pouvez régénérer les types, puis créer pour refléter ces changements. Alors oui, je pense que ces choses vont très bien ensemble car les types commencent à être une sorte de règle de facto.

Eve : … pour être une sorte de règle de facto en JavaScript, ils vont bien ensemble.

Drew : Cela semble être une sorte de thème récurrent avec la façon dont TypeScript a été conçu… ce n'est pas TypeScript, désolé. GraphQL a été conçu de manière à formaliser l'interaction entre le front-end et le back-end. Et cela vient comme une solution entre le juste crée de la cohérence et une formalisation de ce qui jusqu'à présent a été par ailleurs une expérience assez décousue avec du repos pour beaucoup de gens. Une chose que nous devons toujours garder à l'esprit lors de l'écriture d'applications côté client est que le code est soumis à une inspection et potentiellement à des modifications. Et avoir une API où le client peut simplement demander des données pourrait être dangereux. Maintenant, si vous pouvez spécifier les champs que vous voulez, cela pourrait être dangereux. Où, dans l'ensemble de la pile, vous occuperiez-vous de l'autorisation des utilisateurs et de la vérification de l'application des règles commerciales relatives à vos données ?

Eve : Vous vous occuperiez de tout cela sur le serveur. Donc, cela pourrait se produire de différentes manières. Vous n'êtes pas obligé d'utiliser une stratégie unique, mais vos résolveurs géreront votre autorisation. Cela pourrait donc signifier envelopper une API REST existante, comme un service comme Auth0 ou quelque chose que vous avez construit vous-même. Cela pourrait signifier interagir avec un OAuth, comme GitHub ou Facebook ou Google login, ces types de choses qui impliquent de faire passer des jetons dans les deux sens avec des résolveurs. Mais souvent, cela sera intégré directement dans le schéma. Ainsi, le schéma dira, je ne sais pas, nous allons créer une mutation de connexion. Et puis j'envoie cette mutation avec mes informations d'identification, puis sur le serveur, toutes ces informations d'identification sont vérifiées. Ainsi, le client n'a pas à s'inquiéter autant, peut-être un peu de jetons de passage et des choses comme ça. Mais la plupart de cela est simplement intégré au serveur.

Drew : Donc, essentiellement, cela ne change pas vraiment par rapport à la façon dont nous construisons des points de terminaison de repos pour le moment. Le repos en tant que technologie, eh bien, il ne traite pas vraiment de l'autorisation non plus et nous avons des intergiciels et des choses sur le serveur qui s'en occupent. Et c'est pareil avec GraphQL. Vous n'avez qu'à vous en occuper. Existe-t-il des conventions dans la communauté GraphQL pour faire cela ? Existe-t-il des approches communes ou est-ce un peu partout pour savoir comment les gens choisissent de le mettre en œuvre ?

Eve : C'est honnêtement partout. Je pense que la plupart du temps, vous verrez des gens construire dans le schéma et par là, je veux dire, représenter ces types et les utilisateurs autorisés par rapport aux utilisateurs réguliers construisant ces types dans le schéma lui-même. Mais vous verrez également beaucoup de gens utiliser des solutions tierces. J'ai mentionné Auth0. Beaucoup de gens vont en quelque sorte décharger leur autorisation sur des entreprises qui s'y concentrent davantage, en particulier les petites entreprises, les startups, des choses comme ça. Mais vous verrez également de plus grandes entreprises commencer à créer des solutions pour cela. Donc AWS, Amazon a AppSync, qui est leur version de GraphQL, et ils ont des rôles d'auteur intégrés directement dans AppSync. Et c'est plutôt cool de pouvoir, je ne sais pas, ne pas avoir à se soucier de tout ça ou au moins de fournir une interface pour travailler avec ça. Donc, beaucoup de ces outils écosystémiques ont, je pense que l'autorisation est un sujet si important dans GraphQL. Ils ont vu le besoin, la demande de solutions d'authentification et d'approches standard pour gérer l'authentification sur le graphique.

Drew : Je suppose qu'il n'y a pratiquement pas d'implémentation qui n'ait pas besoin d'une sorte d'autorisation. Alors oui, ça va être une exigence assez courante. Nous construisons de plus en plus d'applications à composants, en particulier lorsque nous utilisons des choses React et View et ainsi de suite. Et le principe du couplage lâche nous laisse avec beaucoup de composants qui ne savent pas nécessairement ce qui s'exécute d'autre sur la page qui les entoure. Y a-t-il un danger à la suite de cela, vous pourriez vous retrouver avec de nombreux composants interrogeant les mêmes données et faisant plusieurs requêtes ? Ou s'agit-il simplement d'un problème d'architecture dans votre application que vous devez résoudre pour cela ? Existe-t-il des solutions éprouvées pour y faire face ?

Eve : Eh bien, je pense que c'est parce que GraphQL pour la plupart, pas 100 % des solutions, mais presque toutes les requêtes GraphQL sont envoyées via HTTP. Donc, si vous voulez savoir où ces multiples requêtes se produisent, c'est probablement un problème assez familier pour les personnes qui utilisent des données de repos pour leurs applications. Il existe donc des outils comme Paulo Client Dev Tools et Urkel Dev Tools pour les développeurs front-end qui disent : « Que se passe-t-il ? Quelles requêtes se trouvent sur cette page ? » Cela vous donne un aperçu très clair de ce qui se passe. Il y a plusieurs écoles de pensée avec ça. Créons-nous une grande et énorme requête pour toutes les données de la page ? Ou créons-nous des requêtes plus petites pour charger des données pour différentes parties de l'application ? Comme vous pouvez l'imaginer, ils ont tous deux leurs propres inconvénients, simplement parce que si vous avez une grosse requête, vous attendez plus de champs.

Eve : Si vous avez des requêtes plus petites, il peut y avoir des collisions entre les données dont vous avez besoin. Mais je pense, et pour ne pas trop prendre la tangente, mais j'y suis déjà. Donc, il y a quelque chose appelé la directive différée qui arrive dans la spécification GraphQL et la directive différée va aider avec le type de contenu de chargement secondaire. Supposons donc que vous ayez du contenu en haut de la page, le contenu super important que vous souhaitez charger en premier. Si vous ajoutez cela à votre requête, puis tous les champs suivants obtiennent la directive différée à ce sujet. C'est juste un petit décorateur que vous ajouteriez à un champ, qui dira ensuite : "D'accord, chargez d'abord les données importantes, puis maintenez et chargez les deuxièmes données ensuite." Et cela vous donne en quelque sorte ceci, c'est l'apparition d'une sorte de flux de données vers votre frontal, de sorte qu'il y a une performance perçue, il y a de l'interactivité. Les gens voient les données tout de suite au lieu d'attendre que chaque champ se charge pour la page, ce qui, oui, cela pourrait être un problème.

Drew : Ouais. Je suppose que cela vous permet d'architecturer des pages où tout ce qui est... nous n'aimons pas trop parler de la fenêtre d'affichage, mais c'est tout ce qui se trouve au-dessus du pli, vous pouvez donner la priorité, charger ce chargement, puis charger secondairement tout ce qui va plus loin vers le bas. Donc, nous avons beaucoup parlé de l'interrogation des données. L'une des tâches principales d'une API consiste à renvoyer des données nouvelles et modifiées au serveur pour les conserver. Vous avez mentionné brièvement les mutations plus tôt. C'est la terminologie utilisée par GraphQL pour réécrire des données sur le serveur ?

Ève : Exactement. Donc, toutes sortes de modifications que nous voulons apporter aux données, tout ce que nous voulons réécrire sur le serveur, ce sont des mutations, et ce sont toutes comme des requêtes, ce sont des opérations nommées qui vivent sur le serveur. Vous pouvez donc penser à toutes les choses que nous voulons que nos utilisateurs puissent faire ? Représenter ceux qui ont des mutations. Et encore une fois sur le serveur, écrivez toutes les fonctions qui font fonctionner ce truc.

Drew : Et est-ce aussi simple que d'interroger des données ? Appeler une mutation est tout aussi simple ?

Ève : Ouais. Cela fait partie du langage de requête. Il semble à peu près identique. La seule différence est, eh bien, je suppose que les requêtes prennent des filtres. Ainsi, les mutations ont pris ce qui ressemblait à des filtres dans la requête elle-même. Mais ceux-ci sont responsables de la modification réelle des données. Un e-mail et un mot de passe peuvent être envoyés avec une mutation, puis le serveur les collecte et les utilise ensuite pour autoriser l'utilisateur.

Drew : Donc, comme avant, vous créez un résolveur sur le backend pour gérer cela et faire tout ce qui doit être fait. Une occurrence courante lors de l'écriture de données est que vous souhaitez valider vos modifications, puis relancer la requête pour obtenir le type d'état actuel de celles-ci. GraphQL a-t-il un bon workflow pour cela ?

Eve : Cela vit en quelque sorte dans la mutation elle-même. Ainsi, souvent lors de la création de votre schéma, vous créerez l'opération de mutation. Je vais m'en tenir à la connexion, prend l'e-mail et le mot de passe. Et la mutation elle-même a renvoyé quelque chose. Ainsi, il pourrait retourner quelque chose d'aussi simple qu'un booléen, cela s'est bien passé, ou cela s'est mal passé, ou il pourrait retourner un type réel. Donc, souvent, vous verrez la mutation comme la mutation de connexion, peut-être qu'elle renvoie un utilisateur. Ainsi, vous obtenez toutes les informations sur l'utilisateur une fois qu'il est connecté. Ou vous pouvez créer un type d'objet personnalisé qui vous donne cet utilisateur plus l'heure à laquelle l'utilisateur s'est connecté, et peut-être un peu plus de métadonnées sur cette transaction dans l'objet de retour . Encore une fois, c'est à vous de concevoir cela, mais ce modèle est vraiment intégré à GraphQL.

Drew : Tout cela semble plutôt bien, mais chaque choix technique implique des compromis. Quels sont les inconvénients de l'utilisation de GraphQL ? Y a-t-il des scénarios où ce serait un très mauvais choix ?

Eve: Je pense que l'endroit où un GraphQL pourrait avoir du mal est de créer une carte un à un de-

Eve : … la lutte consiste à créer une carte individuelle de données tabulaires. Alors disons que vous avez, je ne sais pas, pensez à une table de base de données avec toutes sortes de champs différents et, je ne sais pas, des milliers de champs sur un type spécifique, des choses comme ça, ce type de données peut être bien représenté avec GraphQL, mais parfois lorsque vous exécutez un processus pour générer un schéma sur ces données, vous vous retrouvez avec, dans un schéma, les mêmes problèmes que vous aviez dans la base de données, c'est-à-dire peut-être trop de données qui vont au-delà de ce que le client exige réellement. Donc je pense que ces endroits, ils sont potentiellement des problèmes. J'ai parlé à des gens qui ont généré automatiquement des schémas basés sur leurs données et c'est devenu un schéma d'un million de lignes ou quelque chose comme ça, juste des milliers et des milliers de lignes de code de schéma. Et c'est là que ça devient un peu délicat, comme à quel point est-ce utile en tant que document lisible par l'homme ?

Ève : Ouais. Donc, dans n'importe quelle situation où vous traitez avec un client, c'est un très bon ajustement en ce qui concerne la modélisation de chaque type de données, cela devient un peu délicat si vos sources de données sont trop volumineuses.

Drew : Il semble donc que partout où vous allez soigneusement organiser les réponses dans les champs et le faire davantage à la main, vous pouvez obtenir des résultats vraiment puissants. Mais si vous générez automatiquement des éléments parce que vous venez d'avoir un schéma massif, cela devient peut-être un peu difficile à manier.

Ève : Ouais. Et je pense que les gens m'écoutent et ne sont pas d'accord avec moi à ce sujet parce qu'il existe également de bons outils pour cela. Mais je pense que le genre d'endroit où GraphQL brille vraiment est cette étape d'abstraction de la logique sur le serveur, donnant aux développeurs frontaux la liberté de définir leurs composants ou leurs exigences en matière de données frontales, et de vraiment gérer le schéma en équipe.

Drew : Y a-t-il quelque chose d'intégré dans le langage de requête pour gérer la pagination des résultats, ou est-ce une implémentation personnalisée selon les besoins ?

Ève : Ouais. Pagination, vous construisez d'abord dans le schéma, vous pouvez donc définir la pagination pour cela. Il y a beaucoup de lignes directrices qui ont en quelque sorte émergé dans la communauté. Un bon exemple à regarder si vous êtes nouveau sur GraphQL ou non, je le regarde tout le temps, est l'API GitHub GraphQL. Ils ont essentiellement recréé leur API pour la v4 de leur API publique à l'aide de GraphQL. C'est donc un bon endroit pour voir comment une grande entreprise l'utilise à grande échelle. Beaucoup de gens ont de grosses API en cours d'exécution, mais ils ne les rendent pas publiques à tout le monde. La pagination est donc très bien intégrée à cette API et vous pouvez renvoyer, je ne sais pas, les 50 premiers référentiels que vous avez créés, ou vous pouvez également utiliser la pagination basée sur le curseur pour renvoyer des enregistrements basés sur des idées dans vos données. Donc, la pagination basée sur le curseur et une sorte de pagination positionnelle comme le premier, le dernier enregistrement, c'est généralement ainsi que les gens abordent cela, mais il existe de nombreuses techniques.

Drew : Y a-t-il de gros pièges que nous devrions connaître avant d'utiliser GraphQL ? Disons que je suis sur le point de déployer une nouvelle installation GraphQL pour mon organisation, nous allons construire tous nos nouveaux points de terminaison API en utilisant GraphQL à l'avenir. Que dois-je savoir ? Y a-t-il quelque chose qui se cache dans les buissons ?

Eve : Caché dans les buissons, toujours avec la technologie, n'est-ce pas ? Je pense que l'une des choses qui n'est pas intégrée à GraphQL, mais qui peut être implémentée sans trop de tracas est la sécurité de l'API. Ainsi, par exemple, vous avez mentionné que si j'avais une énorme requête, nous en avons parlé avec autorisation, mais c'est aussi effrayant d'ouvrir une API où quelqu'un pourrait simplement envoyer une énorme requête imbriquée, amis d'amis, amis d'amis, amis d'amis , en bas et en bas de la chaîne. Et puis vous autorisez essentiellement les gens à vous DDoS avec ces énormes requêtes. So there's things that you can set up on the server to limit query depth and query complexity. You can put queries on a safe list. So maybe your front ends, you know what they all are and it's not a public API. So you only want to let certain queries come over the wire to you. So I would say before rolling that out, that is definitely a possible gotcha with the GraphQL.

Drew: You do a lot of instruction and training around GraphQL, and you've co-written the O'Reilly 'animal' book with Alex Banks called Learning GraphQL. But you've got something new that you're launching early in 2021, is that right?

Eve: That's right. So I have been collaborating with egghead.io to create a full stack GraphQL video course. We're going to build an API and front end for a summer camp, so everything is summer camp themed. And yeah, we're just going to get into how to work with Apollo server, Apollo client. We will talk about scaling GraphQL APIs with Apollo Federation. We'll talk about authorization strategies and all sorts of different things. So it's just kind of collecting the things that I've learned from teaching over the past, I don't know, three or four years GraphQL and putting it into one spot.

Drew: So it's a video course that… Is it all just self-directed, you can just work your way through at your own pace?

Eve: Yeah, exactly. So it's a big hefty course so you can work through it at your own pace. Absolument.

Drew: Oh, that sounds really good. And it's graphqlworkshop.com, is that right?

Eve: Graphqlworkshop.com, exactly.

Drew: And I'm looking forward to seeing that released because I think that's something that I might need. So I've been learning all about GraphQL. What have you been learning about lately?

Eve: I've also been looking into Rust lately. So I've been building a lot of Rust Hello Worlds, and figuring out what that is. I don't know if I know what that is yet, but I have been having fun tinkering around with it.

Drew: If you dear listener, would like to hear more from Eve, you can find her on Twitter where she's @eveporcello, and you can find out about her work at moonhighway.com. Her GraphQL workshop, discover your path through the GraphQL wilderness, is coming out early in 2021 and can be found at graphqlworkshop.com. Thanks for joining us today, Eve. Avez-vous des mots d'adieu?

Eve: Parting words, have fun with GraphQL, take the plunge, you'll enjoy it, and thanks so much for having me. Je vous en suis reconnaissant.