We're in the process of building an application entirely based on ZF2. The application is split into 3 main divisions namely a Core, API and Front End section / division.
At some point, we want to open the system up for people to develop 3rd party modules which will go on offer for inclusion in the different profiles customers have. These 3rd party modules would either extend functionality or be able to enhance existing processes by hooking into events fired from the Core Level.
These 3rd party modules could use the API, however, the current API is outward focused and does not lend itself to enhancing and extending the system from this perspective.
So, the alternative would be to allow access to the Core directly, which we feel might not be desirable as we must have a means to control access to these vital components and underlying data.
I am considering building a separate API aimed at trying to manage access from a module level within the Application life cycle, however, I am not entirely sure how something like this would look like.
The folder structure would look something like the following:
-config
-data
-AppCore
--Core
--CoreForms
--CoreContacts
-AppAPI
--APIForms
--APIContacts
-APPFront (This fodler will be into a seperate instance of ZF2 installation and communicate via the APPApi)
--FrontForms
--FrontContacts
-3rdPartyModules
-public
-vendor
Developed modules would reside within the 3rdPartyModules folder within the entire structure.
The question is, how would one go about limiting access to Core resources, for instance, any 3rd party modules must not be able to consume the standard database adapter. In this case, db_adapter (Zend\Db\Adapter\Adapter).
These modules will have a separate database setup where data should be stored specific to these modules, so something like db_adapter_3rdparty would be made available instead.
I have considered using interfaces to be implemented within these 3rd party modules and then have a check performed by any of the core module classes and functions, however, this would be cumbersome and inefficient.
Currently, the API functionality is only accessible via REST, so that would not be option for hooking into the system as keys would become involved and be an admin nightmare.
So the question is then, allowing modules to be installed within the overall application, would you be able to limit access to application resources, if so, what would be the most efficient way of implementing such control and whether it is a good idea to allow this to take place?
I've done quite a bit searching and could not find anything close along the lines of what is required, apart from actually installing modules, configuring them etc.
Many thanks in advance!
Related
When should we use multi-module structure (instead simple structure) in php Phalcon?
I have found some multi-module skeleton, such as:
https://github.com/ovr/phalcon-module-skeleton,
https://github.com/phalcon/mvc/tree/master/multiple.
But I don't know should i use this multi-module structure in a project instead use multi projects.
Something i can think about it is: more complex configuration, complex folder structure, my web url be longer (/[module]/[controller]/[action]) and , importantly, performance will be low (for more loading things than).
However, I think that there are something interesting with it (so many ITer had used it). Is there Someone can give me advantages, disadvantages and criterias for selection.
P/s: the same problem with Zend2 Module!
If you are building a single purpose application as an API that does not use Views, you should rather use single module structure. If it will be a realy simple API of for example storing/logging, micro app will do aswell.
Multi module application structure is useful if you are willing to build more complex solutions. For example an public application with public content, but with admin panel. This one would be handy to write in multi-module to separate administrative controllers/views from those public ones.
My habit is to use multi-module structure, because mostly I have to build applications that are CRM's with their API and an public accessible content part (eg. docs). For such purpose it's just handy to create such modules as:
frontend - for controllers accessible by everyone
backend - for controllers accessible after authentication and authorisation like administrative things
API - for API purposes ;)
common - a part I rather am willing not to implement, but in one project I'm forced to put here some abstract controllers that will be extended in other modules.
This way you can keep separate services configuration for each module, what saves you from cutting off things that you are using at purpose of module A, but not on module B. Like authentication part - important for backend, but useless for frontend part. Or Database configuration - slaves for frontend, master for backend, etc. So this may be also a performance-wise solution for big projects.
Update
Sometimes "multi-project" is an option including "multi-module" project ;) It strongly depends on what you are trying to achieve. Eg. if you take API apart, it may be easier to scale it over multiple instances, but at first it costs you an efford to configure separate project.
If system is supposed to be single-server instance or every istance should be absolutely independed on other instances, single multi-module project will be enough - lets say a standar CMS, blog platform, even simple browser game or homepage of mobile app including API for it. But if you are building a whole universum of apps like an internal API to privide content, CRM to manage it and a couple of web pages to serve it, keeping these as separate projects will be easier to manage later.
Well for example I in my application im splitting every functionnality - for example i have model Link - it's splitted to seperate module to have nice application structure where each funtionality is seperated module. It's like less classes to load in loader. Beacause you only need models and routes from each module to load for whole app, and you load other things like librarys/controllers/helpers/services in module.
We have a pretty large Symfony 2 web application which has many different endpoints and features:
api for data from our legacy product
web components for use in our legacy product
api to our new iOS POS
api to loyalty end-user portal
web interface for loyalty end-user portal
web interface for (seperate) invoice end-user portal
big admin area with configuration for all of the above
The database layer (in Doctrine) on this is tightly coupled. Transactions from both the POS and our legacy product are used in the loyalty end-user portals and invoices are based on the same transactions. Obviously there's also many entities that are solely for specific parts of the application.
We originally decided on the single app+bundle approach for ease of programming, which has served us well in developing the whole platform. Unfortunately the main drawbacks are:
very bad performance (although things like further caching, minimizing assets etc can help, we think that having such a bloated bundle that needs to be able to handle everything and also included different 3rd-party libraries only used in specific parts of the application is slowing everything down.)
we use continuous integration and generating new builds and running all the functional tests is taking 20+ minutes.. and we still have many classes lacking (proper) tests.
when we change part of the application, another part breaks easily. Although more and more decoupling and functional tests help with that, it's still far from ideal.
I've done some research to splitting a Symfony project into multiple projects (each with it's own github) and using SOA to connect them. My personal experience so far with SOA is that it makes things very hard to test fully and adds lots of overhead when migrating from standard Symfony 2 forms (which I totally love).
I was also thinking on another solution by creating a shared bundle with the shared entities and repositories. This would make it much easier to test code and share common services (managers), although I've also heard argumentation against big managers. The big downside to this is that we cannot simply use doctrine:schema:update then, because sharing the database and updating the database on a project with a lower version of the shared bundle, will remove fields.. causing loss of data. Also on this approach I have been unable to find any examples or use-cases.. which leads me to wonder if it wouldn't have many more downsides.
So my question is: what are common approaches and solutions for splitting a big project like this? And: are there reasons that maybe it should not be split at all?
Although I'm answering your question, It's kinda hard to come with a magical solution for your problems. This is not an attempt to solve all of your problems, nor impose you of following it. This is not the only possible solution, actually this might not even solve your problems. That said, let's begin.
I'd split the project in 4 layers:
Presentation Layer: Desktop aplications, Web interfaces (no matter if
is php, C#, if it uses Symphony or any other framework and third
library components), Mobile Apps, everything end users can see and
interact with (also known as GUI). These guys only communicate with
Application/Service to request something, like a list of available
products, update some data somewhere, send an e-mail for customers.
The key here is they really don't know how and where is
Appication/Service layer going to do the requested actions.
Application/Service Layer: I'd treat this as controllers which can receive requests from the Presentation Layer, and external webservices as well. They look like APIs, and will decide if they have to access/manipulate data through a Repository, or send e-mails using some SMPT service. They just makes the communication between GUI or external webservices which might consume your APIs and Domain/Infra layers. Yet they don't actually know what SMPT service they are using, or where data is going to be stored and how (in a MySql through Doctrine? in Sql Server through Entity Framework? in a NoSql database? txt files?). Application layers usually have their own Models (also known as ViewModels), which are exposed to the world and returned to the requester (GUI or external Webservice), representing part of the domain models. This mapping (convert Domain classes to Application classes) can be done with patterns like Facade and Adapters (also called the Anti-corruption layer), and there are plenty of packages to resolve this (for C#, there is Automapper, for PHP there might exist something either). Why should you need this? To avoid exposing your full domain to the world. Suppose you have Invoice and Loyalty end-users, but you wanna treat them as one unique domain class "User" with their corresponding properties together. You could create a LoyaltyUser and an InvoiceUser classes in your application, each one containing only the necessary properties for that purpose, then use this Mapping technique to map the domain User class to each one of them. Therefore, the application layer usually contains authentication and authorization rules, so only the Loyalty end-user would have permission to access controller's actions which would deal with the LoyaltyUser model. Inside a single action in a controller, you shouldn't take different paths/ways depending on the requester (for mobile, do this, for website, do that). Instead, you might have different actions for each one, and tue Presentation layer knows what they want to request.
Domain Layer: This is your core, containing all business logic. This is what provide value to your business. Domain layer container
models/classes representing real entities from your world, interfaces
for services and repositories. Domain must be the most clean and
natural possible. They can't know what application is asking
something, nor how type of infra is being used. They just do business
logic. The Domain layer don't know if your are using Doctrine or Laravel as an ORM, nor if the application is a php website done with Symphony, or an Android Native App.
Infra Layer: Here you implement things like database, SMPT service, Logging, and other things your application might need.
Doctrine would reside here. Therefore, you would create Repository
classes implementing the repository interfaces of your domain. The
Repository implementation uses Doctrine to do stuff. These
implementations are providen to Application Layer (normally via
Dependency Injection). This means the Application Layer shouldn't
know if is Doctrine or Laravel, that's why the Application uses the
Repository (so logic to access database are encapsulated).
Your web interfaces would reside in Presentation. If the framework you use in your web have to use MVC and therefore have controllers, these controllers should dispatch to the Application Layer (I know it sounds redundant). Your APIs would reside in Application Layer.
This is very decoupled, if you need to change from Doctrine to Laravel, your don't need to change your Domain nor your Apps. If your need to change from Symphony to anything else, or even change your website from PHP to ASP or Java, your domain don't have to be changed.
Adding more layers, mapping objects, using DI shouldn't make requests slower, considering the hardware's price and capacity nowadays, the difference in time is almost imperceptible. You should put efforts attempting to improve your domain, which brings value for the business. Separating layers improve decoupling, chances of changing part of application breaking other parts, increase flexibility of scaling your app, and makes testing easier.
Rein, what was the solution you've finally ended up with? Have you actually split your project?
There is really a lack of information in this area, I just found one reasonable article https://ig.nore.me/presentations/2015/04/splitting-a-symfony-project-into-separate-tiers/
I've started working with Yii for a month (great Framework) and I am now going to build an application, ERP style.
The goal is to have a main application and then, according to user's roles and permissions, have the possibility to navigate (through single sign-on) to the other applications in the ERP.
I read about modules on Yii's docs and although I got the idea, I was left with some doubts.
Surely it is an advantage to have a One Big application with all the branch applications the company needs as modules but what are the limitations?
Or is it preferable to create seperate entire applications instead of modules inside the main App and then navigate through sub-domains?
Its better and preferred to have modules rather than developing separate applications. With modules you can have totally different look and feel just like a separate application. You must have used Gii tool, well that is also a module within your application.
The main advantage with modules is that you wont have to deploy it separately, it is a self contained application in your website. But again that could be a disadvantage if you need to have total separation of these applications.
To learn more about modules see http://www.yiiframework.com/doc/guide/1.1/en/basics.module
As our company starts using Zend Framework as the base framework for most of our projects, we want to share some common elements across all our projects. I talk about things like:
An implementation of a model (based on doctrine2)
RBAC for the model, including user, group, role models
A xml-based templating engine for ajax backend interfaces
(you name it) ...
Basically, all things to put "zend on rails" and get going. What is the best way to package these components? I see two possibilities:
As modules
We include the necessary functions as separate modules into the modules folder.
Pro:
We can set routes and execute code, which is good for many modules (imaginary example: a paypal module needs some kind of callback url. If our module can set it up on its own, no configuration from the "project developer" is needed).
We can provide real functionality (like the user administration) out of the box
We have a bootstrap to set up autoloading and doctrine etc.
Con:
Bad place? Interferes with the users project
A little harder to share between projects (git submodules instead of classpath)
In the library folder
We put it in the library folder and point the classpath to it.
Pro:
Clean solution
Sharing across projects
Con:
Bootstrap has to be explicitly called
No direct routing or actions - everything has to be proxied through the concrete project
So, how do you solve this? Where do you put your reusable, general purpose stuff in zf?
I think you should use both approaches.
When developing "library-like" code, as in kind of "infrastructure" classes and other things that are reusable (like ZF's own components, Doctrine 2's components etc.), you can put them into the library directory. (or its own entirely separate project)
When developing actual ZF modules (like an auth module for example), then format the code around the ZF module structure.
I think by using this kind of approach you get all the benfits you listed, and pretty much none of the cons :)
As one additional idea, if you develop your architecture parts as "services", you could even keep them running as their own web service endpoints.
I have way too many modules in my application. Currently my modules are namespaced, but what I'd like to do is have a directory structure so I can get rid of this redundant and annoying namespacing.
For instance, for modules named "xModule1, xModule2, xModule3", I'd like to have a directory structure like this:
-x
-module1
-actions and templates
-module2
-actions and templates
-module3
- actions and templates
Surely the developers at symfony know that people would like to use their framework to develop large applications. So how is module organization like this done?
I've done a lot of work in Java/Spring, and because source is component scanned, you can arrange your controllers and jsp files in nicely organized hierarchies. Is this somehow possible with Symfony?
No, this is not possible with Symfony. The structure of your modules and their actions and templates is expected in a fixed file system layout and I haven't heard anything about that changing.
I've run into the same problem you're facing where a very large site ended up with 30+ modules in a single application. At first it seemed cumbersome but after dealing with it for a while I found that the single location to search for a specific module was in fact beneficial instead of having to guess through sub-structures until I got what I was after. Seeing that structure grow and grow also pushes me to respect adding new modules only when it's absolutely necessary, folding new functionality into existing modules and refactoring existing modules to work with new enhancements whenever possible.
Symfony does have auto-loading features that will work for your library folders however, allowing you to have lib/one/two/three/Object.class.php or any other structure you see fit.
If you have so many modules, you could consider to move some functionality into plugins (i.e. create your own plugins).
The benefit is that you can use this functionality also in other projects.
Or you can group your modules into applications. You can have as many applications as you want, not only backend and frontend.
I've wondered about the same thing, especially as many configuration files need to be set either at application level or individual module level. It could useful to be able to cascade configurations to a set of modules.
As mentioned above, it seems the available solutions are:
deal with lots of modules
create separate applications (which will create some wieldy duplication)
refactor your modules to be as efficient as practical (i.e. multiple controllers & views per module)