What do you think of GraphQL

GraphQL - a reason to stop?

On December 11th, 2019, Robin Roschlau, co-founder and CTO of the start-up Echometer, whose software relies heavily on GraphQL, was our guest to give his Java User Group Bielefeld lecture entitled "GraphQL - a reason to rest?" to keep. A diverse audience of almost 30 participants came together in a cozy atmosphere over pizza, wine and coke, to listen to Robin's lecture and to answer questions.

The lecture is also available online as a video.

What is GraphQL

It started with the clarification of the question of what GraphQL actually is now. Robin explained that GraphQL is an open source data query and manipulation language as well as a runtime system for carrying out queries on existing databases. It is called efficient and flexible alternative to REST seen. As a stateless query language, it enables clients to define the exact structure of the required data. With this parameterization, GraphQL avoids, in contrast to many other implemented REST interfaces, to transmit unnecessarily large amounts of data with each request. GraphQL interfaces are easy to explore, easy to implement, and flexible - as much as the promise. But what is that all about in detail? How does it all work? What do I have to consider? And of course: is GraphQL really better than REST? These questions were explained in the practical part!

How do you use GraphQL?

At the beginning Robin explained to us the basics of how he defines an interface using GraphQL. Then he showed us how to use a small sample application Implementation of a GraphQL interface can look like.

For GraphQL interfaces, a scheme is first created in which the types, queries and mutations that the interface will later make available are defined. How the individual parts of a query or mutation are resolved is described in what are known as Resolvers Are defined. Depending on the technology, simple resolvers are also automatically implemented.

The user can then run queries on the object graph defined by GraphQL and specify exactly which information is relevant. The GraphQL implementation then parses the query and, depending on the requested data, calls the previously implemented resolver. For example, a query could look like this:

A big advantage of this is that you don't have to do more than is necessary. In addition, downward compatibility is much easier because new fields can simply be added, which are then not returned to the caller if they have not yet been requested.

Robin's example was built in Kotlin with Ktor as the underlying web server, but can be transferred to Java with Spring or other JVM stacks in a very similar way. During the lecture, the participants had the opportunity to throw in questions at any time and after the lecture, Robin was available to answer and deepen further topics.

The time just flew by!

In good company we learned a lot and ate well, and the time passed far too quickly. We would like to thank Robin again for his informative and vivid presentation and look forward to the next time. We are happy to answer any questions or suggestions from you! With this in mind - many thanks to all participants and see you soon!