PHPixie против Laravel

в 10:10, , рубрики: framework, laravel, php, phpixie, Разработка веб-сайтов

image
Главной причиной написания этой статьи является то что этот вопрос мне задают практически регулярно и было бы хорошо просто иметь под рукой ссылку. Сразу же скажу что холивора в силе Emacs против Vi тут не будет, как и любой попытки сильно упрекнуть Laravel. Уже никто не сомневаются что он работает, на нем крутятся сайты и ничего плохого с ними не происходит, так что глупо утверждать что он чем-то плох. Я же хочу показать какую нишу старается занять PHPixie и Laravel тут просто как пример, так что я надеюсь что читатель воспримет статью как обзор в стиле HTC против Samsung, призванную показать преимущества и разницу в парадигме, но никак не постулировать кто лучше.

Система версий

Стоит заметить что оба фреймворка прошли долгий путь, и если вы были знакомы с ними 2 года назад, то скорее всего совсем не узнаете их сегодня. В этом они оба отличаются от Symfony, который меняется намного медленнее, и даже разница между версиями 2.7 и 3.0 не очень большая. Впрочем если сравнивать с дистрибутивами линукса, то Symfony похож на Debian, Laravel на Ubuntu а PHPixie на Arch. PHPixie использует rolling-release подход, и все новые фичи и багфиксы сразу попадают в мастер и получают тег версии, что делает их доступными максимально быстро. Но «composer update» придется делать более аккуратно, и следить за изменениями. Тут сразу напомню что если вы используете «composer install» то устанавливаете всегда одну и ту же версию, и никаких сюрпризов ждать не приходится. Такой подход заставляет разработчика фреймворка думать о обратной совместимости, и не ломать существующее API. Как результат вы апгрейдите свой код по чуть-чуть вместе с фреймворком, и вам не надо потом думать о прыжках в стиле Laravel 4 к Laravel 5, где в один момент поменялось все, а код на Laravel 4 теперь считается legacy.

Скорость работы

Со скоростью в PHPixie все осталось по старому, она дальше столь же быстра, так как код роутинга и самого ядра практически не изменялся, она лишь обросла новыми библиотеками, которые влияют на скорость только тогда когда вы их используете. Бенчмарки от Techempower показывают что Laravel даже на HHVM не может догнать PHPixie на PHP. В принципе я редко слышу чтобы Laravel хвалили за скорость работы, её больше хвалят за скорость разработки, так что скорее всего производительность просто никогда не была в ней приоритетом.

Порог входа

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

Работа с БД

Компоненты Database и ORM развивались наиболее сильно и являются одними из лучших частей фреймворка. Только несколько месяцев назад ORM начал поддерживать Nested Sets, при этом применяя техники оптимизации. Модели четко распределены на репозитории, запросы и сами сущности. Вместо наследования какого-то базового класса модели расширение осуществляется путем паттерна Декоратор что делает ваш код совсем независимым от самой логики работы с базой и элементарно тестируемым. Даже для построения запросов можно использовать несколько вариантов синтаксиса. Ну и конечно киллер фича что все это работает как с SQL базами данных, так и с Mongo, включая связи между сущностями в разных базах. Тут Laravel сильно проигрывает, так как Eloquent не ушел далеко от Kohana ORM и PHP ActiveRecord. Большинство опытных разработчиков при работе с Laravel используют либо Doctrine, либо Propel. Опять же это все зависит от ваших задач, для большинства CRUD приложений Eloquent работает весьма хорошо.

Сообщество

Laravel разработчиков несомненно намного больше, как и митапов и фриланс заказов для них. Единственное чем может крыть PHPixie это наш чат, в котором меня можно найти каждый день и большинство проблем решается прям там на месте. Кстати если пользователей в чате после написания этой статьи прибудет, то я буду очень рад. Даже если вы не используете PHPixie, все равно заходите к нам, даже с Laravel сумеем помочь если что.

Тесты

PHPixie известна своим 100% покрытием тестами. Это число недавно чуть уменьшилось для фреймворка в целом так как вышли 3 новых компонента, к которым пока еще и документации нет, и тесты там только в процессе, но через короткое время вновь будет 100%. Тут кстати важно не только само покрытие кода, но и его тестируемость. Отсутствие магии и фасадов как раз и позволяет писать короткие и быстрые юнит тесты к отдельным классам без необходимости поднимать кучу зависимостей на каждый тест. В Laravel тесты конечно тоже есть, но гораздо меньше, и кстати на гитхаб странице проекта нет бейджа с процентом покрытия, и даже нагуглить этот процент мне не удалось, так что его явно не афишируют. Я не поленился, и сам запустил тесты и сгенерил статистику, вот результат:

