Solved thread

This post is marked as solved. If you think the information contained on this thread must be part of the official documentation, please contribute submitting a pull request to its repository.

Modules or Single Apps?

Hello!

Most of operations in app that I develop based on angularjs that gets json responses from RESTful API write with Phalcon. So I have 3 parts: API without views, Frontend with ui for users and Backend with ui for admins.

And all parts of app uses common models, libraries and settings (db and some services).

Should I use multi-module structure (http://docs.phalconphp.com/en/latest/reference/applications.html#multi-module) or better to make 3 apps with common config, models and library folder?

Thanks!



83.4k
Accepted
answer

I would go for 3 different apps, you can design a bootstrap that specifically work for every environment without unnecessary components/features/checks. For example, you can use a micro app for the Restful API and a single app for the backend and frontend. Libraries can be shared using a common autoloader.

IMO, the only true difference comes at the testing/QA and deployment stage. With separate apps using a simple shared lib, you can deploy and test each app individually whenever you have changes that specifically affect that app. Typically, a project with a single app containing multiple modules will always be deployed as a single bundle - a small change to the shared lib or any app means redeploying the entire app stack. It mostly comes down to preference. I prefer the look and feel of developing an app with multiple modules (it just seems more natural and organized). The reality of the day-to-day though, means not always having the time to test every app immediately after making a change to the shared lib for a single, specific app. By having separate apps, each app can be deployed with a different version (ie: git, svn) of the shared lib, which makes it possible to make sweeping changes to the shared lib for the benefit of one app, and not have to worry about possible unintended effects in the other apps until that app's own next QA and deployment cycle. It would be great to have the policy of immediately testing all apps after a change to the shared lib is made (makes sense, no?), but sometimes it's just too much to do up front.

tl;dr. If you're not sure, stick with separate apps that use a common shared lib. An app with multiple modules takes away some flexibility in the development cycle.

Don't mean to reopen a thread, but it's been a few years since some significant changes to Phalcon. Does the recommendation still stand?

Thanks.

I would go for 3 different apps, you can design a bootstrap that specifically work for every environment without unnecessary components/features/checks. For example, you can use a micro app for the Restful API and a single app for the backend and frontend. Libraries can be shared using a common autoloader.