Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Revisit can-connect #288
referenced this issue
Jul 17, 2017
I noticed this epic issue on gitter and thought I'd give my ZAR0.02.
You may be thinking "this guy is pattern crazy!" but actually I'm not really. It is more a case of these things being around for a while and folks have come up with names for them.
In my service bus and event sourcing mechanism I make use of an observable pipeline that loosely follows the "pipes and filters" pattern. For "significant" processing I make use of a pipeline. For instance, when retrieving a message from a queue I use the
The issue I had was that a true pipes and filters mechanism isn't easily extendible. In the Asp.Net world the application has a number of events in its pipeline. The idea is that you can register other objects such as handlers and modules that then hook into the pipeline. Even in this mechanism there is no way to add to the events since it is a rather fixed business. This means that when event-x is raised all the objects that listen out for that event are called in the order that they are registered. Now if I need to have finer control over this ordering then things get a bit tricky.
When the pipeline executes all it does is run through the list of events and calls each observer that listens to that event.
However, one could go a step further and go for a per-pipeline approach since there is somewhat of a difference between POST, GET, and DELETE for instance.
In this way it would be possible to add an event say using something like
Perhaps there are other ways also that I cannot think of straight away.
Anyway, I thought I'd put this down and see if it resonantes with anyone :)
Thanks for the feedback @eben-roux I'll look through the patterns you've linked and see if there is anything we can learn from them. The terminology is useful at least.
Regarding the difficulty with ordering behaviors (events as you phrase them) and their implementations (observers in your example), this is something we've put some effort into but we haven't yet found a solution we like yet. Your approach is interesting and something we'll keep in mind when revisiting this issue. A difficulty is that we actually have multiple "pipelines" and some stages of a pipeline extend previous ones and other override the previous behaviors altogether.
We hoped to remove the need for a canonical ordering of behaviors altogether, instead algorithmically determining how behaviors need to be ordered, however due to the high difficulty of doing that we may ultimately take another approach.
I've opened #335 to capture further discussion on this particular improvement.