When GraphQL meets MicroProfile

After a year of actively observing the transition from Java EE to Jakarta EE (including several conferences I have given on the subject), I’ve decided to get more concretely involved in 2019. I’ve taken the opportunity to participate to the MicroProfile GraphQL initiative.

In this blog post I’m going to explain how the group started, what are the challenges and what will be the next steps.

Things started by a discussion initialized by Phillip Kruger on the Eclipse Microprofile Google Group. Phillip is a well-known and active contributor to the Open Source Java ecosystem. Has has already produced a demo project  showcasing how to use GraphQL in a Java EE context.  He is also contributor to the Extensions for MicroProfile project. A few others have joined the group including Andy McCright from IBM (acting as the project lead) and we are lucky to benefit from the support of Bojan Tomic,who is the main contributor to GraphQL SPQR project. As we will see, GraphQL SPQR is the main source of inspiration of what we want to achieve.

 

What is GraphQL?

GraphQL is an open-source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data. It provides an alternative, though not necessarily a replacement for REST.

GraphQL was developed internally by Facebook in 2012 before being publicly released in 2015.

On 7 November 2018, the GraphQL project was moved from Facebook to the newly-established GraphQL foundation, hosted by the non-profit Linux Foundation. This is a significant milestone in terms of industry and community adoption. GraphQL is used by many large and small companies including Atlassian, Coursera, Facebook, GitHub, PayPal, Twitter, and many more.

I’ve discovered GraphQL a few months ago with the excellent GraphQL Java tutorial introduction from Bojan Tomic. Based on a simple use case, it demonstrates the capabilities of GraphQL in general and of graphql-java in particular. I’ve been impressed by the flexibility from a client perspective. Thanks to a powerful query language and a schema describing the available data and the operations, it enables the client to interact with the server in a very flexible and precise way asking for just the needed data. This is a great advantage, especially for the development of mobile applications.

 

How is MicroProfile going?

Eclipse MicroProfile was started in summer 2016 as a reaction to the slow pace of Java EE development. Since then, it has become an Eclipse project and has already produced 8 releases. The most recent one is 2.1 delivered in Q4-2018. 3 releases are planned in 2019: 2.2 (Feb 2019), 2.3 (Jun 2019) and 2.4 (Oct 2019).

The official purpose of MicroProfile is to optimize Enterprise Java for a microservices architecture and delivers application portability across multiple MicroProfile runtimes.

Concretely, it proposes features to develop state-of-the-art microservices and cloud-native applications: external configuration, fault tolerance, health check, JWT, metrics, OpenAPI, Open Tracing, Rest Client. These features are implemented by server runtimes such as Open Liberty, Payara, Thorntail, and TomEE.

 

What about Jakarta EE?

Jakarta EE is the new brand name for the future of Java EE. It is backed by the Eclipse EE4J project. In fact EE4J, it is a top-level project made of 39 projects. Most of 2018 has been dedicated to the transfer from Oracle Java EE to Eclipse EE4J as described by Dmitry Kornilov.

A major milestone to mark this transition has been achieved with the release of Eclipse GlassFish 5.1 mi-december 2018.

To ensure the future of the Jakarta EE platform, and to replace the Java Community Process, Eclipse has defined a new specification process  named EFSP (Eclipse Foundation Specification Process).

The first project to follow it will be Jakarta EE NoSQL which will leverage the existing Eclipse JNoSQL project as described by Otavio Santana. The goal of this specification is to ease integration between Java Applications and NoSQL databases, with a common API to work with different types and vendors of NoSQL databases.

Maybe a small clarification is needed here before going further : NoSQL is about databases while GraphQL is a about APIs. The facts that there are graph-oriented NoSQL databases such as Neo4j and that some NoSQL databases such as ArangoDB proposes a native GraphQL API doesn’t simplify the overall understanding …

 

Jakarta EE vs MicroProfile?

There is a strong connection between MicroProfile and Jakarta EE, they are both Eclipse projects and are backed by the same community (including IBM, Red Hat, Payara, TomiTribe and Oracle). To make a long story short, MicroProfile can be seen as an incubator for Jakarta EE. It proposes specifications in a very dynamic way and some of them are expected to be part of the Jakarta EE platform. May be, it will be appropriate to merge the two projects when Jakarta EE reaches maturity, but for the time being, it is better to keep them separate.

 

A short introduction to SPQR

SPQR stand for Schema Publisher and Query Resolver. It fits very well with the context of MicroProfile by proposing a code-first approach (vs schema-first approach) based on a set of Java annotations.

When the application is started, a schema is automatically generated from these annotations. The structure of the schema is then available at a given URL (suffixed by schema.json) and an introspection tool such as GraphIQL can be used to discover and test it.

Following a code-first approach with a strongly and statically typed language such as Java proves to be highly productive. You do not have to maintain both the Schema Domain Specific Language and the Java code.

Technically, SPQR is a layer on top of graphql-java. It is an alternative to graphql-java-tools which enables to follow the schema-first approach.

To put it in action and to increase my knowledge, I’ve decided to reshape the above mentioned GraphQL Java tutorial introduction. I will publish it on GitHub ASAP. On the plus side, I’ve appreciated its ease of use (just a few annotations makes the deal, no need to implement or extend any specific class or interface). On the minus side, I have suffered from the lack of documentation. Discovering both the subtleties of GraphQL and SPQR at the same time has been a challenge.

But in the end, SPQR is clearly a good starting point for what we want to achieve in MicroProfile.

 

Next steps

We have to finalize our proposal and get the approval of the MicroProfile Board to officially become a MicroProfile project.

If accepted, it will then evolve as a standalone specification. The next objective is to be part of one of the above mentioned MicroProfile releases.

Before that, there are many challenges ahead of us:

• How to manage the transport? Even if widely used with HTTP, GraphQL is independent of any transport layer. Moreover, MicroProfile has no direct dependency on the Servlet specification. In that context, it is important to define the exact scope of MP GraphQL, but it is of equal importance to define how it can concretely be used with HTTP,
• How to enforce the integration with the MicroProfile stack? In particular by removing dependencies on external libraries. For instance, by using JSON-P and JSON-B instead of proprietary libraries,
• How to properly manage GraphQL subscriptions using Server Sent Event or WebSocket?
• How to implement GrapqhQL Unions?
• How to improve the developer experience in general? Using GraphQL should be as easy to do as using REST with JAX-RS, with just a few annotations, a good CDI integration, and a good doe of “convention over configuration”.

To illustrate the ease-of-use of the programming model we have in mind, here are 2 code snippets:

No doubt that there are many other challenges ahead of us … But working on such a project is a great opportunity for me and my company Worldline to contribute and influence the specification. If you’re interested you can also be part of the story, just show up in the Eclipse Microprofile Google Group. You will be welcome!

With NoSQL and GraphQL in sight, the “future of Java EE” is on track!