Содержание
В первой части статьи мы обсудили различия между WordPress и Laravel по части базы данных, основной структуре кода, роутингу и управлению внешними и внутренними зависимостями.
Давайте еще немного углубимся в инструментарий обеих систем.
Во многих фреймворках используется система событий (events) и слушателей (listeners).
Например, вы можете создать событие “Совершение заказа на сайте” и слушателей “Отправить письмо пользователю”, “Отправить письмо администратору” и “Создать лид в CRM”. Затем вы можете вызвать это событие в любом месте вашего проекта (контроллер чекаута, админка, API).
Такая логика помогает избежать “связывания” разных частей системы. Чем более независимы части, тем гибче и надежнее система.
В LL есть система объектных событий и листенеров. Также есть файл EventServiceProvider, в котором они описаны. Все важные события здесь как на ладони.
protected $listen = [
'App\Events\UserCreatedPayment' => [
'App\Listeners\UserCreatedPaymentNotifyAdmin',
'App\Listeners\UserCreatedPaymentNotifyUser',
],
];
В этом примере мы указываем, что на событие UserCreatedPayment должны отреагировать два листенера (слушателя) UserCreatedPaymentNotifyAdmin и UserCreatedPaymentNotifyUser для отправки уведомлений администратору и пользователю. Для того, чтобы временно отключить отправку пользователю, достаточно закомментировать 1 строку. Для того, чтобы добавить еще одно уведомление (например, менеджеру клиента), достаточно добавить 1 строку.
В WP есть хуки. Вообще, это большой успех, далеко не все CMS могут похвастаться системой обработки событий. Хуки WP это как события в LL для бедных. Есть хуки, есть листенеры, но нет ООП и все методы глобальны. В отличие от LL, нет единого списка событий, поэтому хуки могут быть определены где угодно, даже в шаблоне страницы.
Вот тут WP даст фору LL. Мне самому нравится админка WP, нравится писать там статьи, нравится, как она работает с телефона и тд. Админка бесплатная. К админке WP претензий нет.
Этим летом (2018) создатели LL выпустили Nova — первая официальная админка для LL. Стоит $100. Я купил в день выхода и не пожалел.
Nova позволяет моментально собирать интерфейсы для управления данными. Киллер-фича Новы — управление любыми связями. В WP и остальных CMS связи — головная боль разработчика и администратора.
Очень приятный и современный фронтэнд написан на vue.js, ее приятно трогать. Кроме того, это админка гораздо удобнее для модификаций, чем та же WP.
Конечно, есть и минусы молодого проекта: нет адаптивности для мобильных, есть баги, и вся функциональность пока представляет из себя не более, чем CRUD (create, read, update, delete — то есть управление различными справочниками). Однако сообщество активно пишет пакеты для Nova, а основатели активно развивают саму Nova и исправляют найденные ошибки.
Не знаю, можно ли отнести платность Новы к минусам, так как это своего рода гарантия, что проект не исчезнет.
Я готов дать обеим системам по баллу за админки, хотя и надо признать, что админка WP получает этот балл увереннее, так как она более стабильна и полностью бесплатна. Пожалуй, дам WP два балла. В порядке исключения.
Автоматические тесты — это такой код, который разработчик пишет, чтобы проверять другой свой код, который реализует бизнес-логику приложения. Автотесты выполняются только на тестовых площадках и хорошо помогают избежать регрессионных (когда новая фича ломает одну из старых) ошибок, которые неизбежны на растущем проекте. О тестах я бы написал отдельную статью, так как преимущества тестов сложно переоценить.
Также интересно упомянуть технику программирования TDD, при которой разработчик сперва пишет тест, а затем бизнес-код, который должен удовлетворить тест.
В последнее время мы покрываем тестами все наши проекты и активно осваиваем TDD.
Laravel значительно расширяет функционал библиотеки PHPUnit для создания тестов на разных уровнях:
Также Laravel поддерживает работу с транзакциями БД, создание фейковых служб (mocking) и так далее. Это необходимо для того, чтобы проверять, как веб-проект работает с каким-либо окружением.
Пример HTTP-теста, проверяющего регистрацию пользователя:
public function testUserCanRegister()
{
// Выключаем нотификации, вместо этого собираем их специальной службой
Notification::fake();
// Проверяем доступна ли страница регистрации
$this->get(route('register'))
->assertOk();
// Эмулируем запрос из HTML-формы регистрации. Проверяем, редиректит ли на страницу с успешным статусом
$this->post(route('register'), [
'name' => 'MyName',
'email' => 'example@example.com',
'password' => '1234567',
'password_confirmation' => '1234567'
])
->assertRedirect(route('register.success'));
// Проверяем, появился ли юзер в БД
$this->assertDatabaseHas('users', [
'name' => 'MyName',
'email' => 'example@example.com',
'password' => bcrypt('1234567')
]);
// Проверяем, отправлено ли юзеру сообщение
$currentUser = User::find(1);
Notification::assertSentTo($currentUser, VerifyEmail::class);
}
WP
По слухам, в WP есть автотесты, но их используют только разработчики плагинов. При желании можно настроить юнит и интеграционные тесты, но, без HTTP и браузерных тестов, это путь в никуда. HTTP-тесты я нахожу наиболее полезными для нас.
Очереди это как раз то о чем вы подумали, только вместо людей в очередь встают различные задания (отправить письмо, обработать файл, сгенерировать отчет) и ожидают они не вызова от сотрудника Почты России, а когда до них доберется обработчик.
Очереди нужны для того, чтобы пользователю не приходилось ждать. Он просто нажимает кнопку, для него в фоне создается задание в конце очереди, а пользователь дальше пользуется сайтом, делает какие-то пользовательские дела. После того, как обработчик добирается до задания этого пользователя и выполняет его (обычно это происходит очень быстро), пользователю приходит оповещение о результате операции. То есть, вся тяжелая работа выполняется в фоновом режиме.
Лайфхак! Очереди отлично подходят для отправки писем, например, по SMTP. Мы почти всегда ставим письма в очередь. Так наши формы заказов на сайтах работают на секунду другую быстрее.
Насколько я знаю, Laravel — единственный PHP-фреймворк, в котором очереди для Redis реализованы полностью из коробки и это невероятно полезно для такого синхронного языка, как PHP. Redis — это очень быстрая key-value БД, используемая для очередей, кэша и счетчиков.
Что важно, Laravel уже содержит worker (обработчик), который запускается supervisor’ом (распространенная утилита Linux) и CLI интерфейс для управления им (воркером). Воркер — вечно работающий скрипт (демон), обрабатывающий задания из очереди.
В WP с очередями нет никаких проблем, так как очередей нет и не будет. Хотя, мы используем очереди на WP, но полностью пишем их руками, повторяя логику Laravel.
Ошибки могут помогать разработчику, если правильно реализована их генерация и отлов.
В Laravel используются стандартные для PHP реализации класса Exception (исключение). Эти ошибки информативны для разработчика и их можно программно ловить и обрабатывать, например, для выполнения какой-то запасной логики или информирования администратора сайта.
Например, мне очень нравится получать отчеты о всех произошедших на сайте ошибках прямо в Slack, где их сразу же видят разработчики и менеджеры. Таким образом, мы можем сказать пользователю, что починили баг, до того, как он успеет даже сообщить о нем.
В WordPress зачем-то есть отдельный класс WP_error, который нельзя обработать как Exception. Его предназначение я так и не смог понять. Больше ничего нет.
Кэширование — сохранение результатов тяжелых операций для повторного использования. Например, фильтры по параметрам в интернет-магазинах.
Вы догадываетесь, что цифры рядом с кнопочками фильтра — это количество товаров, которое вы получите, если нажмете на эту кнопку. Так вот постоянная генерация этих цифр — на удивление тяжелая операция, она может занимать долгое время, поэтому мы можем сохранить в кэш эти цифры, когда посчитаем их в первый раз, а затем использовать снова и снова для разных пользователей, сократив время загрузки в десятки раз.
Важно понимать, что я сейчас говорю вовсе не о том кэше, который хранит браузер, а о том, который хранит сервер. Это один общий кэш для всех пользователей.
Так как кэш нужен для ускорения сайта, то он должен храниться в быстром хранилище. Обычно, для хранения кэша используют Redis или Memcached. Это key/value хранилища, которые не структурируют данные в отличие от MySQL, MariaDB или PostgreSQL. Зато их скорость работы значительно превышает последние, а это как раз то, что нужно для кэша.
Я думаю, тормоза — не новое явление для разработчиков на CMS. WP не исключение. Зато на рынке есть ряд удобных и эффективных плагинов, таких, как Fastest Cache, Super Cache и Total Cache. Эти плагины дают ощутимое ускорение, однако использование этих решений без правильной настройки принесет больше вреда, чем пользы. Несколько раз мы настраивали эти плагины под наши нужды, и, надо заметить, что время на изучение плагинов было сравнимо со временем написания собственного решения.
Тем не менее, мы зачтем и в этот раз очко в пользу WP.
Laravel имеет встроенные механизмы кэширования, из коробки работающие с Redis и Memcached. Кэш в Laravel очень просто использовать, посмотрите пример.
Cache::put('key', 'value', $minutes); // Записываем данные в кэш на заданное время
$value = Cache::get('key'); // Забираем данные по ключу key
Также Laravel сразу умеет в одно касание кэшировать все собственные относительно тяжелые места, такие как роуты, шаблоны и конфиги, что позволяет быстро подготовить систему к использованию на “продакшене”.
Закэшировать или разкэшировать Laravel можно командами:
php artisan route:cache php artisan view:cache php artisan config:cache php artisan route:clear php artisan view:clear php artisan config:clear
Планировщик — это решение, которое позволяет выполнять какие-либо задания в заданное пользователем время. Например, рассылку отчетов о продажах каждый вечер или импорт товаров по ночам.
PHP сам не умеет запускаться в нужный момент, и разработчики используют для этой задачи Cron. Cron — серверная утилита, которая умеет запускать задания в нужное время.
WP использует довольно интересное решение под названием wp_cron. Это PHP-скрипт, в который мы можем записывать задания и время их выполнения. Подход интересен тем, что не требует настройки Cron. Однако, за удобство придется платить. WP_cron, в отличие от настоящего Cron не запустится в нужное время, если на сайт в этот момент не зайдет посетитель. Кроме того, WP_cron создает солидную лишнюю нагрузку на сайт, так как проверка на запуск заданий выполняется при каждом обновлении любой страницы на сайте.
Laravel использует обычный серверный Cron. Но и тут есть интересные места. Нам не нужно настраивать Cron под каждое задание, достаточно настроить одно задание раз и навсегда.
* * * * * cd /path-to-your-project && php artisan schedule:run >> /dev/null 2>&1
Это Cron-задание будет выполняться каждую минуту.
Задания Laravel уже прописываются в специальном файле. В отличие от WP, планировщик Laravel всегда выполняет задания в срок и никак не связан с загрузкой страниц сайта.
$schedule->call(function () {
Report::sendToAdmin();
})->dailyAt('13:00');
Этот код, например, позволяет ежедневно в 13:00 отправлять администратору какой-нибудь важный отчет.
Я открою вам большой-большой секрет. Готовы?
Основатели WordPress честно создают хороший рынок для разработчиков, но есть одна проблема. Дело в том, что на этом рынке место предусмотрено только для разработчиков плагинов и тем, но не для создателей самих сайтов. Это видно по тому, как написана документация, какие существуют инструменты, да и просто видно рынку, если вариться в нем так долго, как мы.
По задумке создателей WP, разработчики должны продавать свои плагины и темы владельцам сайтов. Владельцы же не должны обладать навыками программирования, поэтому в мире WordPress есть большой спрос на гибкие решения с кучей кнопок в админке.
В мире фреймворков, и особенно в Laravel сообществе, все наоборот. Здесь целевой клиент — разработчик.
“Ага!” — скажете вы и решите, что раз вы не разработчик, то вам нужна CMS. Подождите. Но ведь клиент разработчика — вы.
Большинству наших клиентов, независимо от их компетенций, абсолютно фиолетово, как мы проектируем базу данных, четыре у нас пробела в отступах или два таба. Многие готовы доплачивать, лишь бы я не рассказывал им про разрешение зависимостей и всякое MVC. Они даже не фанатеют за красивые админки, можете себе такое представить? Главное — чтобы работало. Вот что я слышу каждый день.
Свобода это хорошо или плохо?
В нашей работе свобода зачастую означает хаос.
Как я писал выше, Laravel заставляет разработчиков стандартизировать код. Отсутствие стандартов похоже на строительство дома разными рабочими из разных материалов в разное время.
Такое хаотичное строительство создает определенные проблемы, например, вы закрыли окно новой стеной, чтобы пристроить гараж. Чтобы добавить света, сделали окно в другой стене, которая оказалась несущей. Следующее ваше решение — подпереть плечом стену, как Атлант, и позвать на помощь. И вот вы стоите и постепенно понимаете, что свобода и отсутствие планирования обернулись проблемой под названием технический долг.
На самом деле, технический долг — нормальная вещь, потому что проекты всегда делаются “на ходу”. Никто заранее не знает, как сделать все правильно от начала до конца. Технический долг выплачивается устраняется рефакторингом кода (переосмыслением и переписыванием). Рефакторинг стоит денег. В итоге мы получаем следующий вывод.
Чем больше свободы, тем дороже выйдет разработка. Взгляните на примерный график стоимости поддержки сайтов, который я накидал по своему многолетнему опыту разработки сайтов на обеих платформах.
Долгие годы я убеждал людей в том, что WordPress за счет своей популярности (CMS №1 в мире с огромным отрывом) не садит владельцев сайтов на крючок. Логика была такая: чем больше разработчиков, тем дешевле их час работы и тем проще найти нового.
Это действительно логично пока мы работаем в рамках логики WP. А, как я писал выше, до меня наконец дошло, что логика WP в том, чтобы разработчик делал плагины и темы, а не сайты.
Когда же начинаются более сложные задачи, чем разработка контентного сайта, разработчики сталкиваются с упомянутой давящей свободой и отсутствием инструментов разработки. Вследствие этого, разработчик WP начинает изобретать свой велосипед и через какое-то время от WordPress остается только приятная, но трудно редактируемая админка и база данных.
А при чем здесь крючки?
Я объясню. Для другого разработчика WP наш сайт уже не выглядит знакомым. Это не проект на WordPress, это просто проект на PHP со знакомой админкой. Поэтому новый WP разработчик скажет, что проект написан неправильно (не так, как он написал бы) и нужно все переписать (создать другой велосипед).
Laravel же (и здесь я бы выделил именно этот фреймворк) имеет жесткое разделение компонентов по MVC (Model View ControLaraveler), “файлы-карты” проекта (писал об этом выше) и ряд других ограничений и парадигм, которые помогают разработчику делать код стандартизированным и понятным другим. Конечно, Laravel не является панацеей, но по своему опыту скажу, что я в разы быстрее читаю чужой проект на Laravel по сравнению с проектом на WP, причем, если их писал один и тот же разработчик.
В предыдущем тезисе я сказал о соотношении цена/качество.
Что насчет скорости? Зависит от типа проекта.
Благодаря готовой админке и быстрому запуску на WordPress вы быстрее запустите контентный проект.
А функциональный проект, благодаря инструментарию для разработчиков, вы запустите быстрее на Laravel.
Подведем краткий итог и вспомним основные различия наших участников.
| Фича | WordPress | Laravel |
|---|---|---|
| Человекопонятная структура БД | — | + |
| Производительность базы данных | — | + |
| ORM (механизм для работы с БД) | — | + |
| Миграции БД | — | + |
| Хардкод домена в БД (это плохо) | + | — |
| MVC архитектура | — | + |
| Система роутинга | — | + |
| Механизмы разрешения внутренних зависимостей | — | + |
| Пакетный менеджер | +/- | + |
| Система событий | + | + |
| Админка | +’+ | +/- |
| Автотесты | — | + |
| Очереди | — | + |
| Обработка ошибок | — | + |
| Кэширование | + | + |
| Планировщик | +/- | + |
| Стандартизация кода | — | + |
| Ориентация на разработчика | — | + |
| Vendor-lock (это плохо) | + | — |
| Скорость разработки | +/- | +/- |
Навыки и технологии, необходимые разработчику WordPress и Laravel. Разумеется, для администратора или владельца сайта никаких специальных навыков не требуется.
| Навык | WordPress | Laravel |
|---|---|---|
| PHP | + | + |
| ООП (Объектно-Ориентированное Программирование), MVC (Model View ControLaraveler) | — | + |
| Composer (менеджер пакетов для PHP приложений) | — | + |
| Работа в терминале (консоли, CLI) | — | + |
| PHPUnit, Автотесты, TDD | — | желательно, есть предустановки |
| Git | — | желательно, есть предустановки |
| Сборщики фронтэнда | — | желательно, Webpack предустановлен |
В этом месте меня попросили сказать, для справедливости, что мы ставим Webpack, Git и Composer на WordPress. Но я покривлю душой, если скажу, что это делается по обоюдному согласию. Я вижу этот процесс примерно так.
С одной стороны, эта таблица дает очки WP, так как разработчик WP должен знать меньше, а, следовательно, он стоит дешевле. Так и есть. Это плюс.
С другой стороны, это аргумент в пользу Laravel, так как через высокий порог входа смогут перешагнуть только программисты более высокого уровня. Конечно, они дороже, но и работают более качественно. Вопрос к вам, готовы ли вы доплачивать за качество?
Для каких задач я бы посоветовал использовать эти решения.
Сейчас я бы мог посоветовать WP для контентных проектов, когда нужно о чем-то рассказать, например, о товаре, услуге, компании, мероприятии.
В этой ситуации разработчик выступает в роли разработчика кастомной темы. Большую часть функциональности (роутинг, шаблонизатор, работа с БД и админка) WP дает из коробки.
Например:
Фреймворк Laravel я бы взял для проектов, где нужно реализовать какую-то логику.
Например:
Думаю, общая логика ясна.
Может показаться, что я возненавидел WordPress, когда с ним работал. Вовсе нет. Наоборот, я до сих пор выбираю его для некоторых новых проектов.
Думаю, все дело в наших клиентах. Их планы становятся все амбициознее, идеи смелее и, черт побери, кто я такой чтобы не оправдать ваших ожиданий?
Спасибо всем тем интересным и, прямо скажем, большим людям, с которыми нам, Студии Флаг, удалось и еще удастся поработать!
