Plugin system in Elixir

Mine had priority, they registered based on a given priority, but in general it was used by plugins, not something big.

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.

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.

Callbacks.

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.

If I use the name directly, plugins cannot interact with each other. Maybe the next plugin in the “middleware chain” decides to crypt the file before upload, or decides to stop the upload. This should be agnostic for plugins. super represents this — go on with the middleware — but it can also be named next_method or yield. Middleware engines are very nice IMHO.

I see I can overwrite methods, but I don’t want the user of the library to compose the logic. I showed simplified examples, but logic can be a little bit more difficult. More plugins more code and more complex.

Definitively at compile time. I don’t see the point of doing it at runtime.

Maybe my solution will be just simplifying to the maximum the API and create middleware for each method, like decorating pattern kind of.

Oh thank goodness! It is about time!

>.>

Uh, so basically what mine already is… I wonder if I should just rewrite it in Elixir and publish it so it has an elixirified API… >.>

GenEvent is in the process of being deprecated

Plataformatec: Replacing GenEvent by a Supervisor + GenServer

I just do plugins via gen_event, isn’t that the easiest and most built-in way?

Literally I just send an event at whatever hook points I want and let whatever is listening to them do whatever they want at that point.

gen_event has it’s share of problems that I fixed in an erlang replacement library long ago, like using monitors instead of links (gen_event predates monitors did you know? ;-)). Does Elixir have a GenEvent that uses monitors? I’ve not actually checked, I just use my Erlang library in Elixir thus far… >.>

I don’t think this is what you’re after - but just in case - eplugin has a totally different approach to plugins.

There is a dedicated gen_server process that is responsible compiling the plugins and managing their particulars in ETS tables.