Создаем свой Фреймворк на компонентах symfony2. Часть 10

В десятой части этого цикла, мы поговорим об одном из преимуществ использования компонентов Symfony2 — совместимости между всеми фреймворками и приложениями, которые их используют. Давайте сделаем большой шаг навстречу этому качеству: пусть наш фреймворк реализует интерфейс HttpKernelInterface.

HttpKernelInterface, наверное, самая важная часть кода в компоненте HttpKernel. Фреймворки и приложения реализующие этот интерфейс полностью совместимы. Более того, эта возможность может принести вам много отличного функционала.

Усовершенствуем фреймворк, для реализации данного интерфейса:

Даже если изменения выглядят незначительными, они очень много нам дают! Одна из самых замечательных возможностей: поддержка прозрачного HTTP кэширования.

Класс HttpCache предоставляет полнофункциональный обратный прокси, написанный на PHP. Он реализует интерфейс HttpKernelInterface.

Вот и все, что нужно, что бы добавить HTTP кэширование в ваш фреймворк. Правда удивительно?
Настройка кэша производится посредством HTTP заголовков. Например, для кэширования ответа в течении 10 секунд — используйте метод Response::setTtl():

Если, вы как и я, запускаете ваше приложение из командной строки, симулируя запрос (Request::create(‘/is_leap_year/2012’)), вы можете легко посмотреть объект ответа. Его строковое представление (echo $response;), наряду с основным контентом, покажет вам все заголовки.

Что бы убедиться, что все работает, добавьте в ваш вывод рандомное число и убедитесь, что оно меняется только каждые 10 секунд.

Использование HTTP заголовков позволяет очень гибко настроить кэширование, в том числе, задать обе модели кэширования (модель “окончание срока действия” и модель “валидации”). Если вы не чувствуете себя уверено в этой теме, рекомендую почитать главу про HTTP кэширование в документации Symfony2.

Класс Response содержит много методов, позволяющих очень гибко настроить заголовки HTTP. Один из самых полезных: setCache(), который поможет задать стратегию кэширования одним массивом:

При использовании модели валидации, метод isNotModified() позволяет существенно сократить время генерации ответа тем, что дает возможность сгенерировать ответ гораздо раньше:

Использование HTTP кэширования — это здорово, но что если мы не можем кэшировать всю страничку? Что если, нам нужно кэшировать все, кроме небольшой панельки, которая чуть более динамическая чем весь остальной контент? Нас спасет Edge Side Includes (ESI). Вместо того, что бы генерировать весь контент за раз, ESI позволяет задать часть страницы, которую нужно генерировать подзапросом:

Чтобы HttpCache поддерживал эти теги, нужно передать ему инстанс класса ESI. Класс ESI автоматически парсит свои теги, и осуществляя подзапросы, заменяет их соответствующим контентом.

При использовании сложных стратегий HTTP кэширования и большого количества ESI тегов, становится довольно сложно понять, где и как страничка должна кэшироваться. Для удобного дебаггинга, вы можете включить режим отладки:

Режим отладки добавляет заголовок X-Symfony-Cache к каждому ответу, который описывает, что конкретно кэшируется.

У HttpCache огромное количество возможностей, вроде поддержки stale-while-revalidate и stale-if-error расширений, описанных в RFC 5861.

С добавлением одного интерфейса, наш фреймворк обрел много возможностей, благодаря компоненту HttpKernel. HTTP кэширование — только одна из этих возможностей, но и, пожалуй, самая главная, именно она может заставить ваш фреймворк взлететь!

К содержанию >>
Оригинал статьи на английском языке >>
Исходный код из статьи >>

Не забудьте поделиться статьей с друзьями

Подписывайтесь на меня в соц. сетях

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *