I didn’t know the library. It seems very nice to decoupling the code. However, I see lack of flow control for my use case, stop the processing for example. I could define several callbacks, before_action and after_action, where the plugins can stop the action but it feels complicated.
Same here, it is perfect to decouple the code but not to control the flow of the code.
In which case I would suggest looking at how plug does this. It’s an elegant approach to these kinds of situations which sidesteps the whole functions-as-API design cascade, and there is no calling of prior or parent functions in any of the plugs.
Message bus solutions are indeed truly powerful; but if you need / want predictable order of execution then they are more difficult (or just (d)evolve into multiple points of serialized behavior).
Not sure they are looking for a message bus solution in this case? I would expect there needing to be a predictable order of execution, and coupling steps through unwritable contracts of “when someone somewhere eventually emits message B after message A, then I’ll do something..” isn’t really so workable.
That said, I’ve used message busses in many applications in the past where order of execution wasn’t of concern, and I 100% agree with you that they are absolutely lovely in those cases.
Mine had priority, they registered based on a given priority, but in general it was used by plugins, not something big.