As it stands now, I'm developing two services, deployed on the same
server, sharing the same database. These services each have different
hostnames.
I have 3 bundles, one for each service and a shared bundle with the
entities.

If I have one application i have to seperate the services with routes,
and that is not possible. I have to seperate them by hostname. And
that is why I chose to create two application.

If there is any way to avoid this then I'm happy to oblige, but at the
moment this is the situation.

We have doen projects with multiple applications in one git repo in projects. The idea being that for development its easier to have them all in one repo, but for deploying we want to keep them separate. For example one server with the admin interface, another one with the frontend, another one with the API. this lets us scale things separately. it also makes it easier to control the impact of misconfigurations etc.

I am using 2 applications in my sf2 project. One is holding frontend
configuration and second is for backend configuration.
We decided to use 2 applications because both configs are way
different but use same databases, same entities and some common
bundles.
When we separated backend and frontend applications then we have only
whats really needed in project container.

> I think a many people use a fontend/backend structure. I couldn't find the best practice for this in Symfony2..> > Is there a best practice if you want the frontend and backend in the same applications? Ideally you have one bundle with the business logic, backend and frontend code.

the best practice was explained in this thread already:simply create as many frontend controller + kernel's as you need

however the key question when putting multiple kernels into one repo is how many custom bundles are shared. if the answer is zero or very few, then i would recommend to use separate repo's for your applications and another repo for each shared bundle.

we have a project where lots of entities are shared across the admin, frontend and api kernels so they all sit in one repo for convenience.in another project we have a REST api between the backend and frontend so in the end we only had custom bundle that is shared that we simply put in another repo to easily share it between the two applications.

I have a theory that there is a simple way to do this, however I have
never tried it so please bare with me.

In Symfony2 there is a variable used called $_SERVER['KERNEL_DIR'];
the reason I know its there is because I set it in my bundle unit test
boot strap to make sure the kernel sets up correctly in test cases
which require the kernel.

My theory is that you could set up different app.php files in your web
folder and set the $_SERVER['KERNEL_DIR'] in the app.php file

For instance if you have a sight called cats.com and another site
called dogs.com and they both used the same symfony base code but
different apps you could create one app folder and call it cats and
another app folder called dogs

Then in your .htaccess you could do something where you point all
traffic to cats.com at app_cats.php and all dogs.com traffic at
app_dogs.php

i guess there is another key question and that is who develops the given application and what is its upgrade cycle going to be.for example if you have one team doing the frontend and another the backend it might be better to keep them split in different repos.

another point is when you want to upgrade dependencies. you might prefer not to have to update everything in one go. where again it would be nicer at times to have things in different repos.

To bring this up again, i think this is the best multi app structure for a project (@Cédric Lahouste). The main reason i use this is because of APC. This way common php files like inside vendors/* or src/*etc. are only compiled once in APC memory, and not for each directory (project). Having 2 or more projects, each in a different folder will waste more APC memory for common files, like the whole Symfony2 framework.

As Fabien said, most of the time you won't need more than one app in a project. If you need a "backend", you can always route anything after "www.domain.com/backend" to a specific bundle and handle it there (while having access to all other bundles).

But if you (like me) prefer a clean separation (different cache & log dirs, different set of shared bundles etc.) then this approach is great. Almost all console commands have an option for a different app path. You can for example use "backoffice/console assets:install web/backoffice" to install all assets in the right place.

The only catch i found so far is the use of "vendors.php" and "build_bootstrap.php", where the "app" path is hardcoded. So this multi app functionality is possible, but not promoted like in symfony 1.

There is some hostname-related configuration (session domain cookie, security remember me cookie, session dfault locale) wich different in hostnames. And when container compiles it contains embedded/resolved parameters for only one hostname. So there is 2 possible sollutions:

1. use multiple apps2. override some methods like getCacheDir in Kernel and resolve cache path

Another alternative is to have a service that figures out what your current "domain" is. You can then use a little trick created by OpenSky to make any parameter dynamic, which could be controlled by that service (https://github.com/opensky/OpenSkyRuntimeConfigBundle). The approach seems a little strange, but having runtime configs gives you the flexibility you need and seems less dramatic than multiple applications or cache directories.

I have the same problem, where I want multiple different "applications", that act differently and look differently, but really all have the same underlying business logic and require access to the same data stores. Each application comes in on a different subdomain or domain name. Here's how I'm solving it:

use .htaccess rules or webserver configuration to point domain names to specific front controllers (app1/app.php, app2/app.php)

At this point, you can override routing rules for each specific application by specifying a tailored routing.yml

Although people are saying they miss the Symfony1 application structure, this actually is a step up, as you can actually change routing and parameters much easier with the current setup, where as before you only really had one routing table you could work with.

By the way, you do have to do some AppKernel tweaking to get it to understand the concept of an 'application', but really its just about changing the contructor to accept an application name, and then changing registerContainerConfiguration to load the correct configuration file.

On Tuesday, July 10, 2012 6:54:24 PM UTC-5, Joshua Nankin wrote:

I have the same problem, where I want multiple different "applications", that act differently and look differently, but really all have the same underlying business logic and require access to the same data stores. Each application comes in on a different subdomain or domain name. Here's how I'm solving it:

use .htaccess rules or webserver configuration to point domain names to specific front controllers (app1/app.php, app2/app.php)

At this point, you can override routing rules for each specific application by specifying a tailored routing.yml

Although people are saying they miss the Symfony1 application structure, this actually is a step up, as you can actually change routing and parameters much easier with the current setup, where as before you only really had one routing table you could work with.

On Wednesday, March 14, 2012 5:31:34 PM UTC-5, Константин wrote:

Thank you for advie.It Looks like good sollution, but there are some problems on integration

Another alternative is to have a service that figures out what your current "domain" is. You can then use a little trick created by OpenSky to make any parameter dynamic, which could be controlled by that service (https://github.com/opensky/OpenSkyRuntimeConfigBundle). The approach seems a little strange, but having runtime configs gives you the flexibility you need and seems less dramatic than multiple applications or cache directories.

There is some hostname-related configuration (session domain cookie, security remember me cookie, session dfault locale) wich different in hostnames. And when container compiles it contains embedded/resolved parameters for only one hostname. So there is 2 possible sollutions:

1. use multiple apps2. override some methods like getCacheDir in Kernel and resolve cache path

--
If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com