image

Кстати при попытке запустить тест на свежем PHPUnit при включении генерации покрытия просто выкидывает ошибку.

Роутинг

Тут у нас вновь разница парадигм. Laravel как более монолитный фреймворк предоставляет возможности байндинга к моделям, позволяя полностью пропустить код контроллера, например:

$router->bind('user', function ($value) {
    return AppUser::where('name', $value)->first();
});

Также большинство роутов имеют имя а динамический роутинг полностью отсутствует (но его можно симулировать). Компонент роутинга PHPixie более автономный, и даже понятия контролера в нем самом нет, все что он делает это парсит запрос в набор параметров и передает их пользователю. В свою очередь это позволяет более гибкую настройку с вложенными правилами и префиксами. Еще одно отличие в том что в PHPixie роуты хранятся в файле конфигурации массивом а в Laravel задаются программно что более удобно если есть IDE с подсказками.

Шаблонизатор

PHPixie использует ПХП как шаблонизатор, а это означает что все привычные функции например ucwords, substr, trim итд. уже доступны и новый язык учить не придется. PHPixie сумела получить все преимущества популярных шаблонизаторов не прибегая к компиляции, так что с ней вам тоже будут доступны как и наследование шаблонов так и поддержка блоков. В добавок у вас будет полная подсветка синтаксиса в любом IDE и отладка с Xdebug. Кстати как я показывал в предидущих статьях, этот шаблонизатор позволяет прикрутить любой синтаксис, например HAML, в считанные минуты. Laravel Blade же сам по себе ничем особо не отличается от Twig, только синтакс чуть отличается, но ничего нового он не приносит.

HTTP

PHPixie построен на PSR-7, он расширяет его функционал добавляя свои врапперы, но вы всегда можете получить доступ к чистому PSR-7 запросу. Также он может принимать запросы из вне, что позволяет запустить фреймворк например на ReactPHP безо всяких усилий. Это также стало возможно благодаря stateless архитектуре, вместе с ReactPHP это означает что после выполнения запроса фреймворк остается таким как был до него и может сразу обрабатывать следующий без перезапуска. Laravel построен на HTTP компоненте Symfony, который строит свои запросы, и превратить их в PSR-7 можно только используя symfony/psr-http-message-bridge, что как минимум добавит оверхеда на каждом запросе. Хотя скорее всего в следующей версии Laravel перейдет на PSR-7 полностью.

Аутентификация

Добавить аутентификацию в Laravel очень просто, конфигурация доступна фактически из-коробки, но вот имплементация до сих пор оставляет желать лучшего. Уже была статья о том как Laravel просто проверяла зашифрованную айдишку пользователя в кукисах, и как это удалось эксплуатирвать. Проблема была не так в шифровании а в нестрогой проверке результата используя '=='. Дыру починили, но теперь сделали другую. В документации по «remember_me» вы увидите что токен авторизации хранится один для всей учетной записи, то есть если его украсть можно логинится с ним до тех пор пока он валиден. В PHPixie имплементация «remember_me» построена на лучшых практиках, когда у каждого девайса для одной учетной записи хранится свой токен, и при этом он еще и обновляется при каждом использовании. Красть такой токен смысла нет как раз ввиду его одноразовости. Если вам интересна полная процедура, то она описана в известно ответе на Stacokverflow. Также настройка авторизации в PHPixie намного гибче, вы можете создавать несколько токенов, использовать сессию или только кукисы и теперь так же социальную авторизацию, все в одном конфиге.

Компоненты

Laravel как и PHPixie состоит из компонент, и использовать например Eloquent без самого фреймворка очень просто. Но вот другие компоненты, например той же аутентификации завязаны на сам фреймворк гораздо больше, и использовать их с другим фреймворком так легко не получится. PHPixie же изначально задумывалась как независимые компоненты, показательно что на гитхабе каждый компонент PHPixie в отдельном репозитории, в то время как Laravel хранит все в одном проекте и предоставляет read-only репозитории для компонент.

На этом я наверное закончу, а то и так уже слишком длинно получается. На конец только замечу что ни в коем случае не считаю Laravel плохим или даже хуже. Я хотел лишь показать нишу PHPixie как более cutting-edge фреймворка, как и в сравнении с дистрибутивами Линукса в начале статьи. PHPixie это компоненты которые стараются быть на шаг впереди и нацелены больше на опытных разработчиков чем на новичков и скорость разработки.

Автор: jigpuzzled

Источник

Поделиться новостью

* - обязательные к заполнению поля