Datagraph : Mulesoft veut faciliter la réutilisation des API avec GraphQL
Le spécialiste du développement et de la gestion d’API tenait sa conférence annuelle le 18 et 19 mai 2021. MuleSoft a préféré se concentrer sur des fonctionnalités réservées aux développeurs, architectes et intégrateurs de données et d’applications, mais mise in fine sur la collaboration des métiers et des services IT.
Si l’influence de Salesforce se fait sentir sur la manière de communiquer, MuleSoft demeure ce que certains appellent « une boîte de développeurs » qui s’adresse à des DSI. Il suffit de lister les nouveautés présentées lors de son événement MuleSoft Connect pour s’en rendre compte.
Il faut dire que l’éditeur essaye de résoudre des problématiques résolument IT. Dans le cadre de son Connectivity Benchmark 2021, il a interrogé 800 leaders IT d’entreprise de plus 1 000 salariés, répartis dans 10 pays (les États-Unis, la France, le Royaume-Uni, l’Allemagne, Singapour, Hong Kong, le Pays-Bas et l’Australie).
Pas moins de 87 % des responsables affirment que les défis d’intégrations freinent les projets de transformation numérique de leur organisation. En moyenne, les équipes IT passeraient 36 % de leur temps à concevoir, construire et des tester des intégrations personnalisées. Pourtant, les stratégies API sont désormais en place : 96 % des entreprises emploieraient ces interfaces de programmation. Cependant, 42 % des API seraient réutilisables.
MuleSoft a notamment identifié un problème rencontré en premier lieu par les développeurs front-end. Quand ils effectuent une recherche de données, une seule demande peut réclamer l’accès à des dizaines d’API, ce qui induit l’écriture de multiples requêtes.
« Considérons une API Order qui dispose des informations sur les commandes et une API Inventory qui accède aux catalogues produits. Maintenant, l’élément Order peut avoir une référence au catalogue de produits qui sont consultables par ID. Vous savez que ces API sont reliées. Mais lorsque vous créez une application pour que vos employés accèdent à ces données, souvent vous vous retrouvez à devoir créer une autre API pour joindre ces informations », explique Shaun Clowes, Senior Vice-Président, Product Management chez MuleSoft.
Dans Anypoint, GraphQL ne remplace pas les API REST, il les connecte
Pour répondre à ce problème, l’éditeur a présenté la standardisation de l’emploi de GraphQL dans la plateforme Anypoint. Anypoint Datagraph doit permettre de consommer les données en provenance de multiples API en écrivant une seule requête GraphQL. Il ne s’agit donc pas de remplacer les API REST existantes, mais d’offrir un point de terminaison unique pour les interroger.
« Datagraph permet de déclarer les relations entre les API afin de préciser que l’ID du produit mentionné dans l’interface Order fait référence à d’autres API. »
Shaun ClowesSenior Vice-Président, Product Management, MuleSoft.
« Datagraph permet de déclarer les relations entre les API afin de préciser que l’ID du produit mentionné dans l’interface Order fait référence à d’autres API. Ensuite, vous pouvez utiliser le point de terminaison pour poster une requête et fédérer les résultats », indique Shaun Clowes. « Nous nous attendons à ce que presque toutes les nouvelles applications en profitent. Si vous construisez une application mobile ou une interface Web, nous pensons que cela permet d’accélérer les développements par rapport à l’utilisation d’API statiques », vante-t-il. Le dirigeant rappelle que GraphQL se prête bien aux interactions avec le framework React.JS.
Datagraph se présente sous la forme d’un service managé qui crée automatiquement le point de terminaison, le schéma « unifié » GraphQL et renvoie les réponses aux requêtes. Il semble inspiré d’Exchange Graph, une API conçue pour accéder aux requêtes POST depuis un seul endpoint, à la différence que cette dernière est gratuite, mais « self-managed ».
Il convient toutefois d’exprimer les relations entre les API parce que les spécifications standards dédiées aux API ne les renseignent pas, ce qui demande de modifier les interfaces de programmation. « Vous pouvez accéder à toutes vos API dans Exchange [la marketplace d’Anypoint N.D.R.] et les éditer pour ajouter les relations depuis Datagraph. C’est très rapide », insiste Shaun Clowes.
Par ailleurs, MuleSoft Anypoint s’enrichit de 26 nouveaux connecteurs vers Teams, Slack, MongoDB Atlas, Salesforce Commerce Cloud B2C Shop, Jira, PI Historian (OS PI), Alexa, Asana, Google Sheets, Netsuite ou encore Stripe. En outre, l’éditeur a présenté de templates packagés MuleSoft Accelerator pour les services Finances et Retail dans le but d’accélérer les intégrations avec l’ERP SAP.
Un autre sujet pour les services IT concerne les déploiements de ces API. Quand LeMagIT lui demande où les clients exécutent en majorité leurs interfaces de programmation, le SVP Product Management préfère rester vague et rappelle que Runtime Fabric, le service conteneurisé dédié à l’exécution d’API de la plateforme AnyPoint, supporte de nombreux environnements.
Runtime Fabric sur les distributions Kubernetes des fournisseurs cloud
« Nos clients ont des exigences très diverses en matière d’environnement de déploiement, ce qui est logique, car ils gèrent des charges de travail plus ou moins critiques. Dans certains cas, les applications sont extrêmement sensibles et ils veulent les exécuter sur site dans un centre de données qui leur appartient, là ils ont le contrôle total. Nos clients exécutent également des millions d’API dans Mulesfot CloudHub, qui est notre environnement cloud où ils peuvent héberger des interfaces », affirme-t-il.
« C’est pourquoi nous avons plusieurs offres. Nous avons donc, depuis longtemps, une Runtime Fabric déployable en tant qu’une appliance sur site. Vous pouvez la déployer sur des serveurs bare metal ou sur des machines virtuelles dans votre infrastructure sur site », indique Shaun Clowes.
Les clients n’avaient pas la possibilité de gérer eux-mêmes des clusters Runtime Fabric à l’aide de l’orchestrateur Kubernetes. MuleSoft ajoute cette capacité self-managed depuis Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE) et Elastic Kubernetes Service (Amazon EKS). Aussi, les développeurs ont accès depuis le 29 avril à Anypoint Studio 7.9, une version légèrement corrigée de l’IDE (dérivé d’Eclipse 4.18 et Java 11) intégré à la plateforme. Celui-ci inclut DataWeave Playground, un environnement sandbox pour apprendre le langage d’expression de MuleSoft.
MuleSoft Composer : un avenir en dehors de Salesforce
Mais depuis son acquisition par Salesforce et parce que le marché de l’iPaaS s’y dirige à grands pas, MuleSoft souhaite aussi faciliter le développement d’intégrations par les métiers. Il a commencé en rendant disponible MuleSoft Composer dans Salesforce. Pour l’instant, le nombre de connecteurs se compte sur les doigts de la main, mais l’éditeur estime que c’est la voie à suivre. MuleSoft Composer sera également accessible depuis la plateforme Anypoint à l’horizon 2022.
« Actuellement, les intégrations qui résultent de Composer sont construites sur la même plateforme, elles fonctionnent de la même manière, elles ont la même sécurité, les mêmes normes de surveillance de la conformité que n’importe quelle autre build [API ou Mule Apps N.D.R.] au-dessus d’Anypoint », assure Shaun Clowes.
Si cette brique d’intégration low-code/no-code n’est pas encore disponible depuis Anypoint, c’est que l’éditeur, tout comme Google avec Business Application Platform, cherche à faire coopérer les développeurs et les métiers. « Les métiers doivent aussi pouvoir automatiser leurs tâches, mais il ne faut pas s’attendre à ce qu’ils manipulent des objets complexes dans des ERP comme Oracle NetSuite, ou qu’ils accèdent à des systèmes bas niveau ; ce ne serait pas sécurisé. En revanche, ils peuvent collaborer avec des développeurs pour utiliser les briques de constructions mises à leur disposition », envisage le SVP Product Management.
MuleSoft Composer permettrait alors de donner accès aux métiers à des API personnalisées, de hauts niveaux, qu’ils pourraient manier pour exécuter leurs tâches courantes, par exemple la génération de factures, tout en se connectant aux systèmes les plus complexes, gérés par les services IT. Ce que l’approche low-code/no-code apporte, selon Shaun Clowes, c’est la possibilité de faciliter la compréhension de ces interfaces par les collaborateurs, car elles seront exprimées avec la même terminologie que leurs logiques métiers. À voir maintenant si l’éditeur arrive à tenir cette promesse.
