Matt Debergalis sur GraphQL et la modélisation des données dans l'entreprise


Dans ce podcast, Matt Debergalis, fondateur et directeur technique d'Apollo, a rencontré Daniel Bryant, co-animateur du podcast InfoQ. Les sujets abordés comprenaient: les motivations de GraphQL, la plate-forme Apollo Data Graph, la modélisation des données dans un contexte d'entreprise et la façon dont l'adoption incrémentielle de GraphQL peut aider à découpler l'évolution des systèmes frontend et backend.

Points clés à retenir

  • Les défis de la définition de modèles de données conviviaux, de la création d'API backend maintenables et composables et du déplacement des données du cloud vers une application client contribuent à rendre le développement de logiciels modernes difficile et long.
  • GraphQL est un langage de requête et de manipulation de données open-source pour les API, et un runtime pour répondre aux requêtes avec des données existantes. GraphQL permet aux développeurs d'applications de décrire les données dont ils ont besoin et de les afficher dans les écrans qu'ils construisent pour leurs utilisateurs.
  • La plate-forme Apollo Data Graph est une couche middleware qui permet de découpler les API métier principales des modèles de consommation côté client. Apollo peut implémenter des préoccupations transversales, telles que la gestion des transactions, ce qui atténue la nécessité de l'implémenter dans des applications côté client (potentiellement multiples).
  • Apollo permet de construire un «graphique de données»: une série de graphiques qui sont composés à partir des données d'une organisation pour une utilisation dans les applications côté client. Un graphique de données est particulièrement utile dans les grandes entreprises, car c'est ici que de nombreux systèmes (générateurs de revenus) avec des API existantes doivent être combinés pour répondre aux nouvelles exigences commerciales.
  • GraphQL peut être adopté de manière incrémentale. Pour commencer l'adoption, il suffit de créer le graphique le plus simple possible qui correspond aux besoins de la première application, du premier écran ou du premier composant requis pour passer au graphique. Laissez ensuite ce graphique évoluer.

Abonnez-vous sur:





Afficher les notes

  • 00:21 Bonjour et bienvenue sur le podcast InfoQ. Je suis Daniel Bryant, responsable des nouvelles chez InfoQ et architecte produit chez Datawire. Et j'ai récemment eu le plaisir de rencontrer Matt DeBergalis, fondateur et CTO chez Apollo. Dans mon travail de jour, je tombe de plus en plus sur GraphQL en tant qu'API et langage de requête utilisé à la limite des systèmes face au client. Souvent en remplacement ou à côté des API traditionnelles de type REST. Apollo est l'un des serveurs GraphQL bien connus. Et donc quand l'occasion de parler à Matt a été présentée, j'ai sauté sur l'occasion. J'ai eu un certain nombre de questions concernant l'utilisation de GraphQL, comment la modélisation des données doit être abordée, en particulier dans un contexte d'entreprise, où il y a généralement beaucoup de systèmes et d'API existants. Et je tenais à comprendre comment la technologie GraphQL s'intègre avec d'autres composants de communication, comme une passerelle API et un maillage de service.
  • 01:02 Bonjour Matt, et bienvenue sur le podcast InfoQ.
  • 01:04 Merci de m'avoir invité. C'est bon d'être ici.
  • 01:06 Pouvez-vous vous présenter brièvement et partager un peu votre parcours professionnel?
  • 01:09 Bien sûr. Je m'appelle Matt DeBergalis. Je suis co-fondateur et CTO d'Apollo GraphQL. Et nous allons beaucoup parler de GraphQL aujourd'hui. Avant cela, j'ai passé beaucoup de temps dans le monde open source. J'étais l'un des développeurs du projet NetBSD. Pendant un certain temps, j'ai travaillé avec l'appliance réseau sur les systèmes de fichiers et le stockage de fichiers en réseau à mes débuts dans ma carrière. Et pendant un certain temps, j'ai construit une plate-forme logicielle en politique appelée ActBlue, nous sommes une plate-forme de collecte de fonds pour les candidats en Amérique à gauche. Je pense que le thème que vous entendrez beaucoup pendant que nous parlons est que j'ai juste une vraie passion pour l'organisation, pour les mouvements et la communauté open source pour moi est spéciale.
  • 01:49 InfoQ couvre de nombreux sujets, et nous avons sans aucun doute des auditeurs qui sont des experts GraphQL, mais nous avons aussi des gens qui sont quelque peu nouveaux dans cet espace. Personnellement, mes antécédents, beaucoup de SOAP, beaucoup de REST, je suis sûr que beaucoup de leçons viennent de cette direction. Mais avant de nous plonger dans une partie de cela, pourriez-vous déballer un peu l'espace problème pour nous? Et c'est peut-être une sorte d'ascenseur pour GraphQL ou les problèmes que vous verriez lors de l'utilisation de GraphQL?
  • 02:10 Oui, bien sûr. Apollo et GraphQL sont tous sur un défi de base de la façon dont obtenir des données à vos utilisateurs? Et si vous pensez à ce que c'est que de construire une application moderne aujourd'hui, ce qui est intéressant, c'est la richesse des données d'une grande expérience numérique moderne. Si vous pensez à un écran typique dans une application de commerce électronique, ce ne sont pas seulement des produits. Ce sont des recommandations, des personnalisations, toutes sortes de données qui doivent être réunies juste pour créer une excellente expérience utilisateur. Et il s'avère que le déplacement des données du cloud vers le client est ce qui rend le développement logiciel aussi difficile et chronophage. Et à la fin de la journée, GraphQL par rapport aux technologies API héritées comme REST ou SOAP, est un moyen considérablement plus efficace pour permettre aux développeurs d'applications de décrire les données dont ils ont besoin et d'apporter ces données dans les écrans qu'ils construisent pour leurs utilisateurs.
  • 03:04 Pourriez-vous expliquer quel genre de tendances a conduit à l'émergence de GraphQL, s'il vous plaît?
  • 03:08 Je pense que le contexte ici est il y a cinq, six, sept ans, nous avons vu la montée de ces expériences d'application client vraiment riches. JavaScript est devenu le langage du web, Meteor était un projet de framework JavaScript que nous avons commencé. Facebook est bien sûr l'un des nombreux exemples d'une application Web complexe. Et dans l'ancien temps, un site Web était des formulaires et vous verriez un écran et cliquez sur un bouton et obtenez un nouvel écran. Et ce n'était pas si grave. Mais lorsque nous créons des applications, que ce soit sur le Web ou que ce soit une application mobile native, nous avons maintenant besoin de données riches provenant du cloud pour ces applications. Et la perspicacité que Facebook avait avec GraphQL, que Netflix avait avec Falcor, que nous avions avec Meteor et bien d'autres dans l'industrie, il se trouve que chaque fois que vous voulez créer un nouvel écran dans votre application, vous devez vous rendre écrire une nouvelle API sur le backend pour répondre aux besoins de cet écran.
  • 04:06 Et tout est chaudière, c'est toute la plomberie, rien n'est réutilisable, en particulier, et vous finissez par emmêler étroitement votre backend et votre application lorsque vous faites cela. Ce qui signifie que tout va bien au début, mais plus votre application est grande ou plus l'expérience utilisateur est complexe, plus vous découvrez que vous passez tout votre temps à fouiller des données et à écrire du code pour le faire au lieu de créer ce que l'utilisateur souhaite. Le concept de GraphQL est vraiment élégant à mon avis. Au lieu d'écrire du code, nous écrivons des requêtes. Et le développeur d'application, le développeur frontal, les ingénieurs produits dans un environnement GraphQL, ils décrivent en fait les données dont l'écran a besoin sous la forme d'une requête GraphQL. C'est un peu comme écrire une requête SQL. Et c'est le système, l'infrastructure, qui prend cette requête et assemble les éléments de données dont chaque écran a besoin en fonction de ce que dit cette requête et l'envoie au client.
  • 05:01 Et donc ce que nous nous retrouvons, c'est lorsque vous adoptez GraphQL, et supposez que vous utilisez React sur votre frontal, la construction d'une application est aussi simple que la conception de certains composants d'interface utilisateur, l'écriture d'une requête pour chacun de ces composants qui décrit les données dont vous avez besoin pour remplir le composant avec quelque chose, puis les assembler à l'écran de différentes manières. Et vous avez évité tout besoin de cette couche intermédiaire d'API, des backends pour les frontaux, quelle que soit l'architecture que vous ayez conçue, en faveur de quelque chose qui est basé sur une architecture déclarative où vous écrivez simplement des requêtes. Et donc le gros avantage que ces développeurs voient est des projets qui prenaient des semaines, des heures. C'est vraiment ce genre de changement de mentalité. Et c'est vraiment, je pense que le cœur de ce qui a fait que GraphQL s'est propagé si rapidement.
  • 05:48 Mes antécédents sont très bien dans l'espace REST, je pense que beaucoup de nos auditeurs le sont aussi, mais nous avons toujours des gens qui s'y heurtent jour après jour, en particulier sur ce type de systèmes hérités ou faisant de l'argent comme nous aimons les appeler.
  • 05:57 Absolument.
  • 05:59 Quel est le genre de pitch là-bas, c'est presque comme le cliché disant GraphQL contre REST contre SOAP. Il y a probablement une combinaison d'entre eux potentiellement en cours d'exécution dans de nombreux systèmes. Comment se comparent-ils tous?
  • 06:10 Eh bien, ce que nous faisons chez Apollo, c'est que nous permettons de construire ce que nous appelons un graphique de données. Et un graphique de données est particulièrement utile dans une grande entreprise, car c'est dans les organisations où vous avez des systèmes existants avec des API existantes, que ce soit REST ou SOAP ou dans un cadre plus moderne, vous pouvez voir GRPC ou Thrift. Chacun de ces systèmes possède une logique métier. Ce sont souvent des décennies d'investissement qui ont été investies dans ce système. Et c'est vraiment la valeur que l'organisation a créée. Toutes les données et la signification de ces données qui vivent dans ces systèmes sont là où se trouve la valeur. L'idée d'un graphique de données est de prendre chacune de ces choses et de les combiner ensemble dans une couche que vous pouvez interroger avec GraphQL. Nous ne remplaçons aucune de ces API.
  • 06:57 Ce que nous aimons faire avec Apollo, c'est les améliorer et les rendre plus accessibles avec moins de friction aux équipes de développement d'applications qui tentent de créer des expériences utilisateur en plus de cela. Et donc une façon d'y penser est, supposons que vous vouliez faire une nouvelle expérience utilisateur. Sans GraphQL, vous devez écrire un tas de code. Certains vont parler à une API SOAP. Certains vont parler à une API REST. Et vous avez juste ce genre d'effort continu. Et personne n'aime écrire ce code d'ailleurs. C'est le genre de choses que vous écrivez et que vous oubliez. C'est difficile à tester. C'est cassant et fragile.
  • 07:31 Avec GraphQL, vous écrivez un schéma, nous l'appelons. C'est une couche qui décrit toutes ces données. Certaines de ces données peuvent provenir d'un point de terminaison REST. Certaines de ces données peuvent provenir d'un point de terminaison SOAP, mais pour l'auteur de l'application, vous avez maintenant un moyen de décrire ce dont vous avez besoin en termes de GraphQL juste en plus. Et la couche Apollo se traduit. Lorsqu'une requête provient de l'application, le travail d'Apollo consiste essentiellement à créer un plan de requête et à récupérer certaines de ces données à partir de vos points de terminaison REST, certaines de ces données à partir de vos points de terminaison Thrift, etc., etc.
  • 08:04 Pendant que vous parliez, je repensais à mes jours de design classique, cela me rappelait presque une sorte de façade ou un modèle d'adaptateur.
  • 08:10 Oui, c'est vrai. C'est une couche middleware. C'est une façon de découpler les API principales, qui reflètent vraiment les systèmes sur lesquels elles sont construites à partir des applications et des expériences utilisateur. Et donc avoir cette couche entre les deux est un contrat. Vous pouvez le considérer comme un menu de toutes les données disponibles dans l'organisation. Et cela signifie que vos systèmes sous-jacents n'ont plus à contraindre le type d'expériences utilisateur que vous souhaitez créer. Vous pouvez mélanger et faire correspondre le type de données dont vous disposez d'une manière qui n'était pas prévue lors de la première construction de ces systèmes. Vous pouvez créer une expérience utilisateur moderne qui colle les données de plusieurs systèmes. Il vous permet de penser séparément à l'expérience utilisateur, puis aux bases de données sous-jacentes et à l'architecture technique de vos services backend.
  • 08:58 Est-ce que GraphQL doit vraiment être utilisé à la limite du système? Par exemple, je vois beaucoup de gens construire des systèmes et des microservices et utiliser des API comme REST pour la communication de service à service. Pourraient-ils également utiliser GraphQL ici?
  • 09:09 Il y a des équipes qui explorent cela. Je pense qu'à son crédit, l'une des raisons pour lesquelles GraphQL s'est propagé si rapidement est qu'il s'agit d'une spécification simple et bien écrite. Et cela signifie qu'il existe de nombreuses façons différentes d'appliquer ces idées à différentes parties de la pile. La pièce sur laquelle nous nous concentrons à Apollo est ce que vous avez décrit. C'est le bord, c'est cette couche qui assemble toutes les données en un seul schéma pour l'organisation. Mais il existe des moyens d'utiliser GraphQL, par exemple, pour interroger une base de données qui parle GraphQL de manière native. Ou des façons d'utiliser GraphQL pour la communication de service à service. Et donc je pense que nous allons voir un écosystème entier évoluer autour de différents cas d'utilisation au fil du temps, tout comme nous le faisons avec toute bonne technologie flexible.
  • 09:50 J'entends beaucoup parler de requêtes avec GraphQL. Est-il possible de faire aussi le genre de modèles de type CRUD classiques que vous pouvez faire des mises à jour et ainsi de suite?
  • 09:58 Absolument. Ouais. GraphQL est malheureusement nommé d'une manière qui implique qu'il s'agit d'interroger des données, mais GraphQL est vraiment une façon de décrire les services et les capacités d'une organisation. Et ceux-ci incluent, nous les appelons des mutations dans GraphQL. Cela inclut des moyens pour qu'un client mette à jour un élément de données ou demande qu'une action soit entreprise. Et l'aperçu clé avec GraphQL, et je pense que nous en parlerons probablement un peu, est que GraphQL est vraiment à son meilleur quand il décrit les besoins de l'application. Lorsque les données sont modélisées ou que les mutations sont modélisées d'une manière qui reflète les types d'écrans que vous créez ou les types d'actions qu'un utilisateur souhaite entreprendre. Et donc cela vous donne beaucoup plus d'une vision sémantique ou descriptive du monde. Lorsque vous parlez de CRUD, parfois avec une API REST, l'un des défis que nous rencontrons est du point de vue du propriétaire du service, une petite et simple API CRUD REST est élégante car elle a un travail et correspond étroitement aux capacités de la système en dessous.
  • 11:07 Mais du point de vue de l'auteur de l'application, c'est souvent assez loin de ce que vous essayez vraiment de faire. Et vous finissez par écrire beaucoup de code dans votre client qui effectue trois ou quatre appels REST en séquence, car vous devez mettre à jour ceci et ensuite aller le chercher. Et puis peut-être changer cette chose ici. Avec GraphQL, nous avons une architecture qui vous encourage vraiment à décrire ce que vous essayez de faire, que ce soit une requête ou une mutation que vous appelez et que vous laissez le système mapper cela sur toutes les différentes pièces qui doivent se produire sous.
  • 11:35 Très bien. Existe-t-il également un concept de transactions dans GraphQL? Parce que vous avez parlé d'unir les choses. J'ai été là. Je l'ai fait. J'ai dû séquencer les appels REST, vérifier que les choses à faire, avaient été faites correctement, puis revenir en arrière. Si ce n'est pas possible, le motif de la saga était assez populaire pour cette raison. Comment ça marche dans GraphQL?
  • 11:51 Oui, l'un des avantages que nous voyons avec les équipes qui adoptent un graphique de données est que le code qui devait auparavant vivre dans chaque application peut se déplacer vers cette couche centrale de graphique de données. Une transaction est un excellent exemple. Vous trouvez souvent que l'application iOS a un code qui essaie d'appeler trois points de terminaison en séquence. L'application Android a le même code, sauf qu'il est un peu différent et qu'il a été écrit par une équipe différente et que votre application Web a le même code. Et quand on y pense, c'est pourquoi le développement logiciel est si lent. C'est parce que nous demandons aux ingénieurs produits de créer dans un certain sens, de petits gestionnaires de transactions, soit dans leur application, soit ils écrivent un petit backend pour que le front-end fasse cela ou autre chose. Avec GraphQL, vous pouvez centraliser cela. Cela fait partie du graphique. Et donc pour un consommateur du graphique, quelqu'un qui écrit une application, il vous suffit d'écrire votre requête GraphQL. Vous appelez simplement votre mutation GraphQL. Et toute la logique de ces comportements est désormais centralisée en un seul endroit.
  • 12:47 Qu'est-ce exactement qu'Apollo?
  • 12:48 Oui, Apollo est l'implémentation standard de GraphQL dans l'industrie. Cela inclut les clients GraphQL pour toutes les principales plates-formes, JavaScript, Android, iOS. Il comprend un serveur GraphQL intégré à TypeScript, et il comprend un ensemble de services, un registre pour les schémas GraphQL et des outils et des workflows qui vous permettent de collaborer autour d'une couche GraphQL en équipe. Et Apollo est vraiment construit avec ce cas d'utilisation particulier à l'esprit, ce graphique de données que vous allez superposer entre vos API existantes et vos clients. Il peut être utilisé de différentes manières, mais nous l'avons vraiment optimisé pour les besoins des équipes de produits qui souhaitent accélérer la façon dont ils créent des applications en passant de ces API point à point à un graphique de données.
  • 13:33 Sympa. Agréable. Qu'en est-il, donc les systèmes de type ici, parce que honnêtement, vous avez potentiellement des systèmes de type sur le front-end, vous avez TypeScript, ce genre de chose. Tapez des systèmes sur le backend, je suis développeur Java par métier. Comment cela correspond-il à ces types frontaux et aux types backend?
  • 13:46 Pour un développeur qui adopte GraphQL, il est absolument magique d'avoir une forte frappe de bout en bout sur l'ensemble du système. Et la façon dont nous le faisons est le schéma GraphQL lui-même est tapé. Et cela nous permet, par exemple, si vous êtes un développeur iOS, vous pouvez générer automatiquement des classes Swift qui correspondent aux requêtes que vous écrivez. Si vous êtes un développeur TypeScript, vous pouvez générer automatiquement des classes TypeScript qui correspondent aux requêtes que vous écrivez. Et tout cela se fait automatiquement par l'outillage Apollo. L'expérience d'un développeur est vraiment remarquable et c'est pourquoi c'est tellement plus efficace que les alternatives. Vous vous asseyez à l'intérieur du code VS, disons. Vous travaillez sur votre composant React, vous tapez une requête GraphQL, juste à l'intérieur de ce composant. Le code S est assez intelligent pour savoir comment taper vérifier votre requête, comment valider que vous vérifiez tous les cas de bord, vous n'avez pas vérifié si une pièce était nulle ou autre. Et tout cela est simplement validé en continu dans votre base de code client pendant que vous construisez le système.
  • 14:49 Et de même, cela fonctionne dans toute l'équipe. Si un membre de l'organisation met à jour le schéma GraphQL, nous pouvons réellement effectuer une validation statique dans le cadre de votre intégration continue pour toute l'organisation de ce changement par rapport aux différents clients que vous avez écrits et comment ils utilisent le graphique aujourd'hui . Et vous avez donc une comptabilité dans GraphQL de la façon exacte dont chaque client utilise chaque élément de vos données, ce catalogue précis. Et cela nous permet de faire toutes sortes de validations et de vérifications de temps de construction et, pour l'entreprise, d'appliquer les politiques sur la façon dont le graphique est utilisé et comment cela change au fil du temps. Cela n'est vraiment pas possible avec les API traditionnelles où toute la signification de l'API est enfouie dans le code et ne peut pas être raisonnée de la même manière.
  • 15:35 Oui, c'est très puissant car j'ai utilisé la société appelée Pact pour tester les contrats entre les API REST. Et c'est très fastidieux de le mettre en place et de le faire fonctionner dans un système CI, par exemple. Je suppose que d'après votre argumentaire, il est très facile de faire ce genre de changements de schéma et d'en vérifier l'impact?
  • 15:51 Ouais, c'est juste une requête. Et donc, si vous souhaitez mettre à jour, par exemple le schéma de votre application, que vous avez quelque chose qui est une énumération et que vous souhaitez modifier l'ensemble de valeurs qui se trouvent dans l'énumération, Apollo gère un catalogue complet de toutes les différentes applications qui l'utilisent. enum particulier et comment ils l'ont utilisé. Et nous pouvons valider que cette modification est compatible avec l'utilisation ou vous donner une comptabilité de ces trois applications dans ce module particulier ou des trois cas d'utilisation qui ne sont pas compatibles avec cela. Et en plus de cela, vous pouvez créer des workflows vraiment intéressants. GraphQL a l'idée de la dépréciation du champ. Ce n'est pas seulement un jour de drapeau où un jour vous changez votre API de manière incompatible. L'une des choses que nous encourageons vraiment les équipes à faire, c'est qu'elles adoptent le graphique de données et adoptent une approche très agile du graphique.
  • 16:42 Et c'est un grand changement de mentalité pour un développeur lorsque vous pouvez itérer sur votre API à la vitesse que vous itérez sur votre produit. Et c'est vraiment ce que GraphQL vous permet de faire. Vous pouvez marquer une partie de votre schéma comme obsolète et cela signale à votre équipe de développement qu'il y a une fenêtre de temps. C'est peut-être un mois, peut-être six mois, peut-être deux ans. Quand à la fin de cette fenêtre, nous allons retirer ce morceau de l'API et vous pouvez maintenant gérer une transition vraiment gracieuse. Tout d'un coup, vous n'êtes pas bloqué sur la version deux de l'API pendant trois ans. Et vous savez à quel point il est difficile de versionner les API. C'est une force incroyable du graphique de données car maintenant nous agissons comme des ingénieurs produits et nous pouvons expédier le graphique 10 fois par jour avec un changement ici, un changement là-bas. Et c'est une transition en douceur pour les équipes qui s'appuient sur elle.
  • 17:28 Comment les équipes gèrent-elles la modélisation des données? Vous avez mentionné adopter une approche agile. J'ai toujours trouvé que des choses comme d'autres outils, Cassandra, Mongo, faisaient votre choix. La modélisation des données était souvent la partie la plus difficile du problème. Avez-vous des conseils sur la façon dont les gens devraient créer ce genre de modèles graphiques?
  • 17:43 Ce que nous avons appris, c'est que la meilleure façon d'utiliser un graphique de données est de le concevoir pour répondre aux besoins des clients. Voilà la règle d'or. Et cela signifie que vous devez adopter une approche agile, car vos clients vont changer. Souvent, lorsque nous travaillons avec une plus grande entreprise, ils arrivent à la technologie des graphiques de données en pensant que la première étape est un exercice de modélisation des données. Ils le regardent du point de vue de, eh bien, voici tout le genre d'idées de base que j'ai, laissez-moi les mettre dans un graphique et ensuite je peux l'interroger de n'importe quelle façon. Il s'avère que c'est à l'envers. Le génie de GraphQL est qu'il est accessible du côté client de l'équation. Et plutôt que de modéliser vos données d'une manière parfaite qui ne changera jamais, nous vous recommandons de créer simplement le premier graphique le plus simple possible qui correspond aux besoins de la première application.
  • 18:37 Le premier écran, le premier composant sur lequel vous souhaitez passer au graphique. Ensuite, laissez ce graphique évoluer et itérer à mesure que votre interface utilisateur change, à mesure que vous ajoutez d'autres applications au graphique, à mesure que vous trouvez de nouveaux cas d'utilisation de manière organique dans toute l'organisation. C'est un état d'esprit vraiment différent d'une API traditionnelle ou d'un exercice de modélisation de données. Mais les équipes qui ont trouvé cela, Expedia est un excellent exemple d'une entreprise qui a adopté le graphique de données dès le début et qui s'est répandu de manière organique dans de plus en plus de l'organisation. Ce qu'ils ont toujours constaté, c'est que c'est à son meilleur lorsque vous autorisez un processus agile et que vous habilitez chaque équipe de l'organisation à adapter le graphique au fur et à mesure pour répondre aux besoins de ce qu'ils expédient réellement.
  • 19:25 Et c'est la même leçon que je pense que nous avons apprise dans l'industrie du logiciel, restez proche de vos utilisateurs. Suivez ce que vos utilisateurs vous disent, ce dont vos utilisateurs ont besoin et cela vous donnera le meilleur résultat. Et nous avons vraiment essayé de construire Apollo et les outils pour permettre ce genre de mentalité et les types de workflows qui vous permettent de suivre cette voie.
  • 19:44 Oui, très bien. J'aime d'abord l'idée de client. Je l'ai appris à la dure, je pense dans ma carrière en génie logiciel. Pour en revenir au framework Apollo lui-même, est-ce open source, Matt?
  • 19:52 Oui. Apollo est sous licence MIT. C'est le serveur Apollo, je l'ai mentionné. Ce sont les clients de toutes les différentes bibliothèques. Et puis il y a pas mal d'outils qui vont avec. Nous avons parlé de la cogénération, par exemple. Construire vos classes Swift et autres. Et ensuite, cela est associé aux services cloud Apollo, qui sont le registre de votre schéma et les systèmes de suivi de la façon dont cela change, la validation, les types de workflows dont nous avons parlé.
  • 20:19 Je voudrais plonger dans certains des problèmes d'infrastructure et des points d'intégration avec la plateforme là-bas. Et ma première question est, comment le serveur GraphQL est-il lié à quelque chose comme une passerelle API plus traditionnelle?
  • 20:28 Eh bien, je pense qu'ils sont complémentaires et que nous avons beaucoup réfléchi est qu'Apollo est le plus populaire dans les entreprises où vous avez toutes ces différentes couches de la pile. Et donc, à mon avis, Apollo est une autre couche de la pile. C'est un autre élément de votre appareil de développement logiciel que vous allez utiliser. Et Apollo s'est vraiment concentré sur le schéma, ce menu de données et comment il est défini et comment cette définition change au fil du temps et comment votre équipe collabore autour de cela. Et cela suggère donc beaucoup de points d'intégration. Pratiquement tous ceux qui utilisent Apollo en ont câblé des parties jusqu'à leur système de surveillance des performances des applications. De nombreux clients ont une passerelle API située au bord du réseau, qui gère les types de problèmes d'authentification, les DDoS, etc., qui complimentent bien Apollo. Beaucoup de gens cherchent à utiliser un maillage de service sous Apollo car Apollo vous permet de découpler le développement de votre API et permet à plusieurs équipes de collaborer sur une seule API.
  • 21:35 Et cela encourage vraiment une architecture assez fine. Et je pense que l'un des grands avantages de l'adoption d'un graphique de données est qu'il récompense les investissements que vous avez faits dans les microservices et dans les types d'infrastructure cloud native qui permettent de faire évoluer les microservices sur plusieurs équipes, plusieurs environnements, etc. en avant. En fait, il y a une analogie que j'aime utiliser, ce que des technologies comme Kubernetes ou Envoy ont fait pour les développeurs d'infrastructure, c'est qu'elles ont permis à plusieurs équipes de collaborer sur un même environnement. Vous pouvez prendre deux conteneurs Docker qui ont été écrits par des équipes complètement distinctes en utilisant des technologies complètement distinctes et ils coexistent bien ensemble. Et ils sont de bons citoyens dans un cadre plus large d'une infrastructure cloud. Et cela a changé la façon dont le développement des services se fait dans l'entreprise moderne. Apollo fait de même pour votre API.
  • 22:28 Dans le passé, il n'était jamais possible pour plusieurs équipes de collaborer sur une seule API. Vous n'avez aucune idée des conséquences d'une modification d'une API si c'est quelque chose dont dépend un autre système. Mais avec Apollo, vous pouvez le faire. Et l'une des pièces les plus populaires que nous avons construites dans Apollo est une technologie appelée Fédération, qui vous permet de composer plusieurs graphiques de données en un seul. Lorsque nous parlons d'une grande organisation utilisant un graphique de données pour leurs applications, nous ne voulons pas dire que c'est un graphique monolithique dans lequel tout le monde insère du code.
  • 23:00 Ce que nous voulons vraiment dire, c'est que deux, trois, 10 équipes différentes possèdent chacune une partie distincte du graphique de données. Ils peuvent mettre en œuvre cette pièce dans la technologie qu'ils souhaitent. Certaines équipes peuvent être Java. Certaines équipes peuvent utiliser JavaScript. Certaines équipes peuvent utiliser Go ou Rust, mais elles sont toutes composées ensemble dans un seul graphique unifié de sorte que lorsque j'écris une application dans cette organisation, je peux taper une requête sans se soucier des équipes responsables des éléments de cette requête. Je vois juste un menu unifié de toutes les données dont je dispose. Et je peux décrire ce que je veux pour mon application de la manière la plus naturelle possible. Voilà le vrai prix.
  • 23:38 Quelques choses sont apparues, vous en avez parlé. Je travaille beaucoup avec Envoy, par exemple, et il y a beaucoup de discussions sur les procurations sensibles à la couche sept, et nous examinons les métadonnées ATB pour prendre, par exemple, des décisions de sécurité. Comment cela fonctionne-t-il par rapport à GraphQL? Parce que vous avez un autre point de terminaison unique et que les requêtes arrivent, pouvez-vous consulter les métadonnées GraphQL, pour ainsi dire?
  • 23:56 Oui, je pense que c'est un sujet vraiment passionnant. Il y a tellement d'informations sémantiques riches dans la requête GraphQL dont nous pouvons tirer parti. Et je pense qu'il y aura beaucoup d'occasions d'intégrer cela à différentes parties d'un maillage de service ou à différentes politiques, par exemple, qui peuvent vivre à l'intérieur du maillage de service. Et avec le temps, je pense que vous allez l'appeler couche sept, peut-être que GraphQL est presque comme une couche huit. Là où nous ajoutons un autre niveau d'informations sémantiques qui nous permet de raisonner, ai-je envoyé des informations personnelles à quelqu'un qui n'est pas censé les avoir? Ou puis-je avoir une comptabilité d'où le sous-ensemble de mon graphique que je considère comme des informations client? Puis-je avoir une comptabilité de l'endroit où cela est allé? Ou puis-je établir une politique indiquant où cela devrait aller ou ne pas aller?
  • 24:44 Je pense que certaines de ces questions peuvent être résolues avec Apollo lui-même. Certains peuvent être résolus par des intégrations avec un maillage de service ou une passerelle API. Je soupçonne que beaucoup de choses vont être construites au sommet du graphique sous forme de logiciels supplémentaires ou de composants techniques supplémentaires qui se connectent à cette image, car cela nous ouvre tellement de portes pour pouvoir répondre aux questions et appliquer une politique qui a été difficile dans le passé.
  • 25:07 Quelle est l'utilisation de la technologie dans l'industrie? Avez-vous remarqué des tendances intéressantes?
  • 25:11 Eh bien, nous pourrions probablement parler pendant des heures. Je pense que le point clé est la rapidité avec laquelle GraphQL se développe et se propage, en particulier dans l'entreprise. J'ai une vue d'ensemble de cela en partie parce que le client Apollo et le serveur Apollo sont des fondations open source populaires pour les équipes qui construisent un graphique de données. Il est intéressant de voir à quelle vitesse cela s'est propagé dans les grandes entreprises. Et je pense que la raison en est que ce sont les entreprises qui ont les plus grands besoins en matière de vitesse de développement de logiciels. Ce sont les entreprises avec les API les plus traditionnelles qui doivent être réunies en une seule.
  • 25:45 Et en 2020 avec COVID, avec l'accélération de toutes ces tendances vers les premières expériences numériques, chaque entreprise est désormais une entreprise de logiciels. Chaque entreprise doit avoir une expérience numérique de classe mondiale pour ses utilisateurs. Et si vous ne pouvez pas connecter vos données à vos utilisateurs, vos concurrents vont vous innover. Et les événements de ces derniers mois ont vraiment mis un point aussi fin que possible sur ce défi. Nous assistons à une adoption extraordinaire. Et bon nombre des questions que vous avez posées, je pense, sont vraiment pertinentes parce que ce sont les types de questions que chaque entreprise nous pose quand elles s'engagent dans la construction d'un graphique. Et c'est un bon guide, je pense, pour savoir où la technologie ira au cours des deux prochaines années.
  • 26:27 Je suis sûr que vous êtes tombé sur le graphique de diffusion de l'innovation. Nous en parlons beaucoup à InfoQ en termes de localisation de notre technologie sur le graphique. Et bien sûr, différentes sociétés ont des vues différentes sur le graphique. Dans l'équipe d'architecture d'InfoQ, nous l'avons dit, GraphQL a franchi le gouffre. C'est une sorte de passage à une sorte de majorité précoce. Notre équipe de développement Web a déclaré que cela allait plus loin. Où mettriez-vous le sujet GraphQL sur la diffusion de l'innovation?
  • 26:51 Je suis d'accord avec ça. J'ai prononcé un discours lors de notre événement au sommet GraphQL l'année dernière, en novembre dernier. Et mon message était que GraphQL est maintenant mature et accessible. Et le public de cette conférence particulière est constitué de grandes entreprises qui empruntent très rapidement le chemin du graphique de données. Et il y a de très grands noms. Nous travaillons avec le New York Times, par exemple, si vous lisez le New York Times sur votre téléphone ou sur le Web, c'est un graphique de données. C'est de là que viennent toutes ces données. J'ai mentionné Expedia plus tôt. Il y a pas mal d'entreprises qui ont découvert à quel point elles peuvent aller plus vite en adoptant ce type de technologie et en s'orientant dans cette direction.
  • 27:33 PayPal, for example, in the eCommerce space has made an extraordinary investment in the data graph. Airbnb is using the graph. All of the companies that I really think about as being thoughtful about their digital strategy have started to not just chart a course, but to race down this path. Again, because at the end of the day, it saves time and money. It elevates the data that you already have and it creates a better experience for your users and your customers. And I think it's extraordinary just to watch how fast this is happening, but I would agree that it's crossed the chasm. And I think 2020 is really the year that we're going to see every major company building a data graph strategy in some form and charting a course for how they're going to transition to that world.
  • 28:17 Very nice. One question just popped to my mind as you're talking there, Matt. Is there any story around async because I bumped into async API early on in the year where it's kind of like, swagger for events and messages and so forth. Is there any connection around that sort of dealing with asynchronous messages, asynchronous events?
  • 28:34 That's an interesting question. GraphQL has long had, for example, the concept of a subscription. You can type a GraphQL query and your client will be updated automatically as that data changes. And that's been a really exciting area. I'm always hearing interest in subscriptions when I talk to organizations. I just think if you think about a really great user experience, that often leads to push to real time to a dynamic interface. And so there's a lot there. There's also, I think this broader trend of organizations moving to an event based view of the world. And I really see that as complimentary to the graph in so many ways. It's about having a more semantic understanding of your data and of the events that happen. It's about having principled infrastructure for managing that instead of handwritten code that your team is spending its time on instead of building value.
  • 29:31 I'm really excited about how these two move forward together over the coming year. We make a lot of investments in this and our company is rooted in, we mentioned before the Meteor project, and one of Meteor's big innovations was this idea of a end to end real time development stack. And so it's something that's near and dear to our heart.
  • 29:50 It's somewhat of a holy grail, I think, isn't it? Something I've struggled with. I did a lot of front end back end dev, full stack and getting that complete workflow that I could understand and use effectively was very hard.
  • 30:00 It's magical. It's absolutely magical. When a developer can sit down, type a really straightforward query. You do not have to be a computer science genius, to do this. And your screen updates with exactly the data you asked for. You wrote three lines of code to do this. And as the data changes, your screen updates and all the different parts of the screen update the right way so that your application doesn't feel broken or confusing. And it's almost too jarring sometimes where you go in thinking that's something that's going to take a team of developers three months to put together. And when they're done in 15 minutes, it's almost puzzlingly straightforward. Tu sais ce que je veux dire? And so I just think you're right. It is. And it's here now. And as that message spreads and as larger companies who maybe feel left out of some of the modern trends in app dev are able to reach those heights and build that kind of user experience, I think it's just a remarkable opportunity for every company of every size to be able to really do well by their users and build something delightful.
  • 31:02 Final question, Matt, is, what does the future hold for Apollo? What's on the roadmap? What can people look forward to seeing over the next year?
  • 31:08 Well, my vision is a data graph for every company and for every team. And I've talked about why that's so valuable. You can really think of our plans and our roadmap is what can we do to most effectively enable that and accelerate that? For us, a lot of this is about movement building, about open source, about education. We're going to be making many investments in that. A lot of this is about developing deeper integrations and partnerships with the other parts of the stack that we talked about earlier. And a lot of this for me is just fundamentally looking at this question from the perspective of the largest companies with the most complex environments. And what I hear over and again is, at the end of the day, this is a people technology. This is a collaboration technology. We can talk about how you write a query or how a parser might work and all the improvements we can make in this stack.
  • 31:59 But this stuff is really about how do teams work together more effectively? And most of our roadmap, most of our aspirations are really all around whether it's tools or guidance or structure or clarity, anything we can do to help multiple teams collaborate effectively, decouple their work and add all that up to a great user centric point of view. A great customer experience is really the focus of us. And I think you'll find this is an exciting opportunity I think for the industry as a whole to elevate our work as a whole and to do it together.
  • 32:38 Very nice, very nice indeed. If people want to follow you online, Matt, what's the best way? Twitter? LinkedIn?
  • 32:42 Yeah. All the usual places, Apollo GraphQL on Twitter is a great place and you can follow us on LinkedIn. We're on Twitch now. We have a regular live stream of development ideas, and we do a lot of our new announcements on our blog and then do a live stream with that. I've started doing AMAs on Zoom about different kinds of technology. Wherever you want to find us, we'll be there for you. And of course you can go to www.apollographql.com for pointers to all of that.
  • 33:10 Super. Thanks for your time today, Matt.
  • 33:12 I appreciate it. Enjoyed it a lot. Thanks.

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via
SoundCloud,
Apple Podcasts,
Spotify,
Couvert
and the Google Podcast.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts



Source link

Pourquoi confectionner une boutique sur le web ?

Il n’a jamais été aussi facile de jeter un website commerce électronique de nos jours, il suffit de voir le nombre de plateformes web commerce électronique en France pour s’en livrer compte. En effet, 204 000 sites actifs en 2016. En 10 ans, le nombre de sites a été fois 9. Avec l’évolution des technologies, médias à grand coup d’histoire de succès story, (si dans l’hypothèse ou nous-mêmes vous assure, je me nomme aussi tombé a l’intérieur du panneau) le e-commerce a longuement été vu comme un eldorado. Du coup, une concurrence accrue a vu le jour dans thématiques.