add a cookbook entry about how to have multiple kernels

[lsmith77]

this could be based on https://github.com/liip/sf2debpkg

[weaverryan]

I think if we can find a decent use case (and then strongly warn people that they probably don't need this), then I think it's a great idea. I want to make sure that even if we teach people how, we make sure they ask whether or not they actually need this :).

[wouterj]

when this is documented, we can link to it from reference/configuration/kernel

[mpdude]

You think #2465 solved this?

If not, what do you think is missing?

[wouterj]

I like to have some stronger warning that you properbly do not need this.

And I like to have some interlinking from reference/configuration/kernel#kernel.name

[mpdude]

As to kernel.name, by coincidence I came across that today. I did not really see what it is important for and how it should be best chosen. If you can help me to understand that I'd be glad to improve the docs.

Update: Same for the kernel.root_dir. What should that best point to and is it important for anything besides being a base for the cache and logs dir?

[wouterj]

Well, first of all, I maened we cannlink to this article from the kernle.name setting description.

The kernel name is used when generating the classes for the container or routing. The default value will work in most of the cases and you won't worry about it.

The kernel.root_dir is the only path that is known by symfony. All included configuration and other things are based on it. This one usually don't need to be overriden too.

Please note some comment by stof:

The case where it is useful is having several kernels (in which case you still don't care about the values as long as they are different) but the default value should be still enough most of the time as the easiest way to achieve multiple kernels (i.e. without having to overwrite lots of stuff) is simply to duplicate the structure of the app folder in a different folder (the name of the kernel defaulting to the name of this folder)

That's something different than the cookbook article explains it:

When putting multiple Kernels into a single application, it might therefore make sense to add additional sub-directories, for example app/admin/AdminKernel.php and app/api/ApiKernel.php

[stof]

@wouterj The issue with moving the structure of app in subfolder is that it requires changing the Assetic config for the path accessing the web folder whereas my solution keeps the same path

[cordoval]

@weaverryan why would they don't strongly need this? I have been in places where we implemented this and also I got advised back long ago by merk about this too. Usually the use case is a front end with a quick rest api. If you can shed light please it would be great. Thanks man!

[weaverryan]

@cordoval strongly warn people about not doing this until they have a good use case. An API versus a normal app seems like a good use-case.

[javiereguiluz]

@kbond I've just read this comment that you made on Bundles, No Bundles and AppBundle in 10 Steps:

I thought multi-kernel projects were rare but after talking to some people in NY it is not as rare I thought... But, I wouldn't say it is common and it requires some advanced knowledge.

Could you please share with us some of those multi-kernel projects scenarios? This is something we want to document since a lot of time ago and we need someone to outline some basic ideas for the cookbook. Thanks in advance for your help!

[weaverryan]

And I had the same experience as @kbond - I was surprised (at least by conference-goers) by how many people had multiple kernels. @meandmymonkey also mentioned some use-cases beyond an API backend and web frontend, like a kernel just for commands (the advantage being the kernel is a bit slimmer, which is not important for many, but important if you're squeezing performance).

I still think that most people don't need this, but it's definitely a legitimate use-case, and this entry would really be quite simple to write. @javiereguiluz thanks for re-pinging :).

[kbond]

@javiereguiluz the only scenarios I can recall are the ones Ryan mentioned. I think there was a comment from the audience during one if the talks (maybe Fabien's) about a multi Kernel environment but I can't remember their scenario.

[wouterj]

Recently, I had a very slow dev environment due to some 3th party bundles with lots of templates. It made the twig cacher very slow and with that, also each request in dev.
Since I needed the bundles only on some routes, I did create a kernel just for those bundles. This way, most of the site had a quick dev environment. In production, I just used the full kernel (with all bundles).

I don't know if this is a good practice though...

[stof]

Having a different kernel in prod and dev looks really weird to me.

@kbond the common use case for multiple kernel IMO is having an API and a website in the same project. The API can use a separate kernel, allowing to avoid loading a bunch of bundles it does not need (related to the website stuff) and loading other bundles which should affect only the API (FOSRestBundle for instance)

[weaverryan]

+1 for the example with a "website" (frontend) and an API. It works especially well since you can show how some API-related bundles don't need to be enabled for the "website" kernel. I don't think this entry needs to be huge - just highlight some directory structure stuff, show how you have different bundles registered (but you use some bundles on both), and why you would use this approach.

[weaverryan]

Boom!