June 17, 2013

This article is part of a series of articles that explains how to pack a Symfony
full-stack application in one file. The first article explains why this might actually
be useful:
1) Introduction,
2) Bootstrapping,
...

Sometimes, I'm wondering if I'm not just completely crazy. I like small
things, but I'm the author of Symfony, a not-so-small framework (about eighty
thousand lines of code excluding comments as of today). And that's probably
because I like to push the limits of what's possible when coding.

In 1985, my first useful piece of code was about managing a portfolio of
stocks for my parents. I was twelve years old at that time. I won a contest.
It was an interesting challenge: coding a full game in less than 10 lines of
code.
And my code was published in a French magazine.

And most of the time, those experiments helped me get to the next level.
Twittee, my service container that fits in a Tweet, was an experiment, but
then, it became Pimple, a small dependency
injection container that is used today in
Silex, a micro-framework based on the Symfony
components.

So, that's not about just trying to push the limits, or trying to have fun.
It's also about experimenting different approaches to known problems and
see if they can have practical usage.

So, 2013... time for another challenge, right? What about packing a Symfony
full-stack application in a single file. No Silex, no phar allowed, no
compilation phase, just everything in a single readable file: from assets to
controllers, from templates to Composer configuration.

Why?

This is yet another step toward my Quest of the PHP Holy Grail. But besides
being a though challenge, there are many other reasons that makes it
interesting for everyone.

First, that's a good way to learn more about the Symfony internals and
especially about the Kernel class.
Nowadays, thanks to all the talks about HttpKernel given by various speakers
at various conferences, and thanks to my series of
articles
about it on my blog, a lot of developers understand how Symfony handles
requests and how it manages the conversion to responses. There is even a full
chapter
about it in the official documentation.

But the Symfony Kernel is less well-known. This is a shame as it is also a
very interesting piece of software. I hope that this challenge will give you
more information about the Symfony Kernel and that, as a result, more
Open-Source projects will adopt it instead of just using the components.

Then, I want to showcase once more the flexibility of the Symfony core
framework and the decoupling between all aspects of the framework. If you are
just a Symfony developer, you might not realize how the low level architecture
of Symfony works, and I'm going to give you some insights about it.

Also, there is a more practical usage: bug reporting. When you report a
Symfony bug, sometimes, it is not that easy to reproduce it. Probably because
it involves third-party bundles, a specific configuration, or a chain of
controller calls. For such bugs, it is almost impossible to make a patch
without a way to reproduce it. As a matter of fact, we often ask reporters to
fork the Symfony Standard Edition and modify it in a way that exhibits the
issue. But doing so is tedious for both the reporter and the developer that
will try to fix the bug. Doing the same with Silex is more easier as most of
the time, the reporter is able to package everything is a single file. So,
being able to do the same with the full-stack framework would be a huge step
forward.

Reporting bugs is fine, but being able to experiment things in a small
environment also helps. A few weeks ago, Jordi submitted a new API
layer
to simplify the configuration of Symfony's Security. To better understand how
to use it and to get a feeling for the new API, I decided to create a small
project to test different common configurations. And being able to do that in
one file would have helped me a lot.

Being able to pack a whole application in one file is also very useful when
you are teaching Symfony to someone, or if you want to show how to use a
specific Symfony feature.

Micro vs Full-Stack

So, let's sum up things a bit. I created Twitto, a micro-framework that fits
in a tweet. Then, Silex, a micro-framework based on the Symfony components.
And now, I want to make it possible to create a full-stack Symfony application
in just one file. Does it mean that Symfony full-stack is also a
micro-framework?

What is a micro-framework? Micro means "extremely small" and a framework is a
set of tools that structures an application. It abstracts the low-level
architecture of a project.

To me, micro does not mean less code. The user of a framework does not
care about the number of lines of code in the framework. It does not matter
when using the framework.

To me, micro means less structure, less constraints, less decisions made for
you. Full-stack frameworks are great as they provide a sensible default
directory structure; they come with many integrated features; they allow you
to get started faster; they allow you to easily understand what's going on on
an existing project.

A micro-framework is just about the bare minimum you need to get started. It
lets you decide which directory structure you want, it lets you decide which
feature you want to enable, it lets decide how you want to work.

Two different approaches to solve the same problem. And both have valid use
cases. So, comparing a micro-framework to a full-stack one should not be based
on the number of lines of code, but the comparison should be done on the way
you are using the framework.

The Challenge

So, is it possible to pack a Symfony full-stack application in one file? And,
is it possible to do that in less than 200 lines of code? Well, take a seat,
fasten your seatbelt, grab a coffee, and relax. I'm going to show you how I
took up the challenge in this series of articles, and along the way, I'm going
to explain how Symfony works. Hopefully, you're also going to learn a few
tricks about PHP and Symfony.

That's all for the philosophy of the challenge. Next time, we will start
tweaking the Symfony Standard Edition.

nice Fabien, even though you presented it on sflive portland it would be very educative to expound it in a series of blog posts. I did get the idea but looking at the details would be even better. Going to read Jordi's API thing on security now. Thanks!

This will be great for me at the moment. I am now in the process of creating a project using symfony components. It 's only the KERNEL that took me a while to understand the structure. Will be waiting for the chapters.