Conversations about Software Engineering

Conversations about Software Engineering (CaSE) is an interview podcast for software developers and architects about Software Engineering and related topics. We release a new episode every three weeks.

Artur Ortega on GraphQL

Download it: MP3 | AAC | OGG | OPUS

In this episode, Artur Ortega explains to Stefan Tilkov what GraphQL is, how it came to be, and how it differs from REST. Predictably, the two debate whether it’s better or not, but also spend some time going over its technical details and applicability to different usage scenarios.

Read transcript

Show Notes


by Stefan Tilkov on
Thank you for the comment; unsurprisingly, I agree :)
by Simon Zambrovski on
Great discussion, thank you. I think the discussion about API design depends on how your architecture is designed. If you follow DDD principles and create REST APIs for different bounded contexts, there should be no "references" from one domain to another, at least not one, you want to navigate. If you use the GraphQL as an adapter on top of your application, you will loose track of who is using your API and what for. The cross-context requests will be hidden in the GraphQL GW and will hide the need for a change in the implementation. In case you have the same concept represented differently in different bounded-contexts, you will even get more integration problems. I think this is my main problem with the "federeation" explained by Artur. But I agree, given a bad-designed REST API, exposing CRUD operations of (Database) entities instead of resources, a technology like GraphQL might help you to create a solution, which is not possible at all. The main scenario I see in usage of GraphQL is then an integration technology to a framework / generic tool, which provide you access to data and allows you to built new applications using functionality and composing them for a new purpose. If you have a clear purpose - you should focus on your domain, define the REST API following the requirements from it and there should be no reason to introduce complexity of GraphQL. Cheers, Simon

New comment

By submitting your comment you agree that the content of the field "Name or nickname" will be stored and shown publicly next to your comment. Using your real name is optional.