Skip to main content

· 3 min read
Donna Zhou

We are very proud to celebrate 10 years of GraphQL Java!

What started as a little hobby project has become an industry standard.

We want to express our sincere thanks to the GraphQL Java community, the 250+ code contributors and countless more who created issues and participated in discussions. Thanks to all volunteers who helped make GraphQL Java better!

Now we’d like to share fun stories about the last 10 years.

How we came to the library

Andi's story

I was working at a small company which used a REST(ish) API for their web app. This API evolved and had a lot of typical features added on top of rest like field selection, sub selections etc. to make it performant and practical useable. When a colleague pointed me to the imminent release of a new protocol called “GraphQL” by Facebook I was immediately convinced of its value because: it solved the API problems we had on a fundamental level.

I sat down for a week or so and invested all my free time to come up with the first version of GraphQL Java as quick as possible. Very quickly after I released a version 0.1 I already got a first contributor and user. (The) REST is history 🙂

Brad's story

I was an architect at Atlassian on the Jira Service Desk product (now JSM) and we were embracing dynamic UIs driven by having more data called via browser calls. If you don't know what jQuery and AJAX is - just trust me, it was cool in its time.

We invented a REST endpoint nicked named The Smoosher - you made a call and we just smooshed all the data you need to paint the JSD portal screens. It worked but it clearly broke all the RESTian orthodoxy around resources and state and other networking dogma.

I started looking into GraphQL as a more architectural technique for getting the data you need for a dynamic UI. As we had a JVM back end, I started to look into graphql-java.

My first PR was adding the Instrumentation classes that kinda still exist today (albeit in a more efficient form). graphql-java became an after-work hobby to keep my hand in at coding (architects are always drawn away from coding towards the dark side called a rich text editor and eventually Keynote / Powerpoint)

Donna's story

I started a new job on the same team as Andi and Brad. At the time, GraphQL was completely new to me, yet I knew I had to learn pretty quickly for the job! I like to learn by coding, so I picked a few bug tickets to give me a goal to aim for. Andi and Brad patiently explained concepts and reviewed my PRs (and still do!), making the whole experience much less daunting.

Contributing to GraphQL Java was easily the best decision I’ve made in my career. I was hooked from my first PR, kept contributing, and things snowballed from there. Soon I became a maintainer, and a dream came true when Andi and I published a book together, GraphQL with Java and Spring.

Cheers to many more years of GraphQL Java 🍻 Later this year we’ll be speaking at GraphQL Conference 2025, see you there!

· One min read
Donna Zhou

We are pleased to announce the release of graphql-java v24.0.

This release is an unexpected breaking change release. It was made to help propagate a fix in the DataLoader library.

We consider v23.x poisoned and we don't recommend you use it because of the latent bug explained in the release notes on GitHub.

Going forward we will not be supporting v23.x, instead please skip this series and use v24.x going forward.

· One min read
Donna Zhou

Update: please use the v24 series of releases instead of v23 releases. We have made a clearer breaking change in Java DataLoader, thus we will discontinue v23.

We are pleased to announce the release of graphql-java v23.0! Thanks to everyone in the community who contributed to the release, whether that was code, helping to report issues, or participating in discussions.

This is a breaking change release. Included are performance improvements and features.

For the full details, please see the release notes on GitHub.

· 2 min read
Andreas Marek

GraphQL Java has become a mature and widely adopted library over the past 9.5 years. And while we continue to maintain, improve and add features, we don't expect revolutionary changes to the core of the library.

As side effect of this maturity it became clear over the least years, that performance is a key aspect that users are interested in. Especially in larger scale applications performance can have a huge impact on operational costs and user experience.

In GraphQL Java we leverage JMH aka Java Microbenchmark Harness to measure and compare different performance aspects.

Historically, performance testing was done manually by running JMH benchmarks on a local machine.

This comes with the obvious flaw that it's not reproducible over time and across different machines. A benchmark run on one developer's machine is not comparable to a run on another developer's machine (or often even the same machine months later).

We are very happy to share that we have now an automated performance testing setup in place to overcome these limitations by running the benchmarks in an isolated cloud environment.

Currently, it runs on every commit to the master branch and the results are stored in the
performance results folder. You can visualize and compare results with the JMH Visualizer tool, a free tool which runs in the browser. Our goal is to provide clear and reproducible performance improvements over time while preventing any regressions.

This work is sponsored and made possible by Atlassian and we are very grateful for their support.