When I hear something once – fine. Hear it again – coincidence? Three times – pattern! It was last week I was asked by three separate customers about GraphQL, so I figure there might be a few more out there worth sharing my thoughts on this pattern with.
The search for increasing developer productivity is a never ending one, and building APIs more efficiently is a hot topic in this respect. At the very same time the first front-end developer sketched a wire-frame on the whiteboard of their cave, they were asking back-end developers to make them better interfaces. It’s a sad fact that the native query interfaces of back-end data sources never seem to lend themselves to the needs of front-end data manipulation!
I remember my own stretch as front-end developer trying to access any number of databases. I did anything I could to avoid writing in-line SQL. This included writing stored procedures and using object relational mappers (ORMs). Why? When accessing tables with in-line SQL, the front-end becomes tightly bound to the data structure, and as a consequence, the developer needs to undertake all sorts of code gymnastics to get the data in a useable form. This includes code to minimize network round trips and code to get and put only necessary fields. Yuck! A query layer between the database and the front-end, such as an ORM, can automate much of this code and simplify the life of the front-end developer.
GraphQL and Anypoint Platform
As ORM is to database tables, so GraphQL is to RESTful APIs. Today, front-end developers are struggling with the complexity of accessing back-end data in a world with an increasing number of RESTful APIs on top of the myriad of other data sources that they already deal with. GraphQL provides them a query layer that returns back-end data from these diverse sources in a friendly and efficient way. At a high-level, GraphQL provides a master data schema, exposed as a single endpoint where queries can be sent. Behind this endpoint, resolvers connected to disparate data sources (RESTful APIs, databases, etc.), process these queries and populate the schema for return to the front-end.
If you are a curious Mule, this understanding will raise some interesting questions about the relationship between GraphQL and Anypoint Platform. Firstly, GraphQL is used to efficiently surface metadata stored within Anypoint Platform. Anypoint Platform provides a GraphQL API for Exchange. Details of the API are here. This is useful as there is often a need to build customized API portals that work with data stored in the Exchange repository. Instead of a front-end developer needing to call multiple resource-aligned RESTful APIs and assemble the data programmatically, they now have one API to query all entities with the Exchange repository.
GraphQL and API-led connectivity
The next area of interest is the relationship between GraphQL and API-Led connectivity. GraphQL provides a simplified interface for developers to work with by shielding them from complexity of the underlying data structure. This is exactly what API-led connectivity provides. Consider a Process API – it creates a level of abstraction above a number of System APIs, alleviating the need for the developer to understand the complexity of these lower-level APIs.
What today’s Process API lacks is a queryable endpoint to the extent that RESTful APIs will provide only rudimentary query capability in the form of query parameters. What GraphQL lacks is the provision of a connector library to speed connectivity to common data stores. The implementation of resolvers in GraphQL is left to the developer. To fill the Mule deficiency, we built a showcase Mule plug-in which provides the capability needed to build GraphQL APIs in Mule. This allows developers to leverage the full library of connectors available to them in Exchange. An example Mule application using this plug-in is shown here.
Now that I have created my GraphQL API, how do I manage and monitor this on my application network? As the GraphQL API is exposed as a single endpoint in my Mule application, this endpoint can then be managed by the API gateway. Great! Similarly, the individual System APIs discussed in our example above can also be managed by an API gateway. The complexity arises in that a GraphQL API from a functional perspective can represent many RESTful APIs. This makes it a sort of “gateway API,” which is only suitable for the application of course-grained security and policy. This is, in effect, the security model employed by API-led connectivity at the experience layer — we like to apply course-grained security at the edge and more fine-grained security as we move deeper into the network. This can include generalized protection, including DDOS and user authentication at the edge and column-level entitlements as we move deeper inside the resolvers. Now that my GraphQL API is secured and managed, I automatically get access to the monitoring capabilities provided by Anypoint Monitoring.
As we have discussed, GraphQL is an important developer productivity tool. At MuleSoft, we are working to help you build GraphQL interfaces into your application networks. We are doing this by providing GraphQL interfaces into Anypoint Platform through the provision of frameworks to build your GraphQL APIs into your API-led architectures, along with the ability to manage and monitor these APIs in Anypoint Platform.
So how is that for a pattern?
