Давайте попробуем понять чем отличаются эти 3 достаточно популярных решения для разработки веб-продуктов на PHP. Что лучше? Symfony, Laravel или WordPress?
С одной стороны, все 3 платформы позволяют решать любые задачи из мира веб-разработки и они очень похожи. Вы можете сделать сайт, блог, магазин, маркетплейс, CRM, трекер задач или все что угодно. Ограничение только в головах и наличии знаний в команде разработки.
С другой стороны у каждой платформы есть свои фишки и некое назначение.
WordPress — это про модульную сборку и типовые решения
Есть такие дома из модулей типа контейнеров. Вот это похоже на WordPress.
Вы можете взять готовые блоки и собрать что нужно. Подход типа NoCode.
Да иногда надо уметь их соединять — но это все минимум кода — LowCode.
Вот только разработка таких модулей — не самая простая задача. Особенно в контексте MVC & DDD архитектур, которые в моде последние лет 10-20.
У WP архитектура на основе модулей и сообщений. А она крайне не привычна для большинства продвинутых разработчиков воспитанных на MVC & DDD идеях.
Плюс там не хватает разных модулей для highload. Их не проблема поставить или разработать, если знать как это делать. Но в мире WP не так много прогеров, которые умеют такое делать. По этой причине highload продукты на WP встречаются редко, но бывают.
Есть такая штука что вы можете допилить все что вам нужно и поменять любую часть системы создав 1 php файл и 3 строчки кода. Если хочется писать минимум кода то это круто.
Полная свобода, пиши что хочешь и как хочешь. В любом стиле.
Но это круто когда ты 1, или в команде 3-4 спецназовца с высоким уровнем знаний.
А вот если у тебя в команде 5-7 человек, с разными уровнем знаний? Вот тут бывают проблемы, потому что свобода ведет к конфликтам. Очень сложно выстроить правила и ограничения, которые создадут ожидаемое поведение кода. Другими словами ты не всегда сможешь угадать кто куда какой файл запилил и где именно находится механизм который начал глючить. Особенно если в команде есть джуны и они там могут творить абсолютно непредсказуемые маневры 🙂
Потому в индустриальной разработке такое обычно не применяется. Там все пересрутся и подерутся.
Картинка выше это ожидания. Но реальность часто бывает другой 🙂 Зачастую низкой квалификации разработчиков хватает только на то чтобы собрать бытовку.
Laravel — это про уникальные решения
Если у вас более менее уникальный функционал, далекий от типовых решений. То Laravel может быть хорошим решением. Он ближе к понятиям MVC архитектуры.
С одной стороны он уже лучше заточен под команду, там есть больше соглашений и ограничений. Тяжелее прострелить себе или коллеге ногу.
С другой стороны если пытаться на нем делать типовые решения, то оно будет заметно дороже чем на WordPress.
Что чего то дописать — не достаточно сделать 1 файл и 3 строчки. Надо уже соблюдать соглашения. Делать классы и файлы согласно архитектуре. В соответствующих папочках.
Это заметно увеличивает количество кода. Но зато дает предсказуемость. Которая важна в команде.
Если 1 разработчик что то поменял, то другие более менее смогут угадать где именно эти изменения.
Переиспользование кода не так круто как в WordPress. По этой причине на Ларе не так много типовых решений и плагинов с бизнес логикой.
Но если система не очень большая, то можно сделать более элегантную архитектуру. Опять же если уметь.
Картинка выше это про ожидания.
В реальности чаще получается что то такое:
Symfony — это про индустриальную разработку
Если сравнивать количество кода которое надо написать для создания условного магазина, то в Laravel его придется писать сильно больше чем в WordPress. Но это детский сад в сравнении с тем что придется писать в Symfony )
В симфе на каждую историю надо писать еще больше кода. Там сильно больше слоев абстракции. И все это обычно имеет смысл в индустриальной разработке каких то больших систем и микросервисов.
Обычно разработка на Symfony очень близка к идеям DDD. Из коробки вам дается просто обработчик HTTP запросов. Нет ни БД, ни кешей, ни пользователей. Ничего.
Но далее включаются соглашения и практики из индустриальных команд. Надо чтобы сущности были отделимы от БД. Потому пишутся дополнительные слои абстракции. Тут нет модели как в Ларе которая умеет все. Тут на каждую таблицу надо написать сущность, для нее DTO, репозитории чтобы это все можно было как то хранить и передавать в разные БД и каналы обмена. Например хранить это в PostgreSQL, в Redis, в ElasticSearch, передавать в RabbitMQ …
Это все частые атрибуты в индустриальной разработке и системах с highload.
Но тут также бывают факапы.
Edge кейсы и выводы
В общем на любой из этих платформ можно сделать что угодно. Вопрос лишь в том что у каждой из них есть особенности, которые чуть лучше или чуть хуже подходят под те или иные контексты.
Рассклад примерно такой:
- Симфа лучше заточена под сложные большие индустриальные системы. С очень большими бюджетами.
- Лара лучше заточена под работу команды и не очень большие системы. Средние бюджеты.
- ВордПресс лучше заточен под быструю сборку типовых решений из готовых модулей. Минимальные бюджеты.
На Ларе или ВордПресс тоже можно делать очень большие и нагруженные системы. Но во первых это надо уметь делать, а во вторых там бюджеты будут такими же. Сложные системы стоят дорого. И не важно на какой платформе.
А бывают такие кейсы, когда на Симфе пытаются сделать переиспользование бандлов с бизнес логикой. И это сложно. Тут Симфонистам не помешал бы опыт ВордПресс. Но его там обычно нет. И там при росте проекта до 50-100 человек и 10-20 команд, при переиспользовании большого объема кода между командами начинает ад блокировок.
В Laravel есть кейсы где это смогли порешать, например FreeScout. Но они как раз почти целиком слизали модульную архитектуру с обменом сообщений и диспетчером хуков из WordPress 🙂
Потому не все всегда и везде, а кое что иногда и местами.
По большей части успех зависит от ценности продукта, от адекватности руководства и уровня развития команды.
А фреймворк — играют очень малую роль.
Все споры среди программистов от низкой квалификации. И потому что каждый кулик хвалит свое болото )
Наставничество и сопровождение проектов
Если интересно снизить риски и повысить продуктивность разработки, то могу предложить вам услугу сопровождения и наставничества https://wpcraft.ru/wordpress-woocommerce-mentoring/
document.addEventListener(‘click’, function(event) {
var el = event.target;
var actionClassName = ‘action-like-post’;
if (el.parentNode.classList.contains(actionClassName)) {
el = el.parentNode;
}
// console.log(event.target.classList);
// console.log(event.target.parentNode.classList);
if (!el.classList.contains(actionClassName)) {
return;
}
var postId = el.getAttribute(«data-postid»);
var url = wpApiSettings.root + ‘u7/v1/likes/’ + postId;
// console.log(url);
var fetch_options = {
method: ‘POST’,
headers: {
‘Content-Type’: ‘application/json;charset=utf-8’
},
body: JSON.stringify({
‘postId’: postId
})
};
// console.log(url);
fetch(url, fetch_options)
.then(response => {
response.json().then(data => {
if (data.likes_count) {
// console.log(el.getElementsByTagName(‘span’)[0]);
el.getElementsByTagName(‘span’)[0].innerHTML = data.likes_count;
}
});
});
});
Источник: https://wpcraft.ru/blog/v-chem-raznicza-mezhdu-wordpress-symfony-laravel/
