Conversations about Software Engineering

Thank you for the comment; unsurprisingly, I agree :)

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