Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

CQRS commands and GraphQL mutations

Tags:

cqrs

graphql

I've just learned about CQRS, and I would like to combine it in a project with a GraphQL based API. However, in order to do that, a question has come to my mind: according to CQRS, commands have to not return anything after its execution. However, according to GraphQL conventions, mutations have to return the updated state of the entity.

How should I deal with that? Are CQRS and GraphQL incompatible? The only solution that comes to my mind is, in order to resolve the mutation, first execute a command and later a query, in order to get the response object. Is there anything better than that? It doesn't look very efficent to me...

Thanks in advance

like image 712
pitazzo Avatar asked Jul 20 '20 15:07

pitazzo


People also ask

Does GraphQL use CQRS?

CQRS might sound scary at first, but in its essence, it's a quite simple concept: it separates read and write data model. GraphQL makes a strong distinction between input and output object types, which must be defined separately. This makes it perfectly compatible with the CQRS concepts.

What is the difference between mutation and query in GraphQL?

About GraphQL mutationsWhile we use queries to fetch data, we use mutations to modify server-side data. If queries are the GraphQL equivalent to GET calls in REST, then mutations represent the state-changing methods in REST (like DELETE , PUT , PATCH , etc).


2 Answers

How should I deal with that?

Real answer? Ignore the "have to not return anything" constraint; the underlying assumptions behind that constraint don't hold, so you shouldn't be leaning to hard on it.

How exactly to do that is going to depend on your design.

For example, if you are updating the domain model in the same process that handles the HTTP Request, then it is a perfectly reasonable thing to (a) save the domain model, (b) run your view projection on the copy of the model that you just saved, (c) and then return the view.

In other words, the information goes through exactly the same transformations it would "normally", except that we perform those transformations synchronously, rather than asynchronously.

If the model is updated in a different process, then things get trickier, since more message passing is required, and you may need to deal with timeouts. For instance, you can imagine a solution where you send the command, and then poll the "read side" until that model is updated to reflect your changes.

It's all trade offs, and those trade-offs are an inevitable consequence of choosing a distributed architecture. We don't choose CQRS because it makes everything better, we choose CQRS because it makes some things better, other things worse, and we are in a context where the things it makes better are more important than the things it makes worse.

like image 156
VoiceOfUnreason Avatar answered Oct 19 '22 10:10

VoiceOfUnreason


I am considering similar, i.e. using GraphQL predominantly for interfacing with the read-side of a system based on CQRS.

On the write-side, however, I am considering using a Web or REST API that has one end-point that accepts commands.

Remember, in CQRS you don't directly mutate entities but submit a command signalling your intent / desire to do something.

Alternatively, thinking out loud here, it may be possible to use mutations in GraphQL to create commands and track their status using subscriptions.

like image 21
Ashley Aitken Avatar answered Oct 19 '22 08:10

Ashley Aitken