Leveraging GraphQL with Mule

Adding some additional clarity to to earlier works

Photo by Tyler Lastovich from Pexels

Those who have come before us were the true pioneers, delving into cloudy murky waters and making deep technology less opaque. One of these pioneers was Jitendra Bafna. In Q4 of 2020 he released several YouTube tutorials describing how we might go about creating Mule API’s that leverage GraphQL.

By using GraphQL, you enable clients to choose the fields they’re interested in, thus minimizing the amount of data they get with a request to just what they need. A design like this may also reduce the number of API’s you need to create in order to satisfy your clients needs.

In this article i’m not going to repeat the awesome work which Jitendra has already done for us. Instead, I hope to smooth some of the rough edges I encountered and hopefully make the process easier to reuse.

The first thing you’ll need is the Mule GraphQL connector. Be sure to add the reference to your pom.xml file. As you can see from the Readme file, the instructions for using the connector are rather spartan, so Jitendra had his work cut out figuring out how it all worked.

Next, we’ll take a look at our high level objectives. As most MVP’s are created, some API’s are stood up which provide a solution for some basic needs. Jitenrda’s example uses Accounts, Balances and Transactions.

The API Service layer would typically interact with a backend data store or perhaps they would aggregate results from other endpoints. In the example the response data is kept simple and read from a static file. When we construct our basic MVP API’s in Mule they start to look like this:

Example account file for client request

{
  "id": "42",
  "firstName": "Wily",
  "lastName": "Coyote",
  "address": "666 Dynamite La",
  "phone": "(212) 555-1212",
  "website": "https://acme.com",
  "company": "Acme",
  "accountType": "Saving"
}

With the API Service provider created we can focus our attention on the GraphQL layer. In the example above there may be clients who need just the name and address info. Other clients may want the company and account type as well. You get the point. One of the strengths of using GraphQL is that you can write your API just once and GraphQL will allow your clients to get just what they need.

In your src/main/resources folder you’ll want to create a folder called schema and the the file schema.graphql.

src/main/resources/schema/schema.graphql

schema { 
  query: Query
}
type Query {
  account(
  id: String!
  ): Account!
}
type Account {
  id: String
  firstName: String
  lastName: String
  address: String
  phone: String
  website: String
  company: String
  accountType: String
}
type Balance {
  balanceType: String
  amount: Float
}
type Transaction {
  transActionId: String
  description: String
  amount: Float
  currency: String
  transactionDate: String
}

We’ll add the schema to the graphql connector, which will look like this:

Lets take a look at our new high level flow. The top flow in the GraphQL layer is the console input for displaying graphiql in the browser for modeling client flows. In the parse template you’ll add the sample index.html snippet referenced in the section titled: Usage: UMD Bundle over CDN (Unpkg, JSDelivr, etc)

Clients will now interact with the GraphQL Router flow shown in the center, which will dispatch requests to the appropriate flow. The GraphQL Account flow shown at the bottom will interact with the Account API Service you created earlier. In the flow, Jitendra uses some Groovy code to marshal the GraphQL attributes.arguments into the HTTP Request task to the Acoount Service. The Dataweave transform then renders the results to a Java HashMap, which the Router will then render into the correct GraphQ response.

The index.html file is shown below, be sure to modify the port number if yours is different.

src/main/resources/index.html

To view your GraphQL models you can point your browser at the URI exposed by the console flow and you should see this:

In the left pane, when you specify the firstName and lastName for the account type and the results will be displayed in the center pane. Experiment by tailoring the request for other fields of interest and observe how each GraphQL response is tailored for a clients needs.

I think that should cover most of the rough patches I encountered. Kudo’s to Jitendra for doing the tough work of putting this together the first time!

References

Jitendra Bafna GraphQL series

David Mooter discusses Mulesoft GraphQL Vision, as presented in Connect 2020.