GraphQL server in Java: Part III: Improving concurrency

The idea behind GraphQL is to reduce the number of network round-trips by batching multiple, often unrelated requests, into a single network call. This greatly reduces latency by delivering many pieces of information at once. It’s especially useful when multiple sequential network round-trips can be replaced with a single one. Well, honestly, every web browser does that automatically for us. For example, when we open a website with several images, the browser will send HTTP requests for each image concurrently. Or, to be precise, it will start not more than a certain number of connections to the same host. It’s something between 2 and 8, depending on the browser. The same applies to multiple AJAX/RESTful calls (see fetch() API), which are concurrent by default with no extra work on a developer’s side. Actually, that’s what A stands for in AJAX¹.

So, what’s the advantage of GraphQL?

If a web browser can make concurrent requests to multiple pieces of data at once already, why bother with GraphQL? There are some advantages:

• if you need to make more than the allowed number of concurrent connections (max 2-8, see above), the browser will throttle you anyway, queuing some requests
• GraphQL prevents over-fetching and N+1 problem by returning only properties and relationships you explicitly asked for, not more, not less
• there is just one, batched request. Concurrency happens on the server side. Well, not really…

GraphQL server is not utilizing concurrency by default

The last statement is not true by default, in Java’s implementation of GraphQL server. Remember, we provided a bunch of resolvers for each non-trivial property and relationship. Just as a reminder, this is how our resolver looks like:

@Component
cla