Qu'estce que GraphQL?

Dans cet épisode, nous parlons de GraphQL. Qu'est-ce que c'est et comment résout certains problèmes d'API courants? J'ai parlé avec l'expert Eve Porcello pour le savoir.

Afficher les notes

Mise à jour hebdomadaire

Transcription

Drew McLellan: Elle est ingénieur logiciel, instructeur, auteur et co-fondateur de la société de formation et de développement de programmes, Moon Highway. Sa carrière a commencé à rédiger des spécifications techniques et à créer des conceptions UX pour des projets Web. Depuis qu'elle a lancé 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 aussi une conférence fréquente conférencier et a fait des présentations lors de 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 amis fracassants, veuillez souhaiter la bienvenue à Eve Porcello.

Drew: Salut Eve, comment vas-tu?

Eve Porcello: Je suis en train de casser.

Drew: Comme je l'ai mentionné ici , vous êtes vraiment un éducateur dans des domaines 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 auront entendu parler de GraphQL dans une certaine mesure, mais pourraient ne pas être complètement sûrs de ce que c'est, ou de ce qu'il fait, et en particulier, du type de problème qu'il résout dans la pile Web.

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

Eve: Ouais. Le genre GraphQL s'adapte entre le frontal et le backend. Il vit en quelque sorte entre les deux et offre de nombreux avantages aux développeurs front-end et back-end.

Eve: Si vous êtes un développeur front-end, vous pouvez définir tous vos frontaux Exigences en matière de données. 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, il est vraiment propre, car nous pouvons collecter beaucoup de données à partir de beaucoup de différentes sources. 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 où se trouvent toutes nos données. C'est donc très 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 frontal et votre back-end et fournit une sorte d'API, est-ce exact?

Eve: Ouais, c'est exactement ça. Exactement.

Drew: Je pense qu'au cours de la dernière décennie, l'étalon-or des 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 construisez un point de terminaison d'API REST et vous l'interrogez. Alors, où ce modèle tombe-t-il? Et quand pourrions-nous avoir besoin de GraphQL pour venir résoudre cela pour nous?

Eve: Eh bien, le problème avec lequel GraphQL nous aide vraiment, le genre de problème en or, la solution en or, je suppose, que GraphQL fournit est-ce qu'avec REST, nous récupérons trop de données. Donc, si j'ai des utilisateurs slash 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 sélectifs sur les données que nous voulons. Donc, si je n'ai besoin que de quatre champs d'un objet qui en a une centaine, je vais être en mesure de vraiment localiser ces champs et de ne pas avoir à charger des données ou à charger toutes ces données, je devrais dire, dans votre appareil, car c'est beaucoup de travail supplémentaire, 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 voulez retour, ou vous pouvez augmenter ce qui revient avec des choses supplémentaires. Et donc je suppose que cela identifie ce problème, n'est-ce pas? Cela signifie que vous ne voulez pas toujours récupérer les mêmes données à chaque fois. Alors est-ce que GraphQL formalise cette approche consistant à permettre au front-end de spécifier ce que le backend va retourner, en termes de données?

Eve: Ouais, exactement. Donc votre requête devient alors comment vous demandez, comment vous filtrez, comment vous saisissez pour n'importe quelle sorte d'information de n'importe où.

Eve: Je pense aussi qu'il est important de noter que nous n'avons pas à démolir tout nos API REST afin de travailler avec GraphQL vraiment avec succès. La plupart des implémentations de GraphQL les plus réussies que j'ai vues sur le marché sont des enveloppes 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, des exemples, certaines des données proviennent du repos, certaines proviennent d'une base de données.

Drew: Je suppose que le scénario familier est, 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 cueillez cela sur chaque page et remplissez les données, mais ensuite vous trouvez ailleurs dans votre application, 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 comme leur adresse postale. Donc, cela est également renvoyé par ce point de terminaison.

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

Drew: Et cela a été sélectionné sur chaque page juste 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.

