Nous vivons à l’âge d’or du cloud computing. Pour les consommateurs, c’est une merveille. Pour les concepteurs, c’est un gâchis complet et absolu.
Pour tous les problèmes liés aux architectures d’applications monolithiques (et il y en a beaucoup), elles sont relativement simples : prenez un serveur d’applications et une base de données et connectez-les à un réseau Internet. interface utilisateur du navigateur. De base! En revanche, les applications d’aujourd’hui dépendent d’une gamme en constante évolution de microservices back-end, d’API propriétaires et tierces, de bases de données, etc., avec une sélection de zones d’atterrissage front-end pour ces données (navigateur Internet, ensemble -boîte supérieure, application mobile, etc.) Même si React et d’autres structures frontales ont en fait rendu l’avancement du front-end beaucoup plus facile, il est devenu plus difficile de connecter la complexité déconcertante du back-end à cette expérience frontale.
Dites une prière de remerciement pour GraphQL.
GraphQL, lancé par Facebook en 2015, fonctionne comme un langage de requête flexible pour les API. Contrairement à SQL, que vous utiliseriez pour interroger une base de données relationnelle, GraphQL permet à un concepteur d’interroger une grande variété de sources de données, en dissociant le client (avancement front-end) du serveur (développement back-end). Aussi cool que soit GraphQL, il est insuffisant sans un supergraphe. Comme l’écrit Matt DeBergalis, CTO et cofondateur d’Apollo GraphQL, le supergraphe est « un réseau unifié d’informations, de microservices et de capacités numériques d’une entreprise qui sert de ‘couche de structure’ pour l’ensemble de l’entreprise. »
PDG et le cofondateur Geoff Schmidt l’a dit dans une interview : « Le supergraphe est une chose vivante et respirante » qui permet aux entreprises d’adapter progressivement leurs installations à des exigences en constante évolution. Oh, et pour connecter ces installations flambant neuves aux installations traditionnelles, car « il n’y a pas de greenfield ».
Supergraphes et idées fausses sur les greenfield
Attendez, quoi ? Sans aucun doute, une startup ou un développeur spécifique n’a pas à gérer l’obligation financière technique de la même manière qu’une entreprise établie et peut se concentrer sur l’avancement de greenfield ? « Obligation financière technique » peut être un terme un peu chargé, mais révélons-le comme l’a fait l’expert de RedMonk, James Governor, dans une interview actuelle :
Que vous soyez un développeur spécifique [et] que vous avez en fait découvert des compétences … et maintenant vous essayez de vous appuyer sur ces compétences pour apprendre un nouveau cadre, ou si vous êtes une petite entreprise et que vous avez développé une infrastructure de données spécifique et que vous essayez de comprendre comment en construire analytiques à ce sujet, ou si vous êtes une grande entreprise qui a du mal à travailler avec des individus et qui souhaite réellement s’appuyer sur les compétences que vous possédez déjà, … la constante est que même si une nouvelle innovation arrive, elle doit exister ensemble avec et s’appuyer sur les compétences existantes et les piles d’innovation existantes.
Schmidt a appris cela à la dure.
Schmidt et DeBergalis ont cofondé Meteor dans le début des années 2010 pour offrir une structure JavaScript de bout en bout — une « plate-forme vraiment magique pour créer de toutes nouvelles applications », a déclaré Schmidt. Les développeurs semblaient d’accord. À son époque, MeteorJS était l’un des emplois les plus populaires sur GitHub et a amené un quartier sain à plus de 100 rencontres régulières. Le problème, comme le raconte Schmidt, était que Meteor était parti d’une mauvaise hypothèse. « Lorsque nous avons essayé d’introduire Meteor dans l’entreprise, Meteor a été développé pour le développement de greenfield [] nous avons découvert que rien n’est greenfield dans l’entreprise. »
Il poursuit : « Nous résidons dans un monde où n’importe quelle application que vous ‘d wish to develop utilise de nombreux services et sources de données différents provenant de nombreux endroits. C’est ce qui rend l’application précieuse. Elle synthétise toutes les choses dans le cloud en une expérience que vous pouvez avoir. Encore une fois, que vous soyez un concepteur individuel, une petite startup ou un léviathan du Fortune 500, vous dépendez d’une large sélection de services en dehors de votre pare-feu, pour ainsi dire, et tous ces services compliquent le développement.
En fait, ce n’est pas plutôt. Comme le souligne Schmidt, l’idée clé que lui et DeBergalis avaient était que l’entreprise avait besoin d’une bien meilleure méthode pour lier des frameworks frontaux significativement efficaces (tels que MeteorJS ou React) à des services back-end de plus en plus puissants mais complexes. « Voyant à quel point il était difficile d’intégrer Meteor dans l’entreprise, nous avons commencé à développer le système d’information Meteor 2 », se souvient-il, « qui s’appelait Apollo et était basé sur toutes les leçons tirées de [l’assistance] aux entreprises… faire le L’innovation Meteor fonctionne dans des environnements commerciaux hétérogènes complexes. » Ils avaient besoin d’un langage de questions pour leur supergraphe Apollo et ont sélectionné GraphQL.
Tout cela est fantastique. Pourquoi vous devriez-vous vous en soucier ?
Supercharger GraphQL
Si vous développez des applications, que ce soit en tant que développeur individuel ou pour une grande entreprise, l’avancement n’est pas ça devient plus facile. La méthode à suivre se dirige clairement vers une complexité accrue grâce aux microservices. Les développeurs acceptent cette complexité car il y a beaucoup à tirer de la méthode, comme une dextérité accrue. Ils veulent cet avenir.
Atteindre cet avenir peut être difficile.
Même GraphQL, malgré tout son potentiel, a été utilisé par de nombreux développeurs pour assembler des services individuels. Ce qu’Apollo tente d’atterrir est un graphique de cartes, pour ainsi dire. L’utilisation de graphiques pour rassembler une infrastructure considérablement atomisée est excellente, mais l’ajout d’un méta-graphe, ou d’un supergraphe, a la possibilité d’améliorer considérablement la vie des développeurs. Pourquoi? C’est la méthode la plus simple pour utiliser des sources de données disparates sans avoir « à créer ces connexions profondes, directes et vulnérables à une base de données Oracle spécifique ou à un microservice spécifique, ou à développer un tout nouveau point de terminaison REST que quelqu’un doit préserver », déclare Schmidt.
Notamment, la méthode du supergraphe peut être de nature plutôt fragmentaire. Walmart, par exemple, devait déterminer comment intégrer les ordinateurs centraux qui gèrent leurs magasins avec les microservices qui gèrent leur exécution en ligne. Les clients ne connaissaient pas ce problème d’installations et n’avaient peut-être même pas vu que Walmart avait un site pour les achats en ligne et un pour le retrait en magasin. Mais ils ont absolument reconnu que les avis disponibles en ligne n’apparaissaient pas pour le ramassage en magasin. Et ils auraient été ennuyés par les diverses brochures d’articles hébergées avec chaque système. Walmart n’a pas réussi à fermer ses ordinateurs centraux, il a donc utilisé le supergraphe Apollo pour combiner essentiellement les deux systèmes.
La technique du supergraphe « n’a pas besoin d’un changement en cascade qui arrête le monde », déclare Schmidt . Il aide les organisations à relier de manière transparente leurs systèmes traditionnels à leurs systèmes plus récents. Dans le cas de Walmart, cela signifiait qu’un développeur frontal pouvait dire : « Montrez-moi les évaluations d’un article », et il découvrirait ces évaluations où qu’il se trouve, y compris sur son ordinateur central. Si plus tard, ils refactorisaient ce mainframe en une architecture basée sur des microservices, rien n’aurait besoin de changer sur le front-end.
Coopter le cloud
Une chose intéressante qui ressort de tout ceci : Les nuages n’améliorent pas toujours les choses. AWS, par exemple, propose AppSync, un excellent moyen pour un développeur d’applications d’extraire des informations de DynamoDB et de les afficher dans leur application mobile. Que faire si vous souhaitez extraire des informations de DynamoDB, ajouter certaines fonctions sans serveur Azure, appeler des informations dans votre ordinateur central et accéder aux informations d’un service Google Cloud ou 2 ? Tout l’engagement de GraphQL et d’un supergraphe Apollo-esque est d’apprivoiser les environnements hétérogènes, et cette nouvelle hétérogénéité comprend divers nuages. Il sera difficile pour un cloud spécifique de fournir le routage central nécessaire.
Nous avions besoin d’une couche déclarative abstraite, ou d’un supergraphe, pour aider les développeurs à apprivoiser le gâchis qu’est l’informatique d’entreprise. Pendant un certain temps, nous nous sommes trompés en croyant que le cloud résoudrait le problème. Ce n’était pas le cas. Il vient d’étendre et de complexifier davantage l’informatique d’entreprise. Idées et prières qu’un supergraphe peut aider. C’est tout simplement possible.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
