This is the first blog in a series on how Anypoint DataGraph relates to the concept of API-led connectivity. DataGraph is evaluated as a new option to consume APIs compared to REST-based approaches.
Introduction to GraphQL and DataGraph
GraphQL is an open-source data query and manipulation language for APIs. It was developed at Facebook and was released publicly in 2015. In contrast to REST and SOAP APIs, GraphQL allows every consumer to individually specify what data it needs and how. It introduces enhanced query capabilities in a standardized way. These include filtering, sorting, search, pagination, and join operations. Flexibility of consumption is enhanced, as the developers of consuming applications get more control and freedom to define what data they want. Thus, only the data that is needed is moved over the network and the consuming application does not need to filter, sort, or join data.
From an API provider perspective, GraphQL standardizes the definition of an API that fulfills the needs of multiple consumers and use cases. For example, instead of exposing several APIs to provide individually tailored product data to API consumers, just one GraphQL endpoint is required. If there is a new API consumer demanding the data in a different way, it can specify its requirements as a GraphQL query without needing to create a new API.
Anypoint DataGraph leverages GraphQL to enhance the consume-ability of APIs. Every time you add a new API to your application network, Anypoint Platform stores it as a graph of metadata. DataGraph enables you to connect those graphs into one unified schema that runs as a single GraphQL endpoint and contains and links all of the fields defined within all of your APIs.
In summary, API providers now have a standardized way to collaborate on building a holistic view of information. As a result, consumers can create new connected experiences by querying across the underlying APIs without needing to understand all of the relationships or specific capabilities that exist within them.
DataGraph in context of API-led connectivity
Anypoint DataGraph drives consumability of APIs by providing a capability to tailor data for the needs of a digital channel. For example, a mobile application just needs a few fields from a product data set, while a web portal needs more information to deliver a holistic view. With Anypoint DataGraph these consuming applications can specify their need in the API call to the DataGraph endpoint.
Looking at MuleSoft, API-led connectivity addresses the same challenge via an architectural approach: the introduction of architectural layers with one dedicated layer capturing the specifics of digital channels (Experience APIs).
The fundamental idea behind Experience APIs is the separation of the logic needed to tailor data for a digital channel from the general integration logic. This separation is enforced by the API contracts of the underlying channel-agnostic Process APIs. This separation of concerns makes Process APIs reusable across various digital channels by keeping them free of any channel-specific logic. As a result, Experience APIs can be built quickly by reusing Process APIs. This speed of delivery is also supported by the completeness of the Anypoint toolchain around API specification and implementation.
Changes happen most often at Experience Layer
The figure above illustrates the different frequency of change at the System, Process, and Experience layer. The expected frequency increases by every layer with the Experience layer being the layer with the highest frequency of change. If we look at dependencies between layers it is recommended that APIs should not be dependent on API that are expected to change more often. Thus, the direction of dependencies is from top to bottom.
Anypoint DataGraph fits into this picture on the Experience and Process layer. Regarding the Experience layer, DataGraph allows the consumer to describe all the required channel-specific tailoring. Additionally, DataGraph provides capabilities to join and merge data across various APIs; a typical functionality of Process APIs. In summary, DataGraph provides an alternative approach for these tasks.
This leads us to the question: What is the best approach for my use case? In the next post, we will present three approaches to API consumption to lay the foundation for an architectural discussion.
For more information on Anypoint DataGraph, watch our webinar.