Eve: Exactement. Et oui, je pense que toute l'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 système de type sympa pour l'API.

Eve: Donc, n'importe qui dans l'équipe, les managers, les développeurs front-end, les développeurs back-end, n'importe qui qui s'occupe vraiment de données peut se rassemblent, fusionnent autour des données que nous voulons réellement diffuser sur cette API, et alors tout le monde sait quelle est cette source de vérité, ils peuvent aller créer leurs propres parties de l'application sur cette base.

Eve: Il y a donc des choses délicates de gestion de schéma qui viennent aussi avec cela. Mais en ce qui concerne le passage des microservices aux monolithes, nous le faisons en quelque sorte, mais en tirant toujours tous les avantages que nous aimons des microservices.

Drew: Et est-ce que je comprends bien que la manière typique de la configuration d'un système GraphQL est que vous auriez essentiellement une route, qui est le point final vers lequel vous envoyez toutes vos requêtes afin que vous n'ayez pas à le faire … Souvent, l'une des choses les plus difficiles est de savoir quoi nommer, et quoi le chemin doit être celui de cette requête particulière. Ce sont des utilisateurs et des produits qui reviennent, devrait-il s'agir de slash utilisateurs quelque chose, ou de slash produit quelque chose?

Drew: Avec GraphQL, vous n'avez qu'un seul point de terminaison sur lequel vous lancez vos requêtes et vous obtenez une réponse appropriée. [19659010] Eve: Exactement. Ouais. C’est un seul point de terminaison. Je suppose que vous avez toujours des problèmes de dénomination parce que vous nommez tout dans le schéma. Mais en ce qui concerne, je me sens comme beaucoup d’entreprises qui ont fait de gros paris sur les microservices, tout le monde aime, quels points de terminaison avons-nous? Où sont-elles? Comment sont-ils documentés? Et avec GraphQL, nous avons un endroit, un type de dictionnaire pour rechercher tout ce que nous voulons savoir sur le fonctionnement de l'API.

Drew: Donc, je suis très familier avec d'autres langages de requête, comme SQL est un exemple évident de langage de requête que de nombreux développeurs Web connaissent. Et les requêtes en cela prennent la forme presque comme une commande. C’est une chaîne de texte, n’est-ce pas. Sélectionnez ceci à partir de là, où, peu importe. Quel format prennent les requêtes 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 sur le serveur. Donc, le serveur GraphQL, l'API GraphQL est vraiment responsable 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é champ . Nous ajoutons donc simplement des champs pour tout ce que nous voulons récupérer. Bien entendu, nous pouvons également mettre des filtres sur ces requêtes. Mais je pense que la provenance de ces informations est un peu moins directe. Une grande partie des fonctionnalités est intégrée au serveur.

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

Eve: Oui, c’est absolument 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 ainsi que cela fonctionne, nous connectons différents types sur les champs. Je suppose donc que nous recyclerons 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ée que nous voulons que la requête aille, nous pouvons.

Drew: Cela signifie-t-il aussi récupérer les données pour une vue typique dans votre application Web qui pourrait avoir toutes sortes de choses en cours, que vous pouvez simplement faire une requête au backend et obtenir tout cela en une seule fois sans avoir à faire différentes requêtes à différents points de terminaison, car ce n'est qu'une chose?

Eve: Ouais. C’est exactement l’objectif, une seule requête, définir tous les champs souhaités, puis les renvoyer en une seule réponse.

Drew: Et les requêtes sont basées sur Jason?

Eve: … Transformez-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 c'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 il semble que les requêtes concernent presque des objets nus, comme un client ou un produit. Existe-t-il un moyen de spécifier des requêtes plus complexes dans lesquelles la logique métier est contrôlée au niveau du backend? Disons que je veux obtenir une liste d'équipes pour un utilisateur, mais uniquement lorsque cet utilisateur est l'administrateur d'une équipe et où 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 être réalisé avec GraphQL?

