MuleSoft a ajouté cette semaine une fonctionnalité DataGraph à sa plate-forme Anypoint pour intégrer des applications qui utilisent le langage de requête GraphQL pour découvrir, accéder et servir instantanément les données de plusieurs API existantes avec une seule requête sans écrire de code supplémentaire.
Dans le même temps, MuleSoft a ajouté des connecteurs supplémentaires Automation Anywhere, Google Sheets, JIRA, Netsuite et Stripe, ainsi qu'une instance d'accélérateurs MuleSoft pour se connecter aux applications SAP à l'aide de connecteurs et des meilleures pratiques définies par MuleSoft.
Parmi ces meilleures pratiques de développement d'API, citons :
- Créer des attentes : Gardez vos lignes de communication ouvertes et claires. Dites aux développeurs ce que vous attendez d'eux et du projet, fournissez des délais clairs et résolvez les problèmes que la fonctionnalité d'API devrait résoudre.
- Messagerie de service : Toutes les API et tous les services doivent s'aligner sur les objectifs commerciaux et diriger les services visant à apporter de la valeur aux produits et services nouveaux et existants.
- Études de cas : Utilisez des études de cas pour fournir des preuves et illustrer les améliorations que l'adoption de l'API apportera au projet.
- Documents : Assurez-vous que des outils de documentation sont en place afin que l'équipe de développeurs puisse documenter avec précision leur progression dans l'adoption de l'API.
- SDK et bibliothèques : Fournissez des ressources telles que du code et des processus réutilisables (y compris des SDK et des bibliothèques) pour accélérer le développement et la mise en œuvre.
Enfin, MuleSoft rend désormais son Anypoint Runtime Fabric disponible pour la première fois sur les plates-formes Kubernetes telles qu'Azure Kubernetes Service, Amazon Elastic Kubernetes Service et Google Kubernetes Engine. Anypoint Runtime Fabric permet de déployer de manière cohérente la plate-forme Anypoint encapsulée dans un conteneur.
Anypoint DataGraph utilise les mêmes fonctionnalités de base de GraphQL que MuleSoft précédemment intégrées dans les applications de logiciel en tant que service (SaaS) fournies par la société mère Salesforce. Désormais, ces fonctionnalités sont mises à la disposition d'autres applications plus largement via un ensemble d'outils low-code dans la plate-forme Anypoint qui permet aux développeurs d'utiliser GraphQL plus largement comme alternative aux API REST, déclare Shaun Clowes, vice-président senior pour la gestion des produits chez MuleSoft.
Cette approche permet aux développeurs d'intégrer plus facilement leurs applications à d'autres sources de données, que l'application qu'ils créent soit construite à l'aide de code procédural ou d'une plate-forme low-code. Même lorsque les développeurs préfèrent écrire leur application à l'aide de code procédural, il est toujours logique d'utiliser un outil low-code pour créer une intégration plus rapidement, note Clowes.
Les développeurs doivent aujourd'hui être en mesure de consommer des données de manière flexible via plusieurs API alors que les initiatives de transformation numérique de l'entreprise continuent de se développer et d'évoluer, ajoute Clowes. En effet, les développeurs sont tenus de composer rapidement des applications pour permettre à leurs organisations de répondre adroitement à l'évolution rapide des besoins de l'entreprise, déclare Clowes.
Les types de développeurs utilisant des outils d'intégration low-code commencent également à se développer. Les soi-disant développeurs citoyens commencent à créer des applications qui ont besoin de consommer des données via des API. La sophistication de ces applications varie naturellement en fonction des compétences de ces développeurs.
"Le défi avec les développeurs citoyens est de savoir à quel point ils sont citoyens", déclare Clowes.
Indépendamment de qui construit les applications, il devient beaucoup plus facile pour les développeurs de diverses expertises de réutiliser les API. Les développeurs professionnels, par exemple, peuvent créer une bibliothèque d'API approuvées qui pourraient être réutilisées par d'autres développeurs. Celle qui est requise est une approche centralisée de la création et du déploiement des API qui fournit un cadre de gouvernance indispensable, car la responsabilité de la création et de la maintenance des API se déplace plus à gauche vers les développeurs, note Clowes. C'est essentiel non seulement du point de vue de la conformité, mais aussi parce qu'il n'est pas rare que les développeurs travaillant sur un projet distinct créent des API redondantes.
À l'avenir, il est clair que les API sont au centre du développement d'applications à mesure qu'elles continuent d'évoluer. Les applications basées sur les microservices de nouvelle génération dépendent de chaque service pour avoir sa propre API. Le nombre d'API que les organisations pourraient bientôt trouver pourrait se chiffrer en milliers. GraphQL fournit une clé de voûte manquante critique pour faire face à tous. Le défi consiste maintenant à trouver le meilleur moyen de l'implémenter parallèlement aux anciennes API REST qui ne disparaîtront pas de si tôt.
