Create your own framework... on top of the Symfony2 Components (part 10)

Fabien Potencier

January 21, 2012

This article is part of a series of articles that explains how to create a framework with the Symfony2 Components: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12.

In the conclusion of the second part of this series, I've talked about one great benefit of using the Symfony2 components: the interoperability between all frameworks and applications using them. Let's do a big step towards this goal by making our framework implement HttpKernelInterface:

namespace Symfony\Component\HttpKernel;
 
interface HttpKernelInterface
{
    /**
     * @return Response A Response instance
     */
    function handle(Request $request, $type = self::MASTER_REQUEST, $catch = true);
}
 

HttpKernelInterface is probably the most important piece of code in the HttpKernel component, no kidding. Frameworks and applications that implement this interface are fully interoperable. Moreover, a lot of great features will come with it for free.

Update your framework so that it implements this interface:

<?php
 
// example.com/src/Framework.php
 
// ...
 
use Symfony\Component\HttpKernel\HttpKernelInterface;
 
class Framework implements HttpKernelInterface
{
    // ...
 
    public function handle(Request $request, $type = HttpKernelInterface::MASTER_REQUEST, $catch = true)
    {
        // ...
    }
}
 

Even if this change looks trivial, it brings us a lot! Let's talk about one of the most impressive one: transparent HTTP caching support.

The HttpCache class implements a fully-featured reverse proxy, written in PHP; it implements HttpKernelInterface and wraps another HttpKernelInterface instance:

// example.com/web/front.php
 
use Symfony\Component\HttpKernel\HttpCache\HttpCache;
use Symfony\Component\HttpKernel\HttpCache\Store;
 
$framework = new Simplex\Framework($dispatcher, $matcher, $resolver);
$framework = new HttpCache($framework, new Store(__DIR__.'/../cache'));
 
$framework->handle($request)->send();
 

That's all it takes to add HTTP caching support to our framework. Isn't it amazing?

Configuring the cache needs to be done via HTTP cache headers. For instance, to cache a response for 10 seconds, use the Response::setTtl() method::

// example.com/src/Calendar/Controller/LeapYearController.php
 
public function indexAction(Request $request, $year)
{
    $leapyear = new LeapYear();
    if ($leapyear->isLeapYear($year)) {
        $response = new Response('Yep, this is a leap year!');
    } else {
        $response = new Response('Nope, this is not a leap year.');
    }
 
    $response->setTtl(10);
 
    return $response;
}
 

If, like me, you are running your framework from the command line by simulating requests (Request::create('/is_leap_year/2012')), you can easily debug Response instances by dumping their string representation (echo $response;) as it displays all headers as well as the response content.

To validate that it works correctly, add a random number to the response content and check that the number only changes every 10 seconds:

$response = new Response('Yep, this is a leap year! '.rand());
 

When deploying to your production environment, keep using the Symfony2 reverse proxy (great for shared hosting) or even better, switch to a more efficient reverse proxy like Varnish.

Using HTTP cache headers to manage your application cache is very powerful and allows you to tune finely your caching strategy as you can use both the expiration and the validation models of the HTTP specification. If you are not comfortable with these concepts, I highly recommend you to read the HTTP caching chapter of the Symfony2 documentation.

The Response class contains many other methods that let you configure the HTTP cache very easily. One of the most powerful is setCache() as it abstracts the most frequently used caching strategies into one simple array:

$date = date_create_from_format('Y-m-d H:i:s', '2005-10-15 10:00:00');
 
$response->setCache(array(
    'public'        => true,
    'etag'          => 'abcde',
    'last_modified' => $date,
    'max_age'       => 10,
    's_maxage'      => 10,
));
 
// it is equivalent to the following code
$response->setPublic();
$response->setEtag('abcde');
$response->setLastModified($date);
$response->setMaxAge(10);
$response->setSharedMaxAge(10);
 

When using the validation model, the isNotModified() method allows you to easily cut on the response time by short-circuiting the response generation as early as possible:

$response->setETag('whatever_you_compute_as_an_etag');
 
if ($response->isNotModified($request)) {
    return $response;
}
$response->setContent('The computed content of the response');
 
return $response;
 

Using HTTP caching is great, but what if you cannot cache the whole page? What if you can cache everything but some sidebar that is more dynamic that the rest of the content? Edge Side Includes (ESI) to the rescue! Instead of generating the whole content in one go, ESI allows you to mark a region of a page as being the content of a sub-request call:

This is the content of your page
 
Is 2012 a leap year? <esi:include src="/leapyear/2012" />
 
Some other content
 

For ESI tags to be supported by HttpCache, you need to pass it an instance of the ESI class. The ESI class automatically parses ESI tags and makes sub-requests to convert them to their proper content:

use Symfony\Component\HttpKernel\HttpCache\ESI;
 
$framework = new HttpCache($framework, new Store(__DIR__.'/../cache'), new ESI());
 

For ESI to work, you need to use a reverse proxy that supports it like the Symfony2 implementation. Varnish is the best alternative and it is Open-Source.

When using complex HTTP caching strategies and/or many ESI include tags, it can be hard to understand why and when a resource should be cached or not. To ease debugging, you can enable the debug mode:

$framework = new HttpCache($framework, new Store(__DIR__.'/../cache'), new ESI(), array('debug' => true));
 

The debug mode adds a X-Symfony-Cache header to each response that describes what the cache layer did:

X-Symfony-Cache:  GET /is_leap_year/2012: stale, invalid, store
 
X-Symfony-Cache:  GET /is_leap_year/2012: fresh
 

HttpCache has many features like support for the stale-while-revalidate and stale-if-error HTTP Cache-Control extensions as defined in RFC 5861.

With the addition of a single interface, our framework can now benefit from the many features built into the HttpKernel component; HTTP caching being just one of them but an important one as it can make your applications fly!

Discussion

gravatar Lukas Kahwe Smith  — January 22, 2012 09:46   #1
It should be noted that despite implementing the HttpKernelInterface its still the implementors job to ensure that they do not rely on "global" request states.

Aka if during development one maintains a global request state to implement the application, instead of explicitly passing any state that is needed inside a sub request, one can end up having surprises when one then switches to HttpCache later on.

This is one of the things that Symfony2 helps you with by having added scopes to its Dependency Injection Container:
http://symfony.com/doc/2.0/cookbook/service_container/scopes.html

Optionally injecting the request instance into action methods is another step to reduce the need for the above mentioned "request" scoping of services:
http://symfony.com/doc/2.0/book/controller.html#book-controller-request-argument
gravatar Alessandro Desantis  — January 22, 2012 12:18   #2
You should add that the cache directory must have the right permissions, otherwise caching will just fail silently (that's what happened in my case, at least).
gravatar Larry Garfield  — January 22, 2012 22:23   #3
I'm loving this series, Fabien.

Question here, though. The potential benefits of HttpCache are obvious, but what is not is how to switch modes on the fly. For instance, you note in the article that for the ESI cache to work you need to have Varnish or similar setup. That's well and good, but as above that means the entire application must change (in the template above, as well as in Framework) to structure around ESI. That means you couldn't even do development without it.

Obviously changing the Framework code is just an if() statement to pass in an ESI object or not (or similar), but what about the implications for the rest of the application?

(I hope subrequests are next on the list. ;-) )
gravatar Fabien Potencier  — January 23, 2012 08:01   #4
@Larry: HttpCache actually supports ESI too. So, in the development environment, you can use HttpCache as a reverse proxy and switch to using Varnish in the production environment. Moreover, I have not mentioned that Symfony is smart enough to detect if there is a proxy able to understand the ESI tags and it automatically falls back to content inlining if that's not the case.
gravatar Sebastian G√∂ttschkes  — January 23, 2012 23:09   #5
I may sound a bit dumb, but how to I run a Request from command line?
gravatar Fabien Potencier  — January 24, 2012 10:21   #6
@Sebastian: Just run "php web/front.php"
gravatar Yura Uvarov  — January 24, 2012 19:53   #7
Thanks. What about Varnish and cookies? https://www.varnish-cache.org/docs/2.1/tutorial/cookies.html
What is the best practice of Varnish's cookies issue?
gravatar Kamil Ronewicz  — February 11, 2012 11:09   #8
Hi i can't undestand the ESI how to build the request in our framework to test it how it works ?