> Yes, passing a message along to another network service is another step. But whether or not it is an additional "responsibility" is debatable I think. It depends on what your baseline is.
It's just my feeling based on my experience.
What if there are 15 services? Who decides where to route and why? I want to see how it would work in practice. That's why I asked for something more concrete than A, B, C, D. Maybe it would actually be easier and more straightforward, I don't know.
> There would be no net difference to pass a result forward compared to back to the caller.
For example, A knows it has called B, so if there is no response it knows that it has to handle an error, do a rollback and whatnot.
> There is nothing intrinsically wrong with using callbacks. Callback hell is a syntax problem with some languages.
Right, bad wording on my part. If it's A's responsibility to say where to route the result to D, is it also its responsibility say where to route the result of D? Would I have to specify the whole call chain? Do I pass the whole call chain to both B and C? That's what I meant.
What if the request didn't originate from A but from Ω? And B, C are also called to be routed to D by another service called by Ω in the chain sometimes. As stated in the article, D waits for B, C that originate from the same call, which is Ω. Now someone who maintains A is going to have very good time trying to debug that to understand why sometimes D is called with wrong values and then maybe even crashes or returns an error.
> a state machine could be hellish to write explicitly (call it "state machine hell" perhaps, haha) so Rust provides a better syntax for it
Every computer is a finite state machine and we are using mental models like async/await to hide this pesky fact and simplify our lives.
>> There would be no net difference to pass a result forward compared to back to the caller.
> For example, A knows it has called B, so if there is no response it knows that it has to handle an error, do a rollback and whatnot.
Good point. Many application designs wouldn't work as-is in the "pass forward" approach. I hesitate to say in response: "well, then you're architecting it wrong". But perhaps there is a grain of truth in that. Maybe it is hard tradeoff.
> Yes, passing a message along to another network service is another step. But whether or not it is an additional "responsibility" is debatable I think. It depends on what your baseline is.
It's just my feeling based on my experience.
What if there are 15 services? Who decides where to route and why? I want to see how it would work in practice. That's why I asked for something more concrete than A, B, C, D. Maybe it would actually be easier and more straightforward, I don't know.
> There would be no net difference to pass a result forward compared to back to the caller.
For example, A knows it has called B, so if there is no response it knows that it has to handle an error, do a rollback and whatnot.
> There is nothing intrinsically wrong with using callbacks. Callback hell is a syntax problem with some languages.
Right, bad wording on my part. If it's A's responsibility to say where to route the result to D, is it also its responsibility say where to route the result of D? Would I have to specify the whole call chain? Do I pass the whole call chain to both B and C? That's what I meant.
What if the request didn't originate from A but from Ω? And B, C are also called to be routed to D by another service called by Ω in the chain sometimes. As stated in the article, D waits for B, C that originate from the same call, which is Ω. Now someone who maintains A is going to have very good time trying to debug that to understand why sometimes D is called with wrong values and then maybe even crashes or returns an error.
> a state machine could be hellish to write explicitly (call it "state machine hell" perhaps, haha) so Rust provides a better syntax for it
Every computer is a finite state machine and we are using mental models like async/await to hide this pesky fact and simplify our lives.