Symfony2 multiple kernel?

Question

I have application which has core website, api and admin area. I wanted to know is it bad idea to have everything in one app or should I create different Symfony2 project or should I split them into different kernels?

I'm not sure if adding lots of bundles on same kernel will effect performance a lot or is just a little bit, which does not matter?

Following are options:

1. keep everything on same kernel, it wont make much difference
2. have multiple kernel for different part of application (api, admin and core website)
3. create different Symfony2 project for admin area and api.
4. or your wise words :)

Answer 1

You can define more "environments".

For example :

In AppKernel.php

public function registerBundles()
    {
        $bundles = array(
            new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),
            new Symfony\Bundle\SecurityBundle\SecurityBundle(),
            new Symfony\Bundle\TwigBundle\TwigBundle(),
            new Symfony\Bundle\MonologBundle\MonologBundle(),
            new Symfony\Bundle\SwiftmailerBundle\SwiftmailerBundle(),
            new Doctrine\Bundle\DoctrineBundle\DoctrineBundle(),
            new Sensio\Bundle\FrameworkExtraBundle\SensioFrameworkExtraBundle(),
            //new AppBundle\AppBundle()
        );

        if (in_array($this->getEnvironment(), array('api'), true)) {
            $bundles[] = new ApiBundle\ApiBundle();
            //-- Other bundle
        }
        //-- Other environments


        return $bundles;
   }
}

Answer 2

It mostly depends on bundles quality. And this how much connected they are.

I would reject point 3 at start (create different Symfony2 project for admin area and api.) - as probably you don't build two separate applications.

Have multiple kernel for different part of application (api, admin and core website)

Common problem is created by Listeners and services in container. Especially when your listener should work only in one of app contexts (api/frontend/backend). Even if you remember to check it at very beginning of listener method (and do magic only in wanted context) then still listener can depend on injected services which need to be constructed and injected anyway. Good example here is FOS/RestBundle: even if you configure zones then still on frontend (when view_listener is activated for api) view_handler is initialized and injected to listener - https://github.com/FriendsOfSymfony/FOSRestBundle/blob/master/Resources/config/view_response_listener.xml#L11 I'm not sure for 100% here but also disabling translations and twig (etc.) for API (most of api's don't need it) will speed it up.

Creating separate Kernel for API context would solve that issue (in our project we use one Kernel and we had to disable that listener - as blackfire.io profiles were telling us that it saves ~15ms on every fronted request).

Creating new Kernel for API would make sure that none of API-only services/listeners will not interfere with frontend/backend rendering (it work both ways). But it will create for you additional work of creating shared components used in many bundles inside project (those from different kernels) - but in world with composer it's not a huge task anymore.

But it's case only for people who measure every millisecond of response time. And depends on your/3dparty bundles quality. If all there is perfectly ok then you don't need to mess with Kernels.