Interview with Christian Schwendtner

“GraphQL is good, but it’s not an alternative to ‘real’ REST services“

Dominik Mohilo
REST services

Companies like Facebook, GitHub, and Shopify are using GraphQL as an alternative to RESTful Web Services. We talked with Christian Schwendter at MobileTech Conference about both approaches and their differences.

JAXenter: Hello Christian and thank you for taking the time to speak with us. GraphQL is supposed to be something like an alternative to the more traditional approach with RESTful Web Services. Can you briefly describe what exactly GraphQL is?

Christian Schwendter: Hello Dominik, of course, I can do that! GraphQL is primarily a flexible query language. It’s also the first information you’ll receive from the official GraphQL website, titled “A query language for your API“. And this describes GraphQL’s core quite well because its focus is set on the client-side and their data needs, i.e. so that it’s possible to query the required data for clients in a simple and flexible way.

The flexibility, which the client gains in the process, is also the most exciting point in this regard. He can now easily and precisely define which data (including relations) he needs from the server. Thus GraphQL enables a very client-orientated view or rather a very user-case oriented one.  The client can also use a request to load just the required data, which it needs for a use-case or a screen template (no under- or overfetching).

JAXenter: How is GraphQL different from RESTful Web Services?

It’s not the right approach to blindly trust GraphQL to solve every problem.

Christian Schwendtner: I get this question quite often, when people come into contact with GraphQL for the first time. Before answering the question, I would like to point out how I think that it’s important to take a closer look at the term RESTful Web Services. The term is well-defined but often used very inflationary in practice. We like to call any service REST that uses resources, HTTP verbs and HTTP status codes or provides data in JSON. And that’s actually not the case. One should only speak of REST or Restful Web Services when all of the defining criteria are met, which were defined by Roy Fielding, the inventor of REST.

And one important criterion is the HATEOAS or “Hypermedia As the Engine Of Application State”. It’s this HATEOAS which is not at all or not sufficiently implemented in many services, which are supposedly RESTful. There’s a good way to get an understanding of “how RESTful” a service is. And we can make use of the Richard Maturity Model for this distinction.

The model defines different levels depending upon which aspects of REST are implemented. A service, which only matches some criteria of REST (e.g. “only” resources, HTTP verbs, status codes but not HATEOAS) is often called REST-ish, REST-like or REST-wannabe. I am aware of how this does sound. Like splitting hairs, but I think it’s important to be aware of what you are comparing GraphQL to – especially in comparisons with RESTful Web Services.

Talking from experience, GraphQL is a good alternative to the second level of the Richardson Maturity Model (the use of resources, HTTP verbs, status codes), but not a good alternative to “real” REST services (keyword HATEOAS).

A major difference is the mandatory use of a schema. A GraphQL schema defines all types, which can be queried, and all operations, which can be performed (mutations). Due to this build up, it is possible  to check for the query’s correctness at build time of the application.

GraphQL does also offer some interesting concepts – respectively fragments: On the client-side, you can use GraphQL fragments to split a large query into smaller parts. This can be used to define the query of the respective use case (or mask) not at one place, but to define the data requirements per UI component. This has the advantage of data needs being defined where they are best known. A (large) query can then be assembled from the fragments, which contains all data requirements of all components of the respective mask and the required data can then be loaded using a single request.

Another interesting thing about GraphQL are subscriptions. With a subscription, a client can register for an event on the server to be informed about changes (e.g. using WebSockets). This makes it very easy to implement push functionality in applications. You could say that GraphQL is an opinionated approach — that means that certain solutions are provided for certain problems, so you get a complete solution with all advantages and disadvantages.

An indirect weakness of GraphQL is that it’s sometimes advertised as “REST 2.0” or “the better REST”.

JAXenter: What are the weaknesses of GraphQL?

Christian Schwendtner: Many are impressed by the simplicity of defining client-side data needs in GraphQL. But you shouldn’t forget the server side either. Due to the freedom you gain at the client, you often have to invest more thought in the server to avoid running into performance issues.

Since the client can flexibly define its data requirements — in line with the motto “wish for something” — special attention must be paid to performance on the server side. And this should not happen too late in the project.

An indirect weakness of GraphQL is that it’s sometimes advertised as “REST 2.0” or “the better REST”. And I don’t think that’s true. Different things are often compared here. In my opinion, GraphQL is not an alternative for a “real” REST service, but for many REST-ish services, as you often see them. They are more concerned with making data available to the client in a simple and flexible manner.

JAXenter: Let’s say I developed an app which still relies on RESTful Web Services. How hard would it be to upgrade to GraphQL? Is it really doable?

Christian Schwendtner: I think RESTful Web Services and GraphQL can complement each other well. GraphQL can be used as a gateway to give the client a consistent view of the data. The GraphQL gateway wouldn’t load the data then itself (or rather from a database), but call the existing REST endpoints and function as an aggregation point. This way, you could provide a client with the GraphQL flexibility and keep the actual services as RESTful services. This method is also very sensible for microservice architecture.

With the beginning of a new project, you can of course consider working solely with GraphQL. In this case, I would make the decision dependent upon the specific problem. It’s not the right approach to blindly trust GraphQL to solve every problem.

JAXenter: Do you have any advice for developers who are interested in GraphQL?

Christian Schwendtner: GraphQL is an interesting approach, but not a panacea to all our problems. And we tend to look quite often for this kind of solution. We forget to deal with the one specific problem.

And suddenly we end up at that point where “We had a solution, but it didn’t fit the problem”. I think that using GraphQL can be very useful, but it isn’t a magically fix for our problems. During your daily work as a developer or architect, you will have to make decisions for a technology quite often. And sometimes it’s important to make a well-founded decision against a technology, even if this isn’t as frequent. Always keep this in mind and don’t forget it.

JAXenter: Thank you!

Dominik Mohilo
Dominik Mohilo studied German and sociology at the Frankfurt University, and works at S&S Media since 2015.

Inline Feedbacks
View all comments