Eve: Absolument. C'est donc ce qui est vraiment intéressant et puissant à propos de 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'avez pas du tout à l'utiliser. Donc Python, Go, C ++, tout ce que vous voulez utiliser, vous pouvez créer 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 sur cela. Est-ce vrai?

Eve: C'est exactement ça. Je pense donc que c'est vraiment bien pour les gens du front-end, car ils peuvent commencer à prototyper sur cette base. Et puis l'équipe backend pourrait aller 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 il est, et "Quels sont les champs de ce type?" Et tout peut être géré par n'importe quel endroit de la pile GraphQL fonctionne. Et c’est pourquoi ce n’est pas vraiment une technologie frontale ou back-end. C'est vraiment un peu les deux, et ni l'un ni l'autre.

Drew: On dirait que c'est une sorte de formalisation de l'API et de la relation entre le front-end et le backend, donc tout le monde a une interface prévisible qui est normalisée.

Eve: Exactement.

Drew: Ce que je suppose dans les organisations où le front-end et le backend 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, il peut nécessiter des données différentes, sans avoir besoin de quelqu'un qui travaille sur le backend pour apporter les modifications qui correspondent à cela. Vous disposez toujours de cette API personnalisable à l'infini sans nécessiter de travail pour la modifier si vous avez besoin de nouvelles données.

Eve: Ouais, tout à fait raison.

Drew: Il en va de même pour le Serveur GraphQL responsable du formatage de la réponse, ou avez-vous besoin de le faire dans votre logique côté serveur?

Eve: Le serveur GraphQL définit donc deux choses. Il définit le schéma lui-même qui vit sur le serveur, puis il définit les fonctions du résolveur. 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'emballe avec GraphQL, le résolveur va extraire de cette API, transformer les données comme il se doit, puis les renvoyer au client dans cette fonction. Vous pouvez également utiliser toutes sortes de 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ésif pour placer toutes ces données et pour concevoir toute la logique autour de: «D'où viennent ces données? Comment voulons-nous le transformer? »

Drew: Le client dit:« Je veux un utilisateur complexe », le serveur reçoit cela dans une requête et pourrait dire:« D'accord, je vais chercher le résolveur d’utilisateurs complexes. »

Eve: Mm-hmm (affirmatif).

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

Eve: Ouais, exactement.

Drew: Donc, cela pourrait être appeler d'autres API, cela pourrait interroger une base de données, cela pourrait chercher des trucs dans la 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 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 vraiment être une victoire, car il peut être très difficile de maintenir la cohérence sur une grande échelle des points de terminaison de l'API, en particulier dans les grandes équipes. Différentes personnes travaillent sur des choses différentes. À moins d'avoir une gouvernance assez stricte en place, cela peut devenir très complexe très rapidement, n'est-ce pas?

Eve: Oui, absolument. Et je pense que Schema est juste un si joli petit document pour tout décrire. Vous obtenez automatiquement l'avantage de pouvoir 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 intéressants 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 eux, la documentation ne le fait pas. t existent vraiment ou c'est difficile à trouver, ou des choses comme ça. GraphQL vous donne vraiment cette belle couche cohésive pour décrire tout ce qui pourrait faire partie de cette API.

Drew: Concrètement, comment les choses fonctionnent-elles 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? S'agit-il d'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émenter?

Eve: Oui, c'est un vrai serveur. Les serveurs Node.js sont donc les implémentations GraphQL les plus populaires. 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 lignes directrices à tous ces autres qui sont apparus. 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, Apollo Server Lambda; toutes sortes de différents types d'implémentations que vous pouvez utiliser pour exécuter cette chose.

Drew: Donc vous avez mentionné brièvement avant le concept de schéma que le serveur a.

Eve: Ouais.

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

Eve: Ouais. Il y a une langue complète. J'ai donc fait référence à la spécification et je n'ai pas décrit de quoi il s'agissait. 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 également là que vous définissez les requêtes, les mutations, qui sont les verbes, comme les actions, créer la connexion au 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 ici même 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 toute notre application Stack, 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, car vous suivez les règles du schéma.

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

