GraphQL Middleware
Easily spread functionality across you server.
The development of GraphQL application starts with a model. Model is the soul of our system; therefore, we should implement it first. Great! Once we have a model we feel confident about, we start writing resolvers, many of them.
Fast forward a couple of weeks, our application now has an enormous user base, and our codebase is close to a hundred queries. A manager comes into our office and tells us that WIP Corp. has decided to implement the in-depth logging system and we have to make sure each of the resolvers adopts specific functionality.
What now? — We are definitely not going to rewrite each of the resolvers by hand! That’s not DRY at all!
Rethink middleware
Let’s get our hands dirty real quick. We want to implement a simple logging function which would report to our error collector whenever any of our resolvers stumbles upon an issue.
We are very cautious, and we want to make sure everything works before pushing new functionality to production. Let’s apply our middleware only to one test field of Query type — foo, for example.
Simple! But what did you do with resolve and parent and all the fields?
Powered by simplicity
We wanted to make GraphQL Middleware as easily adaptable as possible. The API is next to identical to existing GraphQL JS one, which exposes parent, arguments, context and info arguments to a function resolver — these fields are just copied over.
Atop of that, we’ve added resolver argument to the middleware execution which allows you to control the execution of your query precisely. It is necessary to call resolver to make the query executable, but there is no need to pass in all the arguments. The missing ones get automatically appended at the end.
360° degrees of freedom
Now that we understand how middleware gets executed, it seems like our middleware works. Because we want to apply it to the whole Query, we think about applying it to every field one by one. Wrong! It’s as simple as this.
Pretty neat! Whole schema? Ez Pz!
GraphQL Middleware follows a simple waterfall-like precept when applying middleware. Whenever you define a middleware all fields, types or whole schemas, which are below your function will be wrapped inside it.
Therefore, if you define only a function, entire schema and all its fields and types will be affected; if you apply it to a particular type, all type fields will be modified, and if you use it only on a specific field, just that field will be affected.
Shut up and take my money!
We are happy to see that you’ve decided to use GraphQL Middleware. You can use it out of the box with Yoga, by nesting your middlewares in middlewares property, or, you can use a standalone function which wraps your schema in resolvers and returns a new one.
In this article, we’ve learned how and why you should use GraphQL Middleware in your application. We have demonstrated its basic functionality on the example of simple logging system and explained the semantics of its API.
To discover more prebuilt plugins for GraphQL Middleware, which you can use with your application, check out our readme, and stay put for the upcoming features.