4 ms·

Killing the Command message: should we use Events or Documents? (2007)

36 points by laerus 5y ago

davidshepherd7 5y ago
Is it just me or are all the diagram links broken? It's pretty hard to understand without them.
- farhaven 5y ago
  Yep, getting a bunch of 404 for the pictures here
svilen_dobrev 5y ago
https://docs.microsoft.com/en-gb/archive/blogs/nickmalik/killing-the-command-message-should-we-use-events-or-documents https://docs.microsoft.com/en-gb/archive/blogs/nickmalik/kil... some old copy
- aisamu 5y ago
  This one has all the diagrams, thank you!
cmrdporcupine 5y ago
I feel like in the last 10 years there's been a (mostly unconscious) swing from "document" or "resource" oriented modeling in APIs back to RPC type "command" APIs; due in large part to the new popularity and ubiquity of distributed RPC systems like gRPC (or Thrift, etc.) The "REST" trend crested, and RPC came back with a vengeance. Or people just abused RESTful appearances but pasted command and remote-call semantics in overtop of it. I still think that extensive use of RPC on the Internet has the problem of (deliberately) giving the application developer the illusion that the world of the remote and the local are in the same "system", thereby hiding the intrinsic problems of reliability and latency with communicating over a socket. I feel like this is maybe why a lot of systems that should "know better" fall down when they lose good network connectivity (looking right at you, Android Auto): the developer has not been forced to think about failure conditions because the framework fooled them into thinking that accessing the remote resource was semantically the same as accessing a local resource. That's my rant about this topic, anyways.
weeksie 5y ago
I'm not convinced. Should we use command messages like rpc calls? No. But the category of command message makes sense. A command might fail. Only events are saved to the log. I think the separation of commands into ephemeral requests that may or may not result in new events on the log is a very reasonable distinction.

36 points by laerus 5y ago

davidshepherd7 5y ago

Is it just me or are all the diagram links broken? It's pretty hard to understand without them.

farhaven 5y ago
Yep, getting a bunch of 404 for the pictures here

svilen_dobrev 5y ago

https://docs.microsoft.com/en-gb/archive/blogs/nickmalik/killing-the-command-message-should-we-use-events-or-documents https://docs.microsoft.com/en-gb/archive/blogs/nickmalik/kil... some old copy

aisamu 5y ago
This one has all the diagrams, thank you!

cmrdporcupine 5y ago

I feel like in the last 10 years there's been a (mostly unconscious) swing from "document" or "resource" oriented modeling in APIs back to RPC type "command" APIs; due in large part to the new popularity and ubiquity of distributed RPC systems like gRPC (or Thrift, etc.) The "REST" trend crested, and RPC came back with a vengeance. Or people just abused RESTful appearances but pasted command and remote-call semantics in overtop of it. I still think that extensive use of RPC on the Internet has the problem of (deliberately) giving the application developer the illusion that the world of the remote and the local are in the same "system", thereby hiding the intrinsic problems of reliability and latency with communicating over a socket. I feel like this is maybe why a lot of systems that should "know better" fall down when they lose good network connectivity (looking right at you, Android Auto): the developer has not been forced to think about failure conditions because the framework fooled them into thinking that accessing the remote resource was semantically the same as accessing a local resource. That's my rant about this topic, anyways.

weeksie 5y ago

I'm not convinced. Should we use command messages like rpc calls? No. But the category of command message makes sense. A command might fail. Only events are saved to the log. I think the separation of commands into ephemeral requests that may or may not result in new events on the log is a very reasonable distinction.