laminas / laminas-modulemanager

Modular application system for laminas-mvc applications
https://docs.laminas.dev/laminas-modulemanager/
BSD 3-Clause "New" or "Revised" License
30 stars 18 forks source link

Generate module configuration cache via command line #5

Open weierophinney opened 4 years ago

weierophinney commented 4 years ago

Related to PR https://github.com/zendframework/zend-modulemanager/pull/53.

On a production running website one would ideally have the module-config-cache.php file generated before launching a new version. It would help if a command line utility would exist for this. This could work like the autoloader could be generated beforehand: https://framework.zend.com/manual/2.2/en/modules/zend.loader.classmap-generator.html.

Any thoughts on this?


Originally posted by @roelvanduijnhoven at https://github.com/zendframework/zend-modulemanager/issues/54

weierophinney commented 4 years ago

@roelvanduijnhoven module config generally is applied with any CLI command execution (due to it caching-style transparent API), so a "hello world" action in your app should be sufficient in order to generate all cache config.

Another issue about this is that the CWD must match in order for many configs to actually work as expected.


Originally posted by @Ocramius at https://github.com/zendframework/zend-modulemanager/issues/54#issuecomment-280636851

weierophinney commented 4 years ago

Mm. True. Config depending on $_SERVER will break for example. And although you should not do so; some people most likely are using it that way. So I guess what I propose won't really work.

Maybe close this one; and properly fix locking.


Originally posted by @roelvanduijnhoven at https://github.com/zendframework/zend-modulemanager/issues/54#issuecomment-280639177

weierophinney commented 4 years ago

Agree that they shouldn't do that 😥.

Maybe a validation CLI command that verifies generated config is idempotent, before dumping it somewhere?

On 17 Feb 2017 1:42 p.m., "Roel van Duijnhoven" notifications@github.com wrote:

Mm. True. Config depending on $_SERVER will break for example. And although you should not do so; some people most likely are using it that way. So I guess what I propose won't really work.

Maybe close this one; and properly fix locking.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/zendframework/zend-modulemanager/issues/54#issuecomment-280639177, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJakNvX2kHszCd1XGZnWJ46PiTSnAw4ks5rdZWdgaJpZM4MENnD .


Originally posted by @Ocramius at https://github.com/zendframework/zend-modulemanager/issues/54#issuecomment-280642824

weierophinney commented 4 years ago

If you use a timestamp as a cache key somewhere in your configuration; you get two config files that are not idempotent. But that is a valid usecase, right? So idempotent is not important IMO.

The thing is that the config generated via CLI should work on web in an ideal world. But I am almost sure that this won't be true in a lot of real-world use cases.

If you really want to warm up your cache you should expose an end-point on the web; that will trigger the config generation. But that is outside of the scope of this repo, right?


Originally posted by @roelvanduijnhoven at https://github.com/zendframework/zend-modulemanager/issues/54#issuecomment-280645569

weierophinney commented 4 years ago

But that is a valid usecase, right? So idempotent is not important IMO.

It is EXTREMELY important, because that already shows that you can't cache config.

The thing is that the config generated via CLI should work on web in an ideal world. But I am almost sure that this won't be true in a lot of real-world use cases.

That's where the validation would simply make the generator crash. It wouldn't prevent the user from caching configs, but at least it would say "You're on your own, buddy! You're doing things that I don't want to be held responsible for.".

If you really want to warm up your cache you should expose an end-point on the web; that will trigger the config generation. But that is outside of the scope of this repo, right?

Yes, that's out of scope and it also opens a can of worms when it comes to security issues (DDoS related, specifically)


Originally posted by @Ocramius at https://github.com/zendframework/zend-modulemanager/issues/54#issuecomment-280651879