Anypoint Datagraph

Anoop RamachandranWritten by Anoop Ramachandran

Anypoint Datagraph

Every organisation is trying to deliver more connected experiences to their customers, and to do that effectively, they’re looking for ways to increase the delivery speed. In our journey to achieve speed, reuse, better scalability and security, we’ve moved from writing custom code to API’s, which expose our data across systems, predominantly REST API’s, where we can reuse API’s without writing code from scratch.

To understand Anypoint Datagraph we must first understand how data is fragmented across API’s today.

Anypoint Datagraph

In our journey to achieve speed, reuse, better scalability and security, we’ve moved from writing custom code to API’s which expose our data across systems, predominantly REST API’s where we can reuse API’s without writing code from scratch.

REST APIs, as we all know, work in a request and response manner - you ask it for some information, and it gives you every possible answer that it has, and it is designed to capture the capabilities of each individual system according to the user's needs. With REST API's exposing critical data that a business needs, IT can enable developers to self-serve and reuse, rather than starting from scratch.

However, as different systems expand, your network of API’s naturally increases and there will be a large number of APIs for IT to manage and developers to consume. If a developer needs to expose data from a few systems, they would either need to call multiple APIs or ask IT to create another API, which in-turn connects to multiple API’s or systems.

Either way, there is custom logic and complex code like data transformation and orchestration involved. Moreover, API’s may have complex responses and with REST API’s you get every field returned, including the ones that you don’t need. Developers then need to write custom logic to parse through the responses and extract specific fields they need for their project. Keeping this in mind and in order to reuse multiple API’s at once without writing any additional code, Mulesoft leverages the capability of GraphQL query language into its Anypoint Platform named Anypoint Datagraph.


GraphQL is an open-source data query and manipulation language for APIs. It was developed by Facebook and released publicly in 2015. In contrast to REST APIs and SOAP APIs, GraphQL allows every consumer to individually specify what data it needs and how.

It introduces enhanced query capabilities in a standardised way. From an API provider perspective, GraphQL standardises 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 the need for the provider to create a new API.

Anypoint DataGraph

Anypoint DataGraph leverages GraphQL to enhance the consumability of APIs. With Anypoint Datagraph, MuleSoft customers can consume data from multiple APIs in a single request. To achieve this, we can compose a data service by unifying data across all the APIs into one unified schema and we can do that without writing any code. Developers will be able to query the requests as they do it in GraphQL. They will also be able to select exactly the fields they need and they get the results back in just one query.

Let’s understand this with an example.

Anypoint Datagraph

Often API's that we build have relationships with one another. For instance, an order API can be related to a customer API through a customer-id and an invoice API can be related to a product API through product-id. Crucially, through these relationships we can stitch these API’s together and this forms a graph of all the capabilities that exist within these API’s. Using this graph which has all the data across your API’s, we can reuse existing API’s and developers don’t need to spend all that time doing shallow data extraction work instead they can get the data they need from the graph in one request.

This graph is provided as a service, it’s a single endpoint that can be used to make the project go faster and it is the latest way that MuleSoft will accelerate organisations delivery.

In the 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 very holistic view. With Anypoint DataGraph these consuming applications can specify their need in the API call to the DataGraph endpoint.

Benefits of using Anypoint Datagraph

  • It will help developers as they no longer need to build those APIs and write custom code to consume all other APIs in their organisation. They can now focus more on the application logic and deliver the projects to the customers with much more speed.
  • The IT and Ops teams are going to have less code and less APIs to manage and secure, because a single endpoint created with Anypoint Datagraph runs as a SAAS app. Hence there is no maintenance or patching that’s required.
  • To the customers, by using the Anypoint Datagraph, they can reduce operational cost by reducing the number of API’s.

Restrictions and Limitations to Anypoint Datagraph

  1. Anypoint DataGraph supports:

    a. REST APIs with RAML and OAS specifications

    b. GET methods

    c. Up to 250 APIs per unified schema

    d. Up to 16,000 fields per unified schema

  2. Anypoint DataGraph restricts downstream REST API calls to:

    a. A maximum of 150 concurrent or ongoing calls per unified schema

    b. A 5 second timeout per call

    c. A maximum of 5 MB of response data per call

  3. Anypoint DataGraph limits the query service to:

    a. A 30 second timeout per query

    b. A maximum of 100 selected fields per query.

    c. A maximum depth of 100 fields per query.

  4. To enable collaboration and linking, the primary key field should be in a string type.

  5. ONLY available as a cloud offering, but can connect to on-prem REST APIs within the schema

  6. CAN use non-mule apps within DataGraph schema; only the RAML/OAS specs need to be in Exchange.

  7. CANNOT deploy DataGraph endpoints in a high availability fashion.

  8. Each environment, per business group can deploy one DataGraph endpoint/schema only.

Ref: Anypoint DataGraph Overview

Ref: Anypoint DataGraph Hosting Options and Networking

Anypoint Datagraph Roadmap

In the coming releases we expect

  1. High availability support.
  2. Capability to download GraphQL schema.
  3. CI/CD automation support.
  4. Support for compound keys, pagination, merging L2 types etc.