Skip to main content

One min read
Andreas Marek

We are happy to release the first version of the GraphQL Java Spring (Boot) project.

As described before this project complements the GraphQL Java core project if you build a fully operational GraphQL server with Spring.

Currently it supports GET and POST requests and allows for some basic customization.

In future we are looking into supporting more advanced features like file upload or subscriptions.

As always contributions are more than welcome and we are hoping to grow this project together with the community: please open a new issue or leave a comment on spectrum chat about your wishes.

More details on how to use it can be found on the github page:

One min read
Brad Baker

One of the most common questions we get in GraphQL Java land is "can we have a datetime scalar".

This is not defined by the graphql specification per se so we are reluctant to add it to the core library and then have it turn up later as an officially specified type.

But it really is a badly needed type in your GraphQL arsenal and hence graphql-java-extended-scalars was born

This will be a place where we can add non standard but useful extensions to GraphQL Java.

The major scalars we have added on day one are

  • The aforementioned DateTime scalar as well as a Date and Time scalar

  • A Object scalar or sometimes know as a JSON scalar that allows a map of values to be returned as a scalar value

  • Some numeric scalars that constrain the values allowed such as PositiveInt

  • A Regex scalar that allows a string to fit a regular expression

  • A Url scalar that produces objects at runtime

  • And finally an aliasing technique that allows you to create more meaningfully named scalar values

    We hope you find them useful.



2 min read
Andreas Marek

There seems to be a common misconception about GraphQL Java: that you should not use it directly, but rather use another library build on top of it.

We think it is important to make it clear, that this is not the case: GraphQL Java aims to be a library used directly without any additionally abstraction on top. It was always build with this goal in mind.

To be fair: we didn't do a very good job so far to make that clear. For example up until recently we hosted several other projects which provided abstractions on top of GraphQL Java. This was because of historical reasons and we didn't give any guidance on when to use what. There are also currently more tutorials out there which don't use GraphQL Java directly compared to tutorials which do.

The other reason people might think that GraphQL Java is not suitable is because the core project doesn't provide any easy way to get a full service with HTTP endpoint up and running. And the existing third party projects providing for example Spring Boot support are adding abstractions.

The core project doesn't deal with any form of HTTP or JSON specific things and has on purpose basically no dependencies at all. This will not change, but we recognize the need for having an easy way to get a full service up and running. This is why we are currently working on first class Spring (Boot) support.

This is not done yet, but it will provide an easy way to integrate GraphQL Java in a Spring (Boot) application without adding any abstraction on top of GraphQL Java. It will also be extended over time with more advanced features like Apollo Defer support.

To recap:

  1. GraphQL Java aims to be a first class library used directly
  2. The GraphQL Java core project doesn't deal with HTTP/JSON and will continue not do it
  3. The GraphQL Java Spring project will complement the core project in providing comprehensive Spring (Boot) support



3 min read
Andreas Marek

We are releasing new major versions of GraphQL Java roughly every 2 months. They are major versions because we break the API in it. We do it regularly and we prioritize clean code including good naming and design very high. Actually higher than API stability.

We do that because we are optimizing for long-term growth: GraphQL Java is 3 1/2 years old and it is just getting started. This means more people will be positively affected from a better experience compared to the ones who need to refactor.

We do it also because of resource constraints: we are an open source private run project with limited time and resources. We can鈥檛 afford maintaining a badly designed project in the long-term. Every bad design, every bad naming makes adding features and adopting to new requirements harder, more time consuming and more unlikely. We also want to make external contributions as easy as possible because we can鈥檛 do it all ourself.

The last reason is personal and it is about fun. I don鈥檛 wanna maintain a badly designed project. I need to have fun if I wanna continue to invest a large amount of private time in GraphQL Java.

Does that mean we just refactor as crazy and break everything all the time? No it doesn鈥檛. We follow some rules about breaking changes:

  • We never take a functionality away. We deprecate things and make it clear that we don鈥檛 really support them anymore, but we don鈥檛 take them away without a clear alternative.

  • We try to favor simple breaking changes the compiler will catch. For example renaming a method is such a simple change.

  • We try to document in our release notes every breaking change clearly.

  • Even if we prioritize clean design higher than API stability in general we always weigh the benefits of the change vs the cost of adapting to it. There is no hard rule to that, but we always ask: is it worth it?

But we understand that not every Organization allows for regular updating major versions of GraphQL Java. This is why we started to maintain a Long-term support (LTS) version of GraphQL Java: 9.x. We will continue to back port all bug fixes to 9.x for some time and we will announce when we will switch to a new LTS version.

It is not clear yet how long this time span will be and it depends also on your feedback. Please contribute to this spectrum thread and let us know what suits you best. If you have special needs and you don鈥檛 wanna discuss it in public you can also reach us via contact form.



One min read
Andreas Marek

We have two exciting changes to announce:

New support channel at spectrum

We are moving our support channel from gitter to spectrum. Gitter served us well over the years, but with more and more people using GraphQL Java we are looking for better ways to support our community and we think spectrum is the right place to do that. Especially the Threads oriented view compared to one chat room is something we are looking forward to.

Please ask new questions at We will stop answering questions in the gitter room and direct people to spectrum. The gitter room will be closed in a couple of weeks.

New documentation home

We are also moving our documentation from readthedocs to our own page at

While the the new documentation is currently similar to the old one the layout is already an improvement and code examples are much easier readable than before. We are planning more improvements over time.