MuleSoft Hits the Mark With GraphQL

The Mule Connect 2020 virtual conference is over and we got to see more details on MuleSoft’s vision for GraphQL, and it shows MuleSoft is working aggressively to fill a gap in GraphQL. Let’s review what GraphQL is, its challenges, and how MuleSoft is addressing those challenges.

GraphQL Basics

GraphQL is an API specification for querying data across other APIs. It originated at Facebook in 2012, released as open-source in 2015. It allows API clients to tell the API what it wants rather than the API assuming it knows what the client wants. This is particularly useful for APIs that support UIs. A challenge with UIs is that they may need data from many sources. Calling all those sources can make the UI complex. It can also add too much chatter for mobile apps, which are sensitive to bandwidth. We often solve this by aggregating lower-level business APIs with a composite view-model API or by using the backend for frontend (BFF) pattern.

This has some problems, though. These APIs are very coupled with the page they support. When you have both a web and mobile UI, you often need to code two flavors of the view-model or BFF APIs. When you want to re-arrange things on the UI, such as to A/B test a new experience, you again need to rewrite these APIs.

With GraphQL, the UI layers tell the GraphQL layer what it needs using a GraphQL specification, and the API returns it. Now you can have one GraphQL API supporting both your mobile and web UIs instead of two view-models or BFFs. Want to AB test moving some field to a different page? Just have the new page request the new field when it needs it; no need to go change the API layer.

GraphQL vs. OData

Wait, isn’t this just OData? No. OData is roughly like ODBC/JDBC for the web. The query is pushed down into a database, and the database handles the query. This creates some limitations.

• The OData API owner is less control over what queries the user sends. This opens the door for injection attacks to exploit misconfigured databases or overload a database with a run-away query.
• You’re limited to databases you can connect to directly. If you need to query data that’s only accessible via a service interface (SOAP, REST, etc.), then you’re out of luck.
• Joining data across multiple databases is difficult. This is particularly problematic as IT departments move towards a microservices architecture and break up their data monoliths. It is becoming less common to have one loan database as the system of record.

GraphQL runs in the API layer. Therefore, any data source an API can access can be queried by GraphQL. Furthermore, it can join data across APIs, such as pulling a customer from a customer account API and joining it with the customer’s orders and billing history via separate order and billing APIs.

GraphQL Challenges

While UI developers may love GraphQL, it gets much less love from backend developers. This is because GraphQL can be challenging to maintain. You need to define the relationships between the many data sources that the GraphQL API supports. Furthermore, you need to document them so that end users can know how each API entity relates to others. Lastly, GraphQL just has a much steeper learning curve than REST. These challenges can be a barrier to adoption.

MuleSoft’s GraphQL GUI

During the keynote at Mule Connect, they presented a demo of MuleSoft’s upcoming GraphQL UI, which they call the API Federation. It appears to address the above challenges.

First, the GraphQL maintainer can import APIs managed by the Anypoint Platform. Anypoint already has the OpenAPI specification of every API stored in the Anypoint Exchange API directory, and this info is automatically brought into the graph editor. Then through drag-and-drop UI, you can define the entity relationships between the various APIs. It then appears that Anypoint will generate the schemas you need to automatically spin up a GraphQL API on the Anypoint platform and publish that schema to the Anypoint Exchange API directory.

Secondly, on the consuming side, the UI developer can discover the schema by searching the Anypoint Exchange. From there he can see the visual of the schema and use this to build a query by clicking on the entities and fields he needs. There is even a preview pane that does live queries and shows you the results as you edit the query. When finished, Anypoint will generate the query you need in a variety of languages so you can copy/paste it into your code.

My impression is it will make creating, maintaining, and consuming GraphQL much easier for both the backend developer and the UI developer. Especially if you are already a MuleSoft customer and would rather not add more vendors into your API space.

Unfortunately, MuleSoft did not make a video of this public even though it was a 100% free virtual conference. Hence why I am unable to provide you screenshots. So if you’re interested in GraphQL, keep an eye out for this in an upcoming release.

In the meantime, do some deeper dive reading about GraphQL. Even if you don’t have an interest in MuleSoft, there are a growing number of open-source and commercial offerings for you to explore. For IT teams trying to accelerate the speed of delivery for user experience, GraphQL will be a key tool to have in your toolbox.