MuleSoft’s DataGraph — A Consultant’s 2 Cents

With the API-led connectivity approach, we know that code reusability, and loosely coupled/scalable architecture is attained. But what happens if you want to consume more than one REST API and combine their data to cater to a different use case?

What if there are hundreds of system/process APIs and you have to aggregate responses from those?

What if the aggregation logic is to be in the API layer rather than the front-end?

With the usual API-led connectivity approach You would have to create a separate process API that would consume the data from those APIs -> combine their data -> produce the desired result. This means extra coding effort requirement, deployment and management of the 3rd Process API.

As a good solution, GraphQL can come to rescue YIPEE, and with MuleSoft’s DataGraph, this extra effort is not required. All this can be done in a single query, without any extra effort of implementation, deployment and management of an overhead API.

So, what is DataGraph? Before exploring DataGraph, let’s talk briefly about GraphQL. GraphQl, developed by Facebook in 2012, is an open-source data query language that gives exactly the data that is required, no more and no less. A GraphQL service is created by defining types and fields on those types and then providing functions for each field on each type.

DataGraph can be represented like this -

DataGraph, leveraging the power of GraphQL, enables to unifying of all the data in a single schema. With DataGraph, you can union the data, merge the data, and link the data from different APIs.

Earlier DataGraph could only work on the HTTP GET method, however, with the recent release, DataGraph can also perform mutations.

Mutations are operations that create, update and delete data, i.e. POST, PUT, PATCH, DELETE HTTP methods.

Let’s illustrate this by an example:

Create RAML with proper data types, publish these in Exchange and apply policies in API Manager (if needed), and deploy the applications on CloudHub.

For the demonstration purpose, I have created 2 System APIs:

1. SF Accounts System API with endpoints:

— Get all Accounts

— Create an account

— Get an account by Account ID

2. SF Contacts System API with endpoints:

— Get all contacts

— Create contact

— Get a contact by Contact ID

Now, start configuring the DataGraph by adding these APIs and it would something like this:

Click on GetAccountsData and enable collaboration on the same to enable it to get linked with other datasets.

You can view all the fields of each method and their corresponding Current and Desired state.

Now, enable collaboration on GetContactsData and view its fields if those represent the correct current state:

Now, click on ‘Apply changes’ and wait for the schema to update. Once it is up-to-date, Click on Run Operation and start playing around with DataGraph queries.

To show how DataGraph, now, supports mutation, I will create an account and its corresponding contact:

Thus, DataGraph can be used to perform mutations as well, without much effort.

Now, let’s take another scenario where you want to see the account’s information corresponding to its contact.

Before DataGraph, you would have to create a different Process API to perform this operation. But, with the power of DataGraph, you just have to link the two different datasets to perform this operation, avoiding the extra work of coding, deploying, and managing.

DataGraph basically links the schema of different datasets based on the common attributes. This can be depicted with the ER diagram -

Open your unified schema and ‘Link Configurations’ in GetContactsData, with GetAccountsData, where accountId in GetAccountsData would act as the primary key and foreign key in GetContactsData.

Open GetAccountsData and you would see something like this, once the link has been established.

Click on Apply Changes and wait for the schema to update.

Once the schema gets updated, click on Run Operation. Let’s try to view the account information corresponding to its contact by writing a query.

And that’s it, it’s done in a few simple steps.

You can share the GraphQL endpoint with consumers like the front-end developers, by simply copying the query and sharing it over if you don’t want to give Anypoint Exchange access to users.

Open Postman and try to run the endpoint with the above details.

Concluding the article, you can see that MuleSoft’s GraphQL interpretation i.e. Anypoint DataGraph is one of the most powerful GraphQL engines available in the market as compared to Apollo etc which saves your time and efforts by -

• Aggregating multiple API responses into a single unified schema reading data seamlessly from different downstream APIs.
• Ability to update data to multiple systems in the backend saving developers time to write different process/experience APIs to do that.
• CDN caching to avoid multiple hits on backend systems which improves performance and reduce the load on backend systems.