Plugin/middleware architecture?

[fjorgemota]

Seems like Jimple has some new friends, that add new features to the package, like frozen-jimple, which extends the class and customizes it as shown in our README.

So..should we add a plugin/middleware support directly to the package? It's just an idea for now, suggestions are accepted.

[alxarch]

I decided in the end to implement this outside the container, I will deprecate frozen-jimple in favor of a mix of koa and containers. but middleware logic will belong to the koa side of things. Also the set, run, unfreeze cycle is very cumbersome when implementing certain providers. Will update a comment here when things are stable enough on my experiments.

[fjorgemota]

frozen-jimple seems relevant to detect things like modifications to the container after the startup of the application, which should not occur normally, because it indicates wrong use of the container. It's the implementation of an idea that I had some time ago.

By the way, I think the support to plugins should open margin to nice things, like logging, for example, and creation of graph of the dependencies in a container, which I think can help the developer to understand the behavior of the application more easily. Because of these reasons is that this issue was opened...

What you think?

[alxarch]

I think that Jimple should adjust pimple's logic to fit javascript idioms. For example closures are 'free' in javascript so passing c as first argument every time is pointless since the functions calling set already has a reference to the container which it can use inside the callback. (This is not the case in PHP where closures where an afterthought and the weird use syntax was introduced). The frozen feature will also add a lot of logic to the getters/setters and will force the implementors of providers to do weird tricks to get around it. And they will get around it with poor coding quality (ie basing on this.items etc). So I would only recommend it as a Subclass (ie Jimple.FrozenJimple)

[fjorgemota]

Well, makes some sense to adapt Jimple to fit Javascript idioms. However..

• It's possible to use that c as first argument every time to customize the behavior if using something like a middleware/plugin, like registering what services a service would need, maybe. That's because, using an argument, we don't need to pass the container...but a wrapper of it, for example (it's just an idea, maybe it does not make sense...haha);
• About frozen..yeah, It probably would not make sense to a plugin/middleware..(btw, a possibility in this case is to Object.freeze the this.items object instead of overwriting the methods, I think)

I thing that I am not sure if Jimple should manage is async services. What you think about that?

[alxarch]

Have a look at the implementeation I published yesterday lazybox. I think it is simpler and more js oriented. The container as default argument logic makes sense. I already implemented it for the next release.

[fjorgemota]

Well, lazybox seems to be a bit more js oriented, but do not match the idea of Pimple's port that jimple has. So, I seem it as two different solutions for the same problem (of resolving services dependencies correctly)

However. In the case of js and DI I think that the real problem is async services. Think for example some database connection that needs to connect to the database, or a system that loads configuration remotely. Should a DI container developed in JS be responsible for that? I am not sure about these type of questions, but I think that may plugins/middlewares can provide different solutions for that...

[alxarch]

The tricky part there would be to determine if some depended upon service can be run in parallel. But using Promise.all wisely would solve this I think. Maybe have a look at co also. In my opinion async stuff should happen through a service's API, not during initialization. On server side this ensures 'instant' process restarts for deployments etc. On the browser side it could be useful, similar to angular's config pattern but with more (?) controlled order of execution. Have a look at cokoa For an implementation of frozen-jimple's run() step on the koa side of things

[Poyoman39]

It's an old post but i see it's still opened. To me Jimple power is pimple one : the simplicity. I was hapily surprised to see how short the implementation is. Making built in plugin support would break this simplicity i Think. Moreover, for logging purpose a simple wrapper would do the trick. I hope this opinion helps 😁