Loading Modules Dynamically in Zend Framework 2

Question

I have asked this question yesterday as well, but this one includes code.

Issue

My application have multiple modules and 2 types of user accounts, Some mod

Answer 1

What you're asking can be done, but that doesn't mean you should.

Suggesting an appropriate solution without knowing the complexity of the application you're building is difficult.

Using guards will certainly help decouple your code, however using it alone doesn't address scalability and maintainability, if that's a concern?

I'd suggest using stateless token-based authentication. Instead of maintaining the validation logic in every application, write the validation logic at one common place so that every request can make use of that logic irrespective of application. Choosing a reverse proxy server (Nginx) to maintain the validation logic (with the help of Lua) gives you the flexibility to develop your application in any language.

More to the point, validating the credentials at the load balancer level essentially eliminates the need for the session state, you can have many separate servers, running on multiple platforms and domains, reusing the same token for authenticating the user.

Identifying the user, account type and loading different modules then becomes a trivial task. By simply passing the token information via an environment variable, it can be read within your config/application.config.php file, without needing to access the database, cache or other services beforehand.

Answer 2

I think there is some fundamental mistake in what you are trying to do here: you are trying to load modules based on merged configuration, and therefore creating a cyclic dependency between modules and merged configuration.

I would advise against this.

Instead, if you have logic that defines which part of an application is to be loaded, put it in config/application.config.php, which is responsible for retrieving the list of modules.

At this stage though, it is too early to depend on any service, as service definition depends on the merged configuration too.

Another thing to clarify is that you are trying to take these decisions depending on whether the authenticated user (request information, rather than environment information) matches a certain criteria, and then modifying the entire application based on that.

Don't do that: instead, move the decision into the component that is to be enabled/disabled conditionally, by putting a guard in front of it.