Laravel - высокая скорость... разработки

Удивительно, но всякий раз, когда упоминается "быстрота" Laravel, подразумевается скорость разработки на нём, а не что либо иное, что можно подумать. Когда Тэйлор Отвел (автор фреймворка) создал его упрощённую версию под названием Lumen, причиной стали несколько коммерческих заказов на разработку, их итоговый результат не совсем устраивал Тэйлора (возможно, заказчиков тоже), в основном из-за медленной работы Laravel. С чисто репутационной стороны можно понять автора популярного фреймворка, когда в реальности пришлось бы останавливать выбор на другом, например Slim, микрофреймворке, так что Тейлор мастерски вышел из сложившейся ситуации. При этом, даже Yii2, являясь полноценным фреймворком, из другой весовой категории, обгоняет микрофреймворк Lumen по первичной загрузке.

Мне нравится Laravel, но всегда хотелось, чтобы он работал быстрее, и это не только моё желание, проблема производительности неотрывно преследует проекты на этом фреймворке, практически каждый раз, когда меня спрашивают, есть ли опыт работы с этим фреймворком (положительный ответ), следующий вопрос - разбираюсь ли в оптимизации фреймворка и кода для решения проблем с его производительностью. "Больная" тема. Замечу, что ни с Yii2, ни с Symfony таких акцентов почти не было, что показательно. Потому что основная оптимизация - это все-таки оптимизация запросов и структуры баз данных, на которых приходится (должна, по крайней мере) основная нагрузка по производительности.

На начинающих проектах, стартапах, этого отставания не чуствуется, если, конечно не добить подключением чего-нибудь типа GraphQL. Что примечательно, последний также хорош для быстрой командной разработки и это его основное преимущество. Можно подумать, что есть некая зависимость между быстротой разработки и быстротой работы и нужно делать выбор в одну из сторон.

Посмотрим, что пишет на этот счёт автор учебников по Laravel, Mэт Стаффер, преподаватель и ведущий разработчик на фреймворке. В своём "Полном руководстве" по Laravel, он описывает очень многие преимущества фреймворка, совсем не касаясь производительности. В частности, он даёт краткий экскурс в историю развития фреймворка, который перескажу вкратце.

На развитие фреймворков в том виде, как они есть сейчас, в большой степени повлияла разработка Ruby on Rails. В том числе, популярный в то время CodeIgniter, медленно обновлялся и был проприетарным ПО, зависящим от решений отдельной компании. Mэт Стаффер вспоминает, что Тейлор Отвел настолько разочаровался в CodeIgniter, что начал писать собственный фреймворк и в июне 2011 года состоялся его бета-релиз. Могу понять Тейлора, так как сам начал писать свой фреймворк, разочаровавшись в скорости Laravel, при этом восхищаясь, насколько Laravel удобен и многофункционален.

При создании четвёртой версии Ларавел, его автор полностью поменял его структуру, теперь он полностью собирался из компонентов при помощи Composer, в том числе включая компоненты Symfony, но при этом появилась прямая зависимость от обновлений Symfony.

Тейлор Отвел в рекламных материалах использовал такие выражения как "быстрый", "сверхсветовая скорость" и тд. Mэт Стаффер, упоминая это, пытается объяснить следующим высказыванием:

Двумя принципами фреймворка (Laravel) являются увеличение скорости разработки и повышение удобства разработчиков.

Мне не удалось найти употребление этих слов в поиске в качестве цитаты, по крайней мере, просмотрев всю историю файла readme.md(сейчас README.md) фреймворка в github, ничего подобного не нашёл. Возможно, Мэт Стаффер имеет ввиду иные рекламные материалы того времени.

При этом в корпоративной разработке приложений выгоднее отталкиваться от удобства пользователей, а не только разработчиков. В идеальном мире это был бы баланс между тем, как скоро обновления продукта появляются и насколько хорошо они работают. Скорость отклика страниц в этом случае однозначно влияет на мнение пользователя о качестве продукта. В целом это может стать проблемой, когда всё зайдет далеко, обновления нужны продвигающим их менеджерам, скорость появления нововведений и точность их реализации главное, за что они получают премии. С другой стороны, разработчикам этих продуктов, если послушать автора Laravel в том числе, важна удобность разработки и, добавлю от себя, понятная формулировка задач. Скорость разработки заметна и выгодна всем, с этим нельзя спорить.

