Skip to content

Added a new article about applications with multiple kernels #6840

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
Dec 15, 2016
Merged

Added a new article about applications with multiple kernels #6840

Changes from 1 commit
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
7cb2aa1
Added a new article about applications with multiple kernels
javiereguiluz Aug 3, 2016
21329ec
Fixed some syntax issues
javiereguiluz Aug 3, 2016
a23d82d
Fixed another syntax issue
javiereguiluz Aug 3, 2016
d45e1f4
Fixed an example code
javiereguiluz Aug 3, 2016
5c8ed87
Fixed typo
javiereguiluz Aug 3, 2016
097a73d
Reworded the use cases section
javiereguiluz Aug 4, 2016
2c5aeb1
Removed a use case
javiereguiluz Aug 4, 2016
af4ff18
Added a new use case related to micro-services
javiereguiluz Aug 4, 2016
e403fd8
Added a new section about running commands under a different kernel
javiereguiluz Oct 4, 2016
2613810
Added a note about rendering templates from different kernels
javiereguiluz Oct 12, 2016
bc3618d
Made a bunch of fixes recommended by Ryan
javiereguiluz Oct 25, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Reworded the use cases section
  • Loading branch information
@javiereguiluz
javiereguiluz committed Aug 4, 2016
commit 097a73d79b4dbd4cef32fb0a50f45edb968ced40
25 changes: 17 additions & 8 deletions request/multiple_kernels.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,14 +11,23 @@ response.

This single kernel approach is a convenient default provided by the Symfony
Standard edition, but Symfony applications can define any number of kernels.
This is useful to execute the same application using a different configuration
and a different set of bundles for each kernel:

* An application that defines an API could create an ``ApiKernel`` to not have
to load all the bundles enabled in the regular web application. This will
improve the API performance;
* A bundle that doesn't allow multiple instances can define multiple
configurations in different files loaded by each kernel.
Whereas :doc:`environments </configuration/environments>` execute the same
application with different configurations, kernels can execute different parts
of the same application.

These are some of the common use cases for creating multiple kernels:

* An application that defines an API could define two kernels for performance
reasons. The first kernel would serve the regular application and the second
one would only respond to the API requests, loading less bundles and enabling
less features;
* A highly sensitive application could define two kernels. The first one would
only load the routes that match the parts of the application exposed to the
public. The second kernel would load the rest of the application and its
access would be protected by the web server;
* An application that uses a bundle which doesn't allow multiple instances could
Copy link
Contributor

@ogizanagi ogizanagi Aug 4, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this one.
It is presented as a solution to bundles registering a single service instead of allowing the creation of multiple instances through configuration. But creating new kernels has way too much impact to be considered for this use-case.
Once again, a kernel environment is probably more appropriate to define a different bundle configuration. But anyway, none of the 2 solutions would allow to make the different bundle configurations cohabit within the very same request. In my opinion, the sentence is misleading regarding this 😕.
The only solution for this use case is to not use the bundle/bundle configuration, and register services yourself.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. I'm probably going to remove this use case. I added because the other day one person asked me if EasyAdmin supported defining two different backends in the same app. The bundle itself doesn't support that ... but with this multi-kernel trick, everything is easily solved.

Can anyone think of other use cases or do we just leave the first two proposed ones? Thanks.

Copy link
Contributor

@ogizanagi ogizanagi Aug 4, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about micro-services oriented apps ? You can split your services in multiple optimized modules, allowing to enable/disable a group of micro services on a server instance, by simply exposing or not a kernel instance.
It avoids dealing with multiple git repositories and allow to share code/configuration more easily.
However, it's very close to the mentioned API use-case, but with more advanced partitioning.

Copy link
Member Author

@javiereguiluz javiereguiluz Aug 4, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's nice! I've added that use case. Thanks.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe the most common use case is the front-end/back-end sceneries, a big e-commerce application, for example ?

define two identical kernels to define a different bundle configuration for
each of them.

Adding a new Kernel to the Application
--------------------------------------
Expand Down