Re:The Idempotency-Key HTTP header field
by chrismorgan on Sunday July 04, 2021 @12:53PM
(#27730999)
On 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.
[ Parent
| on HN ]
Re:The Idempotency-Key HTTP header field
by joshribakoff on Sunday July 04, 2021 @01:20PM
(#27731172)
CQRS 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.
Re:The Idempotency-Key HTTP header field
by chrismorgan on Sunday July 04, 2021 @01:31PM
(#27731237)
> 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.
Re:The Idempotency-Key HTTP header field
by joshribakoff on Sunday July 04, 2021 @04:04PM
(#27732215)
Yes you’re right. I meant to write that abstinence from CQ[R]S doesn’t prevent race conditions.