MuleSoft this week added a DataGraph capability to its Anypoint Platform for integrating applications that employ the GraphQL query language to instantly discover, access, and serve data from multiple existing APIs with a single query without writing any additional code.
At the same time, MuleSoft has added additional connectors Automation Anywhere, Google Sheets, JIRA, Netsuite, and Stripe, along with an instance of MuleSoft Accelerators for connecting to SAP applications using connectors and best practices defined by MuleSoft.
Among those best API developer practices include:
- Create Expectations: Keep your lines of communication open and clear. Tell developers what you expect of them and the project, provide clear deadlines, and address any pain points the API functionality should solve.
- Service Messaging: All APIs and and services should align with business goals and lead services aimed at delivering value for new and existing products and services.
- Case Studies: Use case studies to provide evidence and illustrate the improvements that API adoption will bring to the project.
- Documentation: Ensure that documentation tools are in place so the developer team can accurately document their progress in adopting the API.
- SDKs and Libraries: Provide resources such as reusable code and processes (including SDKs and libraries) to help speed up development and implementation.
Finally, MuleSoft is now making its Anypoint Runtime Fabric now available for the first time on Kubernetes platforms such as Azure Kubernetes Service, Amazon Elastic Kubernetes Service, and Google Kubernetes Engine. The Anypoint Runtime Fabric makes it possible to consistently deploy the Anypoint platform encapsulated within a container.
The Anypoint DataGraph employs the same core GraphQL capabilities that MuleSoft previously embedded within the software-as-a-service (SaaS) applications provided by parent company Salesforce. Now those capabilities are being made available more widely to other applications via a set of low-code tools in the Anypoint Platform that enables developers to employ GraphQL more broadly as an alternative to REST APIs, says Shaun Clowes, senior vice president for product management at MuleSoft.
That approach makes it simpler for developers to integrate their applications with other data sources regardless of whether the application they create is built using procedural code or a low-code platform. Even when developers prefer to write their application using procedural code, it still makes sense to employ a low-code tool to create integration faster, notes Clowes.
Developers today need to be able to flexibly consume data via multiple APIs as digital business transformation initiatives continue to expand and evolve, adds Clowes. In effect, developers are being required to rapidly compose applications to enable their organizations to adroitly respond to rapidly changing business requirements, says Clowes.
The types of developers employing low-code integration tools are starting to expand as well. So-called citizen developers are starting to build applications that need to consume data via APIs. The sophistication of those applications naturally varies depending on the skills of those developers.
“The challenge with citizen developers is how citizenry they are,” says Clowes.
Regardless of who builds the applications, it’s becoming much easier for developers of varying expertise to reuse APIs. Professional developers, for instance, might create a library of vetted APIs that could be reused by other developers. The one that is required is a centralized approach to building and deploying APIs that provides a much-need governance framework as responsibility for both building and maintaining APIs shifts further left toward developers, notes Clowes. That’s critical not only from a compliance perspective but also because it’s not uncommon for developers working on a separate project to create redundant APIs.
Going forward, it’s clear APIs are at the center of application development as it continues to evolve. Next-generation microservices-based applications depend on each service to have its own API. The number of APIs that organizations may soon find themselves could number in the thousands. GraphQL provides a critical missing lynchpin to cope with them all. The challenge now is finding the best way to implement it alongside legacy REST APIs that won’t be going away any time soon.
