Skip to main content


Showing posts from October, 2019

GraphQL server in Java: Part II: Understanding Resolvers

In part I we developed a really simple GraphQL server. That solution has a serious flaw: all fields are loaded eagerly on the backend, even if they weren’t requested by the front-end. We sort of accept this situation with RESTful services by not giving clients any choice. RESTful API always returns everything, which implies always loading everything. If, on the other hand, you split RESTful API into multiple smaller resources, you risk N+1 problem and multiple network round trips. GraphQL was specifically designed to address these issues: fetch only required data to avoid extra network traffic as well as unnecessary work on the backend allow fetching as much data as needed by the client in a single request to reduce overall latency RESTful APIs make arbitrary decision how much data to return, therefore can hardly ever fix the aforementioned issues. It’s either over- or under-fetching. OK, that’s theory, but our implementation of GraphQL server doesn’t work this way. It still f

GraphQL server in Java: Part I: Basics

Near Zegrzyńskie Lake Superficially, there is no reason GraphQL servers are typically written in Node.js. However callbacked-based languages that don’t block waiting for the result turn out to play really well with GraphQL philosophy. Before we dive into details why that’s the case, let us first understand how GraphQL server works underneath and how to implement it correctly. In the second installment we shall split the implementation to lazily load only necessary pieces of information. In the third installment we shall rewrite the server using non-blocking idioms to improve latency and throughput. What is GraphQL First things first, what is GraphQL? I’d say it lies somewhere between REST and SOAP (sic!) It’s a fairly lightweight, JSON protocol that works best for browsers and mobile apps. Just like REST. On the other hand it has a schema, describing valid attributes, operations and payloads. However, unlike SOAP, schema is designed to evolve and we have a great control over th