MuleSoft hat diese Woche seiner Anypoint-Plattform eine DataGraph-Funktion hinzugefügt, um Anwendungen zu integrieren, die die GraphQL-Abfragesprache verwenden, um Daten von mehreren vorhandenen APIs mit einer einzigen Abfrage sofort zu erkennen, darauf zuzugreifen und sie bereitzustellen, ohne zusätzlichen Code schreiben zu müssen.
Gleichzeitig hat MuleSoft zusätzliche Konnektoren für Automation Anywhere, Google Sheets, JIRA, Netsuite und Stripe sowie eine Instanz von MuleSoft Accelerators für die Verbindung zu SAP-Anwendungen mit von MuleSoft definierten Konnektoren und Best Practices hinzugefügt.
Zu diesen Best Practices für API-Entwickler gehören:
- Erwartungen schaffen: Halten Sie Ihre Kommunikationswege offen und klar. Teilen Sie den Entwicklern mit, was Sie von ihnen und dem Projekt erwarten, geben Sie klare Fristen an und gehen Sie auf Schwachstellen ein, die die API-Funktionalität lösen sollte.
- Dienstnachrichten: Alle APIs und Services sollten an den Geschäftszielen ausgerichtet sein und Services führen, die darauf abzielen, einen Mehrwert für neue und bestehende Produkte und Services zu liefern.
- Fallstudien: Verwenden Sie Fallstudien, um Beweise zu liefern und die Verbesserungen zu veranschaulichen, die die API-Einführung für das Projekt bringen wird.
- Dokumentation: Stellen Sie sicher, dass Dokumentationstools vorhanden sind, damit das Entwicklerteam seinen Fortschritt bei der Übernahme der API genau dokumentieren kann.
- SDKs und Bibliotheken: Stellen Sie Ressourcen wie wiederverwendbaren Code und Prozesse (einschließlich SDKs und Bibliotheken) bereit, um die Entwicklung und Implementierung zu beschleunigen.
Schließlich stellt MuleSoft seine Anypoint Runtime Fabric jetzt zum ersten Mal auf Kubernetes-Plattformen wie Azure Kubernetes Service, Amazon Elastic Kubernetes Service und Google Kubernetes Engine zur Verfügung. Die Anypoint Runtime Fabric ermöglicht die konsistente Bereitstellung der Anypoint-Plattform, die in einem Container gekapselt ist.
Der Anypoint DataGraph verwendet die gleichen GraphQL-Kernfunktionen, die MuleSoft zuvor in die Software-as-a-Service (SaaS)-Anwendungen eingebettet hat, die von der Muttergesellschaft Salesforce bereitgestellt wurden. Jetzt werden diese Fähigkeiten anderen Anwendungen über eine Reihe von Low-Code-Tools in der Anypoint-Plattform breiter zugänglich gemacht, die es Entwicklern ermöglichen, GraphQL breiter als Alternative zu REST-APIs einzusetzen, sagt Shaun Clowes, Senior Vice President für Produktmanagement bei MuleSoft.
Dieser Ansatz macht es Entwicklern einfacher, ihre Anwendungen mit anderen Datenquellen zu integrieren, unabhängig davon, ob die von ihnen erstellte Anwendung mit prozeduralem Code oder einer Low-Code-Plattform erstellt wurde. Selbst wenn Entwickler es vorziehen, ihre Anwendung mit prozeduralem Code zu schreiben, ist es dennoch sinnvoll, ein Low-Code-Tool einzusetzen, um die Integration schneller zu erstellen, bemerkt Clowes.
Entwickler müssen heute in der Lage sein, Daten flexibel über mehrere APIs zu nutzen, da Initiativen zur digitalen Geschäftstransformation weiter expandieren und sich weiterentwickeln, fügt Clowes hinzu. Tatsächlich müssen Entwickler schnell Anwendungen erstellen, damit ihre Organisationen geschickt auf sich schnell ändernde Geschäftsanforderungen reagieren können, sagt Clowes.
Auch die Arten von Entwicklern, die Low-Code-Integrationstools einsetzen, nehmen zu. Sogenannte Citizen Developer beginnen damit, Anwendungen zu erstellen, die Daten über APIs konsumieren müssen. Die Ausgereiftheit dieser Anwendungen hängt natürlich von den Fähigkeiten dieser Entwickler ab.
„Die Herausforderung bei Bürgerentwicklern besteht darin, wie bürgerschaftlich sie sind“, sagt Clowes.
Unabhängig davon, wer die Anwendungen erstellt, wird es für Entwickler mit unterschiedlichem Fachwissen immer einfacher, APIs wiederzuverwenden. Professionelle Entwickler könnten beispielsweise eine Bibliothek mit geprüften APIs erstellen, die von anderen Entwicklern wiederverwendet werden könnten. Erforderlich ist ein zentralisierter Ansatz zum Erstellen und Bereitstellen von APIs, der ein dringend benötigtes Governance-Framework bietet, da sich die Verantwortung sowohl für das Erstellen als auch für die Wartung von APIs weiter nach links zu den Entwicklern verlagert, bemerkt Clowes. Das ist nicht nur aus Compliance-Sicht wichtig, sondern auch, weil es nicht ungewöhnlich ist, dass Entwickler, die an einem separaten Projekt arbeiten, redundante APIs erstellen.
Für die Zukunft ist klar, dass APIs im Mittelpunkt der sich weiterentwickelnden Anwendungsentwicklung stehen. Microservices-basierte Anwendungen der nächsten Generation sind darauf angewiesen, dass jeder Service über eine eigene API verfügt. Die Anzahl der APIs, die Organisationen bald finden könnten, könnte in die Tausende gehen. GraphQL bietet einen wichtigen fehlenden Dreh- und Angelpunkt, um mit ihnen allen fertig zu werden. Die Herausforderung besteht nun darin, den besten Weg zu finden, es neben älteren REST-APIs zu implementieren, die in absehbarer Zeit nicht verschwinden werden.
