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

Cheers,

Andi

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’t 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’t do it all ourself.

The last reason is personal and it is about fun. I don’t 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’t. We follow some rules about breaking changes:

• We never take a functionality away. We deprecate things and make it clear that we don’t really support them anymore, but we don’t 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’t wanna discuss it in public you can also reach us via contact form.

Cheers,

Andi

We have two exciting changes to announce:

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 https://spectrum.chat/graphql-java. 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.

We are also moving our documentation from readthedocs to our own page at graphql-java.com/documentation.

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.

Cheers,

Andi

Soon after I started started GraphQL Java (almost 3 1/2 years ago) other people started building libraries on top of it. I was happy to welcome them into the GraphQL Java Github organization, because it was great to see the GraphQL Java ecosystem grew and centralizing these projects into one org made sense.

Fast forward to today: the core library graphql-java is maintained by myself and my co-maintainer Brad, but we are not involved in graphql-spring-boot and other projects. They are independently released and organized without any involvement from us. This leads to confusion from our users and makes it hard to recognize what actually the Graphql Java project is and what are libraries build on top without any involvement from Graphql Java.

In order to clear up this confusion we have decided to move these projects or to archive them:

• graphql-spring-boot is moved to https://github.com/graphql-java-kickstart/graphql-spring-boot
• graphql-java-tools is moved to https://github.com/graphql-java-kickstart/graphql-java-tools
• graphql-java-servlet is moved to https://github.com/graphql-java-kickstart/graphql-java-servlet
• graphql-java-annotations is moved to https://github.com/Enigmatis/graphql-java-annotations
• graphql-java-type-generator is archived and in read only mode: https://github.com/graphql-java/graphql-java-type-generator/

I wanna make clear that these projects are valuable and successful projects and moving them out of the GraphQL Java Github organization is done to reduce confusion as described above.

Cheers,

Andi

Welcome to the new GraphQL Java Homepage: the central page about everything GraphQL Java.

It is still a work in progress and we will continue improving this page over time.

Cheers,

Andi