PHPixie проти Laravel

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

Система версій
Варто зауважити, що обидва фреймворку пройшли довгий шлях, і якщо ви були знайомі з ними 2 роки тому, то швидше за все зовсім не пізнаєте їх сьогодні. У цьому вони обидва відрізняються від Symfony, який змінюється набагато повільніше, і навіть різниця між версіями 2.7 3.0 і не дуже велика. Втім, якщо порівнювати з дистрибутивами linux, то 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 App\User::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 фреймворку, як і у порівнянні з дистрибутивами Linux на початку статті. PHPixie це компоненти, які намагаються бути на крок попереду і націлені більше на досвідчених розробників ніж на новачків і швидкість розробки.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.