3 ms·
are you mixing command and query together in one request? i thought it is a bad practice. mutating data is command and is a separate request and fetching custo
by slt2021 5y ago
are you mixing command and query together in one request? i thought it is a bad practice.
mutating data is command and is a separate request and fetching customer details is another request
- chrismorgan 5y agoOn the contrary, for remote APIs like this having commands return the resulting state is the only sane path; otherwise you get mandatory inefficiency (doubling latency) and race conditions.
- joshribakoff 5y agoCQRS doesn’t obviate race conditions. Especially if multiple commands can be in flight at the same time (the response can still be received out of order), or if there are multiple clients mutating the same resource.
- chrismorgan 5y ago> CQRS doesn’t obviate race conditions. I think you may be talking at cross purposes with me here. I’m saying that command–query separation¹ causes race conditions. Having the mutating API return state is the only way to obtain the value of the resource at the time of mutation. — ¹ CQS; CQRS, where you use different representations for command and query, is not necessarily applicable here.
- joshribakoff 5y agoYes you’re right. I meant to write that abstinence from CQ[R]S doesn’t prevent race conditions.
- joshribakoff 5y agoIt’s not bad practice. CQRS is just a pattern with pros and cons.
- manigandham 5y agoCommand and Query is really just named that in CQRS, which is specifically a pattern that splits read/write into separate traffic paths. It's not the only way to do things, and I find it usually isn't that great in practicality.