Получается, что скорость работы самого приложения до какого-то времени никем не принимается в расчёт пока это не становится слишком заметным. Часто это следствие большого количества вспомогательных frontend-запросов со страницы, которые должны работать почти молниеносно и с развитием проекта их число увеличивается. Но в большинстве случаев - увеличение посещаемости. Можно решить проблему частично за счёт железа и серверного софта, но повторю, время отклика приложения в данном случае не входит в ответственность ни постановщиков коммерческих задач, ни их исполнителей. Потому что завязано на выбранной технологии - фреймворке. Вы сможете это внятно объяснить пользователям, ожидающим по несколько секунд, когда хоть что-то появится на странице? А вот если бы фреймворк был самописный, разработчикам бы не удалось так просто свалить всё на рекламные материалы Тейлора. Мне попадались или полностью самописные фреймворки или переделанные из существующего под собственные нужды, что тоже как вариант контроля кода ядра приложения.

К каким ухищрениям прибегают, чтобы "разогнать" Laravel? Основной способ - кэширование всего и вся. В первую очередь кэширование маршрутов с установлением времени кэша, но с потерей сессий, что подойдёт не для всех страниц. Ещё всевозможное кэширование настроек и маршрутов, а также применение акселераторов PHP-кода. Кэширование шаблонов Blade и просто любых значений встроенными средствами (так называемыми "драйверами").

Возвращаясь к автору Laravel и той хронологии развития фреймворка, что описана выше, можно заметить, что до выпуска им первой версии уже существовала плеяда PHP фреймворков, из них, помимо упомянутого CodeIgniter, это CakePHP, Kohana, Symfony, Zend Framefork, Aura и Slim, то, что они не совсем отвечали запросам Тейлора, вполне вероятно. Но странно, что он не обратил внимание на Yii, выпущенный в 2008 году, достаточно удобный и современный для того времени.

В Ларавел много внимания уделяется красоте кода и его структуризации. Но настолько ли это важно для фреймворка? Если вы хоть раз заглядывали в исходный код известного фреймворка Fat-Free, отличающегося скоростью, но код которого минифицированный (кодовая база всего ~ 65 КБ), написанный точно не для понимания его человеком, с нарушением всех рекомендаций читабельности кода, наверное, вы были удивлены его популярностью, в конце концов многие обзоры фреймворков часто включают его наравне с остальными топами в один ряд. В сверхбыстром фреймворке Phalcon код спрятан в PHP-расширении, часто программисты, работающие с ним, даже не подозревают, как этот код выглядит. В конце концов, без возможности переделывать ядро-фреймворк проекта, только обновлять его, нужно ли следовать такой же архитектуре в самом проекте? Ничто на это не указывает, кроме личного вкуса программиста, однако при использовании Fat-Free и Phalcon врятли это может быть уместным.

Также в описании фреймворка Laravel рекомендуется для начинающих разработчиков пользоваться настройками по умолчанию, это в большинстве случаев им должно подойти. Не могу представить проект, кроме учебного, при котором на этом всё и закончится и в котором задействованы только начинающие. В реальном рабочем проекте скорее всего те самые "рамки" или "фреймы" фреймворка будут не раз испытаны на прочность изменением настроек и выжиманием из них максимума гибкости для тех или иных надобностей.

Проще говоря все обёртки над стандартными инструментами PHP, которые фреймворк должен упростить, не всегда нуждаются в упрощении. Так в чём же плюсы их применения? Можно создать быструю видимость, что проект начат, в этом преимущество фреймворка, а то что он не настроен как нужно, это дело следующего этапа работы. Можно считать, что этап подбора библиотек (тех-же из арсенала Symfony) и их подгонка для конкретной задачи (по конкретным лекалам) заменяется на установку общепринятой коллекции (готовая вещь) этих библиотек с последующей подгонкой ("под фигуру"). Но самого проекта ещё нет, его логику надо спроектировать и написать, заполнить объём рамок фреймворка. А это уже совсем другая история.