Eve: Absolument. Donc, si vous êtes une personne qui parle beaucoup de GraphQL, parfois les gens vous diront que c'est mauvais, et ils viendront vers vous 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 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 un peu la règle de facto en JavaScript, ils s'emboîtent bien.

Drew : Cela semble être une sorte de thème en cours 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 à ce qu'il y ait beaucoup à 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 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 quels champs vous voulez, cela pourrait peut-être être dangereux. Où, dans le genre de la pile entière, vous occuperiez-vous de l'autorisation des utilisateurs et vous assurer que les règles commerciales autour de vos données sont appliquées?

Eve: Vous vous occuperiez de tout cela sur le serveur. Donc, cela peut se produire de différentes manières. Vous n’avez pas à utiliser de stratégie ponctuelle, mais vos résolveurs se chargeront de votre autorisation. Cela pourrait donc signifier envelopper une API REST existante, comme un service comme Auth0 ou quelque chose que vous avez créé vous-même. Cela pourrait signifier interagir avec un OAuth, comme la connexion GitHub ou Facebook ou Google, ces types de choses qui impliquent une sorte de transfert de jetons avec les résolveurs. Mais souvent, cela sera intégré directement dans le schéma. Donc, 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 sont vérifiées. Ainsi, le client n'a pas à s'inquiéter autant, peut-être un peu de passer des jetons et des choses comme ça. Mais la plupart de ces éléments sont simplement intégrés 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. Reste en tant que technologie, eh bien, elle ne traite pas vraiment non plus d’autorisation et nous avons des intergiciels et des éléments sur le serveur qui les traitent. Et c’est pareil avec GraphQL. Vous vous en occupez simplement. Existe-t-il des conventions dans la communauté GraphQL pour faire cela? Existe-t-il des approches communes ou est-ce partout pour la façon dont les gens choisissent de les mettre en œuvre?

Eve: Honnêtement, c'est 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 qui construisent 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 transférer leur autorisation à 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 saveur 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 à s’inquiéter de tout cela ou au moins fournir une interface pour travailler avec ça. Donc, beaucoup de ces outils écosystémiques ont, je pense que l'autorisation est un si gros sujet dans GraphQL. Ils ont vu une sorte de 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 guère d'implémentation qui ne nécessite pas une sorte de autorisation. Alors oui, ce sera une exigence assez courante. Nous construisons tous de plus en plus d'applications en composants, en particulier lorsque nous utilisons des éléments React et View, etc. Et le principe du couplage lâche nous laisse avec de nombreux composants qui ne savent pas nécessairement ce qui se passe sur la page qui les entoure. Y a-t-il un danger à cause de cela, vous pourriez vous retrouver avec de nombreux composants interrogeant les mêmes données et effectuant plusieurs demandes? Ou est-ce juste un problème d'architecture dans votre application que vous devez résoudre pour cela? Existe-t-il des solutions bien rodées pour gérer cela?

Eve: Eh bien, je pense 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ù se produisent ces demandes multiples, c'est probablement un problème assez familier aux personnes qui utilisent des données de repos pour leurs applications. Il existe donc des outils tels que Paulo Client Dev Tools et Urkel Dev Tools pour les développeurs frontaux qui se disent: «Que se passe-t-il? Quelles requêtes se trouvent sur cette page? » Cela vous donne des informations très claires sur 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 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 vous avez besoin. Mais je pense, et ne pas aller trop loin sur une tangente, mais j’y suis déjà. Il y a donc quelque chose appelé la directive différée qui vient à la spécification GraphQL et la directive différée va aider avec le type de chargement secondaire du contenu. Supposons que vous ayez du contenu en haut de la page, le contenu très important que vous souhaitez charger en premier. Si vous ajoutez cela à votre requête et que 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 alors: "Très bien, chargez d'abord les données importantes, puis attendez et chargez ensuite les secondes." Et cela vous donne en quelque sorte cela, c'est l'apparence d'une sorte de streaming de données vers votre front-end, de sorte qu'il y ait des performances perçues, il y a de l'interactivité. Les gens voient les données tout de suite plutôt que d'attendre que chaque champ soit chargé pour la page, ce qui peut être un problème.

Drew: Ouais. Je suppose que cela vous permet de créer 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 prioriser, avoir cette charge et ensuite charger dans tout ce qui est plus loin vers le bas. Nous avons donc beaucoup parlé d’interroger 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 évoqué brièvement les mutations plus tôt. C’est la terminologie que GraphQL utilise pour réécrire des données sur le serveur?

Eve: 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 réfléchir à toutes les choses que nous voulons que nos utilisateurs puissent faire? Représentez ceux qui ont des mutations. Et puis à nouveau sur le serveur, écrivez toutes les fonctions qui font que tout cela fonctionne.

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

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

Drew: Donc, comme avant, vous créez un résolveur sur le backend pour faire face à 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 effectuer une nouvelle requête pour en obtenir le type d'état actuel. GraphQL a-t-il un bon workflow pour cela?

Eve: Il vit en quelque sorte dans la mutation elle-même. Ainsi, lors de la création de votre schéma, vous créez souvent l’opération de mutation. Je vais m'en tenir à la connexion, saisir l'e-mail et le mot de passe. Et la mutation elle-même a renvoyé quelque chose. Donc, il pourrait renvoyer quelque chose d'aussi simple qu'un booléen, cela s'est bien passé, ou cela s'est mal passé, ou il peut renvoyer 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 un peu à vous de concevoir cela, mais ce modèle est vraiment intégré à GraphQL.

Drew: Tout cela sonne 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 le lieu où un GraphQL pourrait avoir du mal est de créer une carte un-à-un de-

Eve: ]… La lutte consiste à créer une carte univoque 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, il vous reste, dans un schéma, les mêmes problèmes que vous aviez dans la base de données, qui sont peut-être trop de données qui vont au-delà de ce que le client exige réellement. Je pense donc que ces endroits sont potentiellement des problèmes. J'ai parlé à des personnes qui ont des schémas générés automatiquement en fonction de leurs données et c'est devenu un schéma d'un million de lignes ou quelque chose du genre, juste des milliers et des milliers de lignes de code de schéma. Et c’est là que cela devient un peu compliqué, comme à quel point est-ce utile en tant que document lisible par l’homme?

Eve: Ouais. Donc, quelle que soit la situation dans laquelle vous avez affaire à un client, c'est une solution vraiment intéressante pour modéliser tous les types de données, cela devient un peu délicat si vos sources de données sont trop volumineuses.

Drew: Donc, il semble que partout où vous allez soigneusement organiser les réponses dans les domaines et le faire plus à la main, vous pouvez obtenir des résultats vraiment puissants. Mais si vous générez automatiquement des trucs parce que vous avez juste un énorme schéma, alors peut-être que cela devient un peu difficile à manier.

Eve: Ouais. Et je pense que les gens m'écoutent et ne sont pas d'accord avec moi à ce sujet, car il existe également de bons outils pour cela. Mais je pense que l'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 besoins en données frontaux, et gérant vraiment le schéma en équipe.

Drew: Y a-t-il quelque chose de construit 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?

Eve: Ouais. Pagination, vous intégreriez d'abord le schéma, vous pouvez donc définir la pagination pour cela. Il y a beaucoup de directives qui ont émergé dans la communauté. L'API GitHub GraphQL est un bon exemple à regarder si vous êtes nouveau ou non dans GraphQL, je regarde cela tout le temps. Ils ont essentiellement recréé leur API pour la version 4 de leur API publique à l'aide de GraphQL. C'est donc un bon endroit pour voir comment une grande entreprise utilise cela à grande échelle. Beaucoup de gens ont de grandes API en cours d'exécution, mais elles ne les rendent pas publiques à tout le monde. La pagination est donc vraiment 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 le type de pagination positionnelle comme le premier, le dernier enregistrement, c'est généralement la façon dont les gens abordent cela, mais il existe de nombreuses techniques.

Drew: Y a-t-il des choses importantes que nous devrions savoir pour utiliser GraphQL? Si je suis sur le point de déployer une nouvelle installation GraphQL pour mon organisation, nous allons créer tous nos nouveaux points de terminaison d'API à l'aide de GraphQL à l'avenir. Que dois-je savoir? Y a-t-il quelque chose qui se cache dans les buissons?

Eve: On se cache dans les buissons, toujours avec la technologie, non? Je pense que l’une des choses qui n’est pas intégrée à GraphQL, mais qui peut être mise en œuvre sans trop de tracas, est la sécurité des API. Donc, 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 , le long de la chaîne. Et puis vous autorisez essentiellement les gens à vous DDoS avec ces énormes requêtes. Il existe donc des éléments que vous pouvez configurer sur le serveur pour limiter la profondeur et la complexité des requêtes. Vous pouvez placer les requêtes sur une liste sûre. Alors peut-être que vos frontaux, vous savez ce qu'ils sont tous et ce n'est pas une API publique. Vous ne souhaitez donc que certaines requêtes vous parviennent. Donc, je dirais qu'avant de déployer cela, c'est certainement possible que vous ayez obtenu le GraphQL.

Drew: Vous faites beaucoup d'instruction et d'entraînement autour de GraphQL, et vous avez co-écrit le O'Reilly livre «animal» avec Alex Banks appelé Learning GraphQL. Mais vous avez quelque chose de nouveau que vous lancez au début de 2021, n'est-ce pas?

Eve: C'est vrai. J'ai donc collaboré avec egghead.io pour créer un cours vidéo GraphQL full stack. Nous allons créer une API et une interface pour un camp d'été, donc tout est sur le thème d'un camp d'été. Et oui, nous allons simplement aborder la façon de travailler avec le serveur Apollo, le client Apollo. Nous parlerons de la mise à l'échelle des API GraphQL avec Apollo Federation. Nous parlerons des stratégies d’autorisation et de toutes sortes de choses. Il s'agit donc simplement de rassembler les choses que j'ai apprises en enseignant dans le passé, je ne sais pas, trois ou quatre ans de GraphQL et de les mettre en un seul endroit.

Drew: C'est donc un cours vidéo que… Est-ce que tout est auto-dirigé, vous pouvez simplement vous frayer un chemin à votre rythme?

Eve: Ouais, exactement. Il s’agit donc d’un parcours assez lourd pour que vous puissiez le parcourir à votre rythme. Absolument.

Drew: Oh, ça sonne vraiment bien. Et c'est graphqlworkshop.com, n'est-ce pas?

Eve: Graphqlworkshop.com, exactement.

Drew: Et j'ai hâte de le voir publié parce que je pense que c'est quelque chose que je pourrais avoir besoin. J'ai donc tout appris sur GraphQL. Qu'avez-vous appris ces derniers temps?

Eve: J'ai également étudié Rust ces derniers temps. J'ai donc construit beaucoup de Rust Hello Worlds et j'ai découvert ce que c'était. Je ne sais pas si je sais encore ce que c'est, mais je me suis amusé à le bricoler.

Drew: Si vous, cher auditeur, souhaitez en savoir plus sur Eve, vous pouvez la trouver sur Twitter où elle est @eveporcello, et vous pouvez en savoir plus sur son travail sur moonhighway.com. Son atelier GraphQL, découvrez votre chemin à travers la nature sauvage de GraphQL, sortira début 2021 et se trouve sur graphqlworkshop.com. Merci de vous joindre à nous aujourd'hui, Eve. Avez-vous des mots d'adieu?

Eve: Mots d'adieu, amusez-vous avec GraphQL, franchissez le pas, vous allez en profiter, et merci beaucoup de m'avoir invité. Je l'apprécie.

(il)