This week, we had the opportunity to interview Nils Hartmann, a highly knowledgeable API expert who wants to spread know-how about GraphQL, how its query language works, and the best time to use it. On February 16, 2023, he will be one of the speakers at a live event API Day on devmio, where he will share his insights about GraphQL APIs, their uses, and their limitations, gained from his years of hands-on experience. Here’s what he told us and what you can expect from the live event.

devmio: Hello Nils, thank you for taking the time to answer our questions. What are the distinguishing features of GraphQL? What is the API concept behind it?

Nils Hartmann: GraphQL APIs provide data in the form of an object graph that the client can use to read or write the necessary data with its own query language. A schema describes what the specific object graph of an application or API looks like. This defines the domain-oriented objects, their fields, and the relationships between them. For all fields, a type is also specified in each case so that the API is type-safe.

Contrary to what you may sometimes read, GraphQL doesn’t offer all application data in a lump sum and doesn’t provide the client with a complete database. Just as with other API technologies, an application’s GraphQL API can be modeled according to your own requirements and needs. Comparing it to SQL also isn’t very accurate, since SQL is much more flexible than GraphQL and comes with more features out of the box.

Contrary to what you may sometimes read, GraphQL doesn’t offer all application data in a lump sum and doesn’t provide the client with a complete database.

devmio: What are some example use cases for GraphQL APIs?

Nils Hartmann: GraphQL APIs make sense especially if there are several different clients for an application or its API where completely different views or interfaces need to be built. These can be internal or external applications. For example, GitHub and GitLab provide GraphQL APIs so developers can integrate their services into their own applications and tools. Another example is when a public transportation company provides data on timetables and stops so that other applications can integrate them. GraphQL can fully show its strengths here. Due to the query language’s flexibility, completely different types of clients can select their required data themselves. The mandatory schema description with documentation and types makes it easy for developers to get to know and understand even new or unknown APIs. GraphQL’s type system and the tooling based on it ensure that formulated queries actually work.

In particular, I find the type system so helpful. I would also consider GraphQL for scenarios where there may be only one client, but there is a complex API.

devmio: In which scenario would you prefer GraphQL over REST?

Nils Hartmann: REST APIs are even more widespread than GraphQL APIs and accordingly, knowledge about it is also much more widespread. So it’s easier to find developers for these APIs. This could be a criterion for REST. If you want to provide a public API and make the barrier to entry as low as possible (maybe there’s a lot of competition or potential customers are not willing to use GraphQL), it certainly also makes sense to provide a REST API. By the way, the two API technologies can also be used together in principle.

GraphQL APIs make sense especially if there are several different clients for an application or its API where completely different views or interfaces need to be built.

devmio: On Feb. 16, you'll be hosting a live event titled “GraphQL - What is it All about? Fundamentals, Concepts and Use-cases of the API Query Language” here on devm.io. What core ideas do you want to convey in your live event?

Nils Hartmann: I want to teach the basics and most important ideas of GraphQ. In general, I will cover: what is the schema, how does the query language work, and what is GraphQL’s type system? When do GraphQL APIs make sense? What are the limits of GraphQL? Furthermore, I would like to clear up some misunderstandings that are circulating about GraphQL.

devmio: What does the future hold for GraphQL? What are your visions for the future?

Nils Hartmann: Implementing and offering a GraphQL API often requires connecting and merging a whole range of services, databases, and other sources. This can be a challenge in distributed architectures. In this area, there are currently a lot of ideas and experiments on how to make it easier to provide GraphQL APIs. One example is declaratively integrating existing (REST or GraphQL) APIs into a GraphQL API. Until now, there have been individual approaches, products, and tools, but no standard or something similar. I could imagine that there will be some exciting developments in this area.