What is DataGraph?
The first question that probably sprang to mind when reading the above title is ‘What is DataGraph?’, so let’s start by answering that first question.
- DataGraph is a layer built within Anypoint Platform designed to utilise the power and abilities of GraphQL.
Although this is an accurate statement, to fully understand it, we now also need to understand what GraphQL is.
- GraphQL is an open-source query language for interrogating REST APIs. It allows data to be both queried and updated. Responses are filtered to return specific subsets of data required by the clients.
One of the strengths of REST APIs is that they are well-structured and have a defined interface. So, each time an API is queried, it gives a response which contains a specified list of fields. It is consistent and repeatable.
However, this structure has a disadvantage in that it can be too rigid. Responses to queries may contain data a client doesn’t actually need and it can even require subsequent calls to other APIs to get access to additional data.
The downside to this is not only increased network traffic (which may be an issue to smaller mobile devices) but it also places an onus on the developer of the client app to understand the API solution they are interacting with. So, they not only need to have a grasp of the associated API contracts but they also need to understand any data transformation rules that are required and to know the sequencing of API calls to get to the data they want. In short, they need to know how to use the APIs and how they relate to each other – knowledge and skills they may not have.
DataGraph is the layer within Anypoint Platform that allows GraphQL to be used. It builds up a unified Schema of all the APIs that have been added and an endpoint is exposed for clients to access that schema and it processes all GraphQL requests, aggregating and filtering the data as required.
DataGraph significantly simplifies the querying of API as it provides one single endpoint with no fixed interface. It returns only those fields requested and it gives the ability to query multiple APIs in one go.
What are DataGraph Use Cases?
Let’s look at the primary use cases.
Use Case 1 – Returning different subsets of data to different Clients.
In this example, we have a single API being queried by two different clients (each requiring different responses).
Here, DataGraph acts as the gateway and provides a single endpoint for all clients. It filters results from API based on the request being made from the client app.
Use Case 2 – Querying multiple APIs at once
In this example, we have multiple APIs being queried to return the full dataset required by the client.
Here, DataGraph is the gateway aggregating (and filtering) the results of the APIs in the Unified Schema. Ultimately, these are simplified use cases for ease of understanding, but it shouldn’t be a stretch to imagine a situation where these two use cases would be merged.
Having followed these two examples, the following questions arise:
- Doesn’t use case 1 make Experience APIs redundant?
- Doesn’t use case 2 make Process APIs redundant?
Those are both good questions, and unfortunately there are no simple, definitive answers. The above diagrams are only simplistic views of the use cases and as with most things, ‘the devil is in the detail’.
To help determine whether DataGraph can be used to successfully replace other APIs or even whether it is suitable for a particular solution, the design and functionality required has to be taken into full consideration first.
However, below, are listed the restrictions published by MuleSoft relating to the current limitations of DataGraph.
Anypoint DataGraph supports:
- REST APIs with RAML and OAS specifications
- Only GET methods
- 250 APIs per unified schema
- 16,000 fields per unified schema
Anypoint DataGraph restricts downstream REST API calls to:
- A default of 150 concurrent or ongoing calls per unified schema. API calls can be increased or decreased depending on required workloads or consumption needs Refer to API Call Scaling in Anypoint DataGraph for instructions.
- 5 second timeout per call
- Maximum of 5 MB of response data per call
Anypoint DataGraph limits the query service to:
- 30 second timeout per query
- Maximum of 100 selected fields per query.
These are the most significant limitations and will help determine whether DataGraph is a suitable solution. The timeout limitations do need to be taken into account. Any long running APIs may cause these limits to be exceeded and cause a timeout failure, resulting in data not being returned. DataGraph currently only works with the GET methods of any underlying APIs and updates via POST methods are not yet supported.
Why DataGraph is Important
DataGraph is a very useful addition to the tooling within Anypoint Platform becuase it adds an important ‘string to the bow’ and provides developers with the ability to query REST APIs using GraphQL. For developers, as GraphQL and the flexibility it provides increases in popularity, this can only be a good thing.
However, there are some limitations in the current implementation of DataGraph that need to be considered carefully when determining if DataGraph should be the solution of choice. For example, if the intended solution only requires extraction of data and fits within the stated limitations, DataGraph may be the ideal choice.
If you have any questions and want to investigate if DataGraph meets your requirements, please contact us and we’ll help determine if DataGraph is the solution for you!
References
- MuleSoft DataGraph documentation:
- MuleSoft DataGraph tutorial:
- MuleSoft Coding Lab:
- Main GraphQL site: