4 ms·

Sending messages asychronously and not knowing who (or even if anyone) will handle it is pretty desirable. Like a holy grail of writing maintainable software.

by latch 7y ago

Sending messages asychronously and not knowing who (or even if anyone) will handle it is pretty desirable. Like a holy grail of writing maintainable software. (think of async communication via a queue) Isn't always possible, but it's worth the constant vigilance to drive each feature towards that type of architecture.

kstenerud 7y ago
OK, I must be missing something fundamental, then. Let's say you want to take payment and ship a product. You send a message that payment of X is needed. And... nothing happens because the component that handles that isn't listening for whatever reason. Do you wait for a message saying payment was posted? How long do you wait? What about the UI? How long does the customer wait? It seems like a messaging system like this would require all calling components to micro-manage anything they're calling, to make sure things actually get done...
- megous 7y ago
  Message sending function can block until timeout or response is received.
  - tomaskafka 7y ago
    How is timeout and sending message without knowing how it was handled different?
    - megous 7y ago
      Have you programmed anything on the web? fetch() has interface just like that.
- tybit 7y ago
  I like pub sub for sending events(where the sender doesn’t expect any responses). I dislike it for modelling RPC which is what you seem to be referring to.
- rswail 7y ago
  If I'm the service that needs a payment, then it is up to me to make sure it happens. If it doesn't, then I need to deal with that, because that's something that can happen with a payment. So if I don't hear from the payment that it has been initiated, then I have to go on the basis that I can't get a payment. But I also don't get to tell the payment how to deal with its internal activities, I don't want to know about it retrying, or working out which payment provider to use etc. Objects arent FiniteStateMachineManagerFactories. They're actual things that your system is built to handle. If an object needs an FSM, it'll get one, just like cells have mitochondria.
- zeugmasyllepsis 7y ago
  > It seems like a messaging system like this would require all calling components to micro-manage... I think that's part of the trick, actually. When every component of a system behaves in similar ways, it's easier to extract that behavior into re-usable patterns. Rather than each component worrying about handling failure and micromanagement, that job is delegated to an another component, a supervisor or orchestrator. Supervision trees, automatic service discovery, and elastic resource managers all come to mind. What payment systems don't send messages to communicate with the credit card company, or the eCheck service, or Venmo/PayPal/Apple pay? Websites and native apps alike have spinning graphics and loading bars, messages that say "please don't refresh the page while we do this". These systems are fundamentally asynchronous to begin with. By uniformly applying the practices you get consistency, in exchange for a higher low-bar of complexity (which you're likely to exceed anyway).

by latch 7y ago

kstenerud 7y ago

OK, I must be missing something fundamental, then. Let's say you want to take payment and ship a product. You send a message that payment of X is needed. And... nothing happens because the component that handles that isn't listening for whatever reason. Do you wait for a message saying payment was posted? How long do you wait? What about the UI? How long does the customer wait? It seems like a messaging system like this would require all calling components to micro-manage anything they're calling, to make sure things actually get done...

megous 7y ago
Message sending function can block until timeout or response is received.
- tomaskafka 7y ago
  How is timeout and sending message without knowing how it was handled different?
  - megous 7y ago
    Have you programmed anything on the web? fetch() has interface just like that.
tybit 7y ago
I like pub sub for sending events(where the sender doesn’t expect any responses). I dislike it for modelling RPC which is what you seem to be referring to.
rswail 7y ago
If I'm the service that needs a payment, then it is up to me to make sure it happens. If it doesn't, then I need to deal with that, because that's something that can happen with a payment. So if I don't hear from the payment that it has been initiated, then I have to go on the basis that I can't get a payment. But I also don't get to tell the payment how to deal with its internal activities, I don't want to know about it retrying, or working out which payment provider to use etc. Objects arent FiniteStateMachineManagerFactories. They're actual things that your system is built to handle. If an object needs an FSM, it'll get one, just like cells have mitochondria.
zeugmasyllepsis 7y ago
> It seems like a messaging system like this would require all calling components to micro-manage... I think that's part of the trick, actually. When every component of a system behaves in similar ways, it's easier to extract that behavior into re-usable patterns. Rather than each component worrying about handling failure and micromanagement, that job is delegated to an another component, a supervisor or orchestrator. Supervision trees, automatic service discovery, and elastic resource managers all come to mind. What payment systems don't send messages to communicate with the credit card company, or the eCheck service, or Venmo/PayPal/Apple pay? Websites and native apps alike have spinning graphics and loading bars, messages that say "please don't refresh the page while we do this". These systems are fundamentally asynchronous to begin with. By uniformly applying the practices you get consistency, in exchange for a higher low-bar of complexity (which you're likely to exceed anyway).