Nous vivons à l’âge d’or du cloud computing. Pour les consommateurs, c’est une merveille. Pour les développeurs, c’est un gâchis complet et absolu.
Pour tous les problèmes avec les architectures d’applications monolithiques (et il y en a beaucoup), ils sont assez simples : prenez un serveur d’applications et une base de données et connectez-les à un navigateur interface utilisateur. Simple! 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 un assortiment de zones d’atterrissage front-end pour ces données (navigateur Internet, décodeur box, application mobile, etc.) Même si React et d’autres frameworks front-end ont rendu l’avancement du front-end beaucoup plus facile, il est en fait devenu plus difficile de lier la complexité souvent écrasante du back-end à cette expérience front-end.
Dites une prière de remerciement pour GraphQL.
GraphQL, publié par Facebook en 2015, fonctionne comme un langage d’interrogation polyvalent pour les API. Contrairement à SQL, que vous utiliseriez pour interroger une base de données relationnelle, GraphQL permet à un développeur d’interroger une grande variété de sources d’informations, en dissociant le client (avancement front-end) du serveur (développement back-end). Aussi cool que soit GraphQL, il est incomplet sans supergraphe. Comme le compose le CTO et cofondateur d’Apollo GraphQL, Matt DeBergalis, le supergraphe est « un réseau unifié des données, des microservices et des capacités numériques d’une entreprise qui fonctionne comme la ‘couche de structure’ pour l’ensemble de l’entreprise. »
PDG et le cofondateur Geoff Schmidt l’a exprimé ainsi dans une interview : « Le supergraphe est une chose vivante et respirante » qui permet aux entreprises d’adapter progressivement leur infrastructure à des exigences en constante évolution. Oh, et pour lier cette nouvelle infrastructure à l’infrastructure héritée puisque « il n’y a pas de greenfield ».
Supergraphes et mythes de greenfield
Attendez, quoi ? Sans aucun doute, une start-up ou un concepteur privé n’a pas besoin de gérer la dette technique de la même manière qu’une entreprise reconnue et peut se concentrer sur l’avancement de greenfield ? « Obligation financière technique » peut être un terme un peu bourré, mais révélons-le comme l’expert de RedMonk, James Guv, l’a fait dans une récente interview :
Que vous soyez un designer privé [et] vous avez en fait découvert des capacités … et maintenant vous essayez de vous appuyer sur cette compétence pour découvrir une nouvelle structure, ou si vous êtes une petite entreprise et que vous avez en fait construit des installations de données particulières et que vous essayez de comprendre comment pour construire des analyses dessus, ou si vous êtes une grande entreprise qui a du mal à embaucher des gens et qui veut réellement s’appuyer sur les compétences que vous possédez actuellement, … la constante est que même si une toute nouvelle innovation est disponible dans, il doit exister côte à côte avec et s’appuyer sur les compétences existantes et les piles technologiques existantes.
Schmidt a appris cela de manière difficile.
Schmidt et DeBergalis ont cofondé Meteor au début des années 2010 pour fournir une structure JavaScript de bout en bout — un « vraiment plate-forme magique pour créer de toutes nouvelles applications », a déclaré Schmidt. Les développeurs semblaient d’accord. À son époque, MeteorJS figurait parmi les emplois les plus populaires sur GitHub et attirait une communauté saine à plus de 100 rencontres de routine. Le problème, comme le raconte Schmidt, était que Meteor partait d’une mauvaise hypothèse. « Lorsque nous avons essayé d’introduire Meteor dans l’entreprise, Meteor a été conçu pour le développement de greenfield [] nous avons découvert qu’absolument rien n’est greenfield dans l’entreprise. »
Il poursuit : « Nous vivons dans un monde où n’importe quelle application vous voudriez construire s’appuie sur un grand nombre de services et de sources de données différents provenant de nombreux endroits. C’est ce qui rend l’application précieuse. Elle synthétise tout ce qui se trouve dans le cloud en une expérience que vous pouvez avoir. Encore une fois, que vous soyez un designer privé, une petite start-up 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 rendent l’avancement complexe.
En fait, ce n’est pas tout à fait ça. Comme le souligne Schmidt, l’idée clé que lui et DeBergalis avaient était que l’entreprise avait besoin d’une meilleure méthode pour connecter des structures frontales progressivement efficaces (telles que MeteorJS ou React) à des services principaux efficaces mais complexes. « Voyant à quel point il était difficile de faire entrer Meteor dans l’entreprise, nous avons commencé à développer le système de données Meteor 2 », se souvient-il, « qui s’appelait Apollo et était basé sur toutes les leçons tirées de [l’aide] aux entreprises… faire fonctionner la technologie Meteor 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 formidable. Mais pourquoi devriez-vous vous vous en soucier ?
Turbo charger GraphQL
Si vous créez des applications, que ce soit en tant que concepteur spécifique ou pour une grande entreprise, l’avancement ne devient pas plus simple. La voie à suivre est clairement dirigée vers une complexité accrue grâce aux microservices. Les développeurs acceptent cette complexité car il y a tellement à tirer de l’approche, comme une dextérité accrue. Ils veulent cet avenir.
Mais atteindre cet avenir peut être difficile.
Même GraphQL, malgré tout son potentiel, a en fait été utilisé par de nombreux développeurs pour assembler des services spécifiques. Ce qu’Apollo essaie d’atterrir est une carte des cartes, pour ainsi dire. L’utilisation de graphiques pour rassembler des installations progressivement atomisées 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 le moyen le plus pratique d’utiliser des sources de données disparates sans avoir « à développer ces connexions profondes, directes et délicates à une base de données Oracle particulière ou à un microservice spécifique, ou à produire un tout nouveau point de terminaison REST que quelqu’un doit conserver », explique Schmidt.
Notamment, la technique du supergraphe peut être de nature quelque peu fragmentaire. Walmart, par exemple, a dû déterminer comment intégrer les mainframes qui gèrent leurs magasins avec les microservices qui gèrent leur exécution en ligne. Les clients n’ont pas compris ce problème d’installations et n’ont peut-être même pas découvert que Walmart avait un site Web pour les achats en ligne et un pour le ramassage en magasin. Ils ont définitivement reconnu que les avis facilement disponibles en ligne n’apparaissaient pas pour le ramassage en magasin. Et ils auraient été ennuyés par les différents catalogues de produits hébergés avec chaque système. Walmart n’a pas réussi à arrêter ses mainframes, il a donc utilisé le supergraphe Apollo pour combiner essentiellement les 2 systèmes.
L’approche du supergraphe « n’a pas besoin d’un changement de cascade stop-the-world », dit Schmidt. Il aide les entreprises à relier de manière transparente leurs systèmes hérités à leurs systèmes plus récents. Dans le cas de Walmart, cela impliquait qu’un concepteur frontal pouvait dire : « Montrez-moi les avis sur un article », et ils découvriraient ces évaluations où qu’ils se trouvent, y compris sur leur ordinateur central. Si plus tard, ils refactorisaient ce mainframe en une architecture basée sur des microservices, absolument rien n’aurait besoin de changer sur le front-end.
Coopter le cloud
Une chose intrigante qui émerge de tout ceci : Les nuages n’améliorent pas toujours les choses. AWS, par exemple, propose AppSync, une méthode formidable permettant à un concepteur d’application d’extraire des données de DynamoDB et de les afficher dans son application mobile. Cependant, que se passe-t-il si vous souhaitez extraire des données de DynamoDB, ajouter certaines fonctions sans serveur Azure, appeler des données dans votre ordinateur central et accéder aux données d’un service Google Cloud ou plus ? Toute la promesse de GraphQL et d’un supergraphe à la Apollo est d’apprivoiser des environnements hétérogènes, dont la nouvelle hétérogénéité inclut divers nuages. Il sera difficile pour un cloud particulier de fournir le routage principal requis.
Nous avons 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 compliquer davantage l’informatique d’entreprise. Idées et prières qu’un supergraphe peut aider. C’est possible.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
