Долго откладывал, но всё-таки добрался до разбора интервью с Taylor Otwell (далее по тексту T - для сокращения) на YouTube-канале ThePrimeTime. Признаюсь, формат интервью с разработчиками мне казался скучным. Редко когда узнаю что-то полезное, но всё-таки у меня канал и комьюнити посвящены Laravel и просто обязан знать все новости, а также планы T. И я не пожалел - несмотря на то что брали интервью его фанаты, и каверзных вопросов не было, интервью было интересным и очень важным. T дал понять, куда движется развитие Laravel и почему был выбран именно этот маршрут. Забегу вперёд - хейтеры Laravel будут очень довольны ?.
Сразу скажу, что местами при чтении моего обзора будет складываться впечатление что и я хейтер Laravel, но друзья это не так, просто выбрал стиль небольшого (но вредного) критика, чтобы читать было интереснее. На самом деле я уважаю T, его фундаментальный продукт - Laravel, а также труд и вклад в PHP сообщество. Знакомство с миром Laravel сильно изменило мою жизнь к лучшему. Конечно, у меня есть мнение (как наверняка и у вас), как надо сейчас поступать T. Но об этом поговорим как-нибудь в другой раз.
Too dumb for React
Вопрос к T почему изначально выбор пал на Vue в экосистеме Laravel, а не React - на мой взгляд стал "гвоздём программы".
"Too dumb for React, enjoying Vue" - ответил T.
Приятная самоирония меня улыбнула, но это фраза — основа ответов на многие вопросы. Не смог T понять React и выбрал Vue - потому что Vue проще.
Далее T признаётся, что Laravel Cloud использует стек Inertia + React. В этом проекте React отлично вписался, так как имеет больший набор готовых компонентов. T всё ещё с React не смог разобраться, но уже достаточно зарабатывает и может позволить себе нанять разработчиков, которые хорошо разбираются в React. Про команду Laravel и то насколько T им доверяет мы ещё обсудим.
Много знать плохо
T делится своим отношением к Inertia. Считает что большое преимущество Inertia в том, что она не требует изучения чего-то нового, и является просто мостом между хорошо известными инструментами, и при этом позволяет в разы экономить время на разработку.
Полностью согласен с T. Кстати говоря все проекты из экосистемы CutCode написаны на Laravel + Vue + Inertia и на данный момент приносит только позитивные эмоции. На днях же выйдет Inertia v2, а я давно ничего не снимал по ней на канал. Может пора сделать новый видеогайд по Inertia?!
Собственно здесь и ответ на вопрос, почему T не применяет Livewire или Hotwire?. T за простоту - чем меньше фреймворков, в которые нужно вникать, тем лучше.
Мы играем хиты для фанатов
Далее был интересный вопрос о хейте Laravel, и, в частности, о основных направлениях ненависти, а именно ORM и Queue.
T сказал, что фанаты любят ORM в том виде, в каком он есть и то же самое про очереди. T прислушивается к фанатам и работает именно для них. Философия Laravel — низкий порог входа и охват большинства. Как вывод - основные хиты рок-группа "Laravel" играет для фанатов, а хейтеров даже не пускают на концерт!
Напомню, что ежегодно T проводит опрос в Laravel комьюнити - stateoflaravel.com, где больше 80% респондентов согласны/полностью согласны, что Laravel Framework движется в правильном направлении.
Кстати, ORM переписывали три раза и мнение T, что сейчас она идеальна. Нам приходится ему верить. ?
Да T считает, что их система очередей очень умная, ведь она умеет сериализовать и гидрировать модели, это прям революция ?. Но мне показалось немного странным, что сравнивает он её с реализациями в JS фреймворках, а не с той же Symfony или хотя бы Битриксом. ?
Дормамму* ты не пройдёшь!
*могущественный персонаж-плохиш вселенной Marvel
Важная часть интервью с ответом на многие вопросы началась, когда T рассказывал о том, как он поддерживает исходный код Laravel и каков его вклад в ревью пулл реквестов.
Каждый Pull Request лично проверяет T и именно он жмёт кнопку смержить или же закрыть PR. Каждая строчка кода должна быть в стиле Laravel! Для T важно, чтобы исходный код не превратился в кашу стилей от разных разработчиков со своим бэкграундом и поэтому он лично всё перепроверяет. И даже если код работает и выполняет свои задачи, но по стилю и красоте не нравится T, то он его может даже закрыть и сделать самостоятельно, но так как видит именно он.
Тут же можно вспомнить начало интервью, про "too dumb" и получается, что если T не понимает или ещё не знаком с чем-то новым (а как мы уже поняли, изучать новое он не очень любит), то высока вероятность отказа. Так что забудьте о более глубокой интеграции с Longrunning и выходом в этом вопросе за пределы HTTP, то же самое касается и очередей, где выбрана нативная PHP сериализация, имеющая множество хейта.
Да и в целом T присматривается к автору PR, ему может показаться, что вы не фанат и язвите и потому вам с Laravel не по пути - закроет PR и попросит Nuno Maduro написать то же самое.?
Но я считаю очень круто, что T настолько сильно вовлечён, продолжая уже много лет каждый день даже в отпуске заходить на GitHub и не прекращая развивать код. Хотя на T ещё куча дел по управлению проектом!
Команда как ключевой фактор успеха
T большое внимание уделяет команде (снова вспоминается фраза про "too dumb"). Работой над Laravel занимается команда суперпрофессионалов. Например, T даже не приходится давать правки по дизайну, так как он полностью полагается на опыт и знания своих сотрудников. Но код всё равно оставил за собой! ?
Интуиция — это ключ
Важный компонент успеха, собственно на что всегда полагался T - это интуиция. Не нужно быть самым умным в здании, главное — иметь чутьё. Прокачать мышцу под названием интуиция способа нет, но зато нужно всегда окружать себя более умными людьми и двигаться к своей цели (T знаком со стариной Уорреном Баффеттом).
«Всегда окружайте себя людьми, которые умнее и лучше вас»
Ну и T намекает - хотите попасть в мою команду? Развивайтесь, смотрите курсы Laracasts и CutCode ?.
Мне также здесь понравилась мысль от T - чтобы достичь результата не надо бояться или быть слишком гордым, чтобы просить помощь. Не обязательно знать всё и всегда есть люди рядом с нами, которые лучше разбираются в каком-то вопросе. Соглашусь, особенно с опытом и определённым успехом помощь просить сложно, но истинная сила человека заключается не только в физической мощи или власти, но и в способности преодолевать свои эгоистичные чувства и гордость.
История создания Laravel, Forge и Herd
Тут наверное история, которую мы слышим от любого автора open source проекта — то, что сделано было сделано для себя и под свои задачи. Было много боли и рутины на работе и хотелось всё упростить и добиться красивых решений, и вот такие откровения поведал нам и T в этом интервью.
T сделал Forge (интуиция подсказала), который почти сразу на старте начал приносить ему денег в несколько раз больше, чем на основной работе. Но T подождал ещё 6 месяцев после запуска Forge, так как боялся рисковать, но в итоге ушёл с основной работы и считает, что сделал правильно. Грех не согласится, что выбор правильный, иначе бы у него интервью не брали ?.
Зачем Laravel масштабироваться?
Из интервью мы узнали, что за год количество сотрудников выросло с 10 до 40 и, соответственно, вопрос - зачем если и так всё хорошо? Оказывается, у T уже давно глобальные цели и ему не хватает ресурсов, чтобы их выполнить. Одна из ближайших целей — это Cloud, который недавно релизнули. Вообще цели это ответ на вопрос, куда движется Laravel?
В целом T считает, что работа над Laravel ещё не закончена и что там есть плохой код, который мешает ему спать?.
T: "Откуда в Laravel плохой код скажете вы?!? Да и в целом я думаю ещё надо хотя бы типизацией заняться, но пока ресурсов нет?"
Мы поняли, что код Laravel идеален и это так, потому что он открыт для всех и это лицо T. А вот в его закрытых коммерческих проектах T сознался, что с кодом уже не так радужно, но главное, что работает и деньги приносит. В общем, там можно и похулиганить.
Из этого вопроса я понял, что T уже устал от работы над Laravel и ему необходимы новые вызовы. Таким вызовом и является проект Cloud, на создание которого он привлёк инвестиции и расширяет команду.
Говоря о будущем, T поставил чёткую цель - сделать порог входа ещё ниже, чтобы web-разработчик ещё не имея особых знаний купил ноут, в пару кликов поднял систему для разработки на любой платформе и начал писать проекты. Ну и также просто их деплоил, конечно же через Cloud (или через onFriday, но про это T почему-то не сказал). В целом T вспоминает, каким простым был PHP, в те старые добрые времена, когда достаточно по FTP залить один файл и всё готово. И насколько сложно деплоить сейчас. Фреймворки всякие с миграциями, гиты, зависимости, очереди.
Собственно цель T сделать PHP снова популярным - чтобы любая обезьянка могла написать сайт и задеплоить его в пару кликов. Кстати говорят, что в Laravel придумали новый вид тестирования, где обезьяны в течение 5 минут должны сделать блог на Laravel, и совсем недавно тест был провален на несколько минут, поэтому вышел Laravel 11 с slim скелетом ?
То, ради чего мы здесь собрались — итоги
Фокус на массовом разработчике.
T не конкурирует с Symfony и с какими-либо Enterprise решениями и не собирается конкурировать. Его путь — работа с массовым потребителем, упор на так называемых junior и middle разработчиков и средние проекты.
Философия простоты.
Laravel не будет усложняться, так как то, что T не понимает - фреймворку не нужно. Порог вхождения будет дальше уменьшаться. Если требуется без особых знаний ворваться в web-разработку, то Laravel идеален. Песочница или любой не претендующий на хайлоад проект не найдёт лучше решения, чем Laravel. Сам T следует этой философии, делая проекты для экосистемы Laravel (полезные сервисы для упрощения жизни разрабам) - ничего мегасложного.
T держит руку на пульсе и будет продолжать развивать Laravel.
T сильно вовлечён в написание кода и занимается код-ревью всех PR в Laravel. Большие планы подтверждают значительные инвестиции, которые удалось привлечь T - https://laravel-news.com/laravel-raises-57-million-series-a. Laravel это работа всей его жизни и его величайшее профессиональное достижение. T намерен продолжать делать его потрясающимХейт Laravel оправдан?
Сложил мысли T и своё мнение по результатам нескольких лет работы с Laravel и другими PHP фреймворками - хейт Laravel не имеет смысла. У каждого решения есть недостатки, они могут быть явными, или их можно придумать, если есть желание. Это как хейтить Tesla за то, что она не делает тягачи! Действительно, их тачки не способны возить большой груз на дальние расстояния. Но факт в том что самому владельцу Tesla эти недостатки не интересны. Ну если же он купил Tesla для грузоперевозок и его не устраивают возможности авто, то, скорее всего, дурак он, а не Маск.
Laravel отличный инструмент для определенного набора задач. Но он не универсален на 100% и имеет свои недостатки.
Ну а T я шлю респект от CutCode! Laravel развивается, хоть и не всем нравится, как это развитие происходит. Slim skeleton только начало, типизацию и уход от нативной сериализации в очередях не ждите, но скоро будет атрибут, который сразу реализует аутентификацию или максимум вынос очередей в пакет ?
Всем мир ✌️
Данил Щуцкий, CutCode
Комментарии (39)
sergant210
23.10.2024 08:23Интересная статья.
П.С. Идея с сокращением имени Тейлора выглядит кринжем. Наверно нужно было пойти дальше и сокращать вообще всё - "На самом деле я уважаю T, его фундаментальный продукт - L, а также труд и вклад в P сообщество" )
Cutcode Автор
23.10.2024 08:23Спасибо, но насчет "п.с" идея классная конечно и веселая, оставим для следующей статьи)
Sway
23.10.2024 08:23Если Т свой ORM называет простым, то он вообще его использовал в сколько-нибудь сложных сценариях? Там же можно в ногу выстрелить на каждом запросе, если не знать подводные камни. А в код давно смотрел? там же сплошной overengineering c невероятным количеством магии. Про реализацию тегов для кеширования вообще промолчу, это ж совершенно неюзабельно в 99% сценариев когда теги могли бы использоваться. Что-то прочитал я это всё, и как-то грустно стало. Походу таки надо подумать про выпиливание генератора неочевидных и непредсказуемых багов (это я про ORM)...
FanatPHP
Спасибо за отличный обзор! Я вот кстати тоже всегда говорил, что Ларвель следует изначальному подходу, заложенному ещё Расмусом - фигак-фигак и в продакшен :)
Разумеется, у этого подхода есть свои минусы. Но нельзя отрицать, что и своя ниша тоже есть. И пых захватил веб именно благодаря ей. И сюда же перекличка с Аджайлом. Если нам нужен MVP, то и надо пилить MVP, а не накручивать абстракции. А вот когда (если) проект выстрелит и разрастётся - можно будет неторопясь вдумчиво перепиливать его на Симфони. Или разбить на микросервисы на том же Ларавле.
Djeux
Много ли вы подобного встречали на своем опыте?
Чаще "зачем тратить время на то что и так работает, погнали фичи пилить".
Сам много лет использовал Лару. Есть свои плюсы, но тот же eloquent выбешивал столько что сейчас я лучше потрачу чуть больше времени но без него.
FanatPHP
На самом деле да. Большая часть проектов, на которых я работал, проходили по несколько стадий большого рефакторинга или даже сказать - смены платформ. Битрикс - чистый пых - Ларавель - Симфони. Эксель - чистый пых - Соната админ - Симфони. Монолит Ларавель - Ядро на Го, микросервисы на Ларавле но в качестве ORM - Доктрина.
Не скажу, что все эти переходы, и в особенности с Ларавля на Симфони, были вызваны насущной необходимостью (хотя многие как раз были) - часто это просто смена команды и/или руководителя. Но нарастание технического долга по мере развития проекта - это факт. А параллельная разработка полностью нового движка - один из вариантов решения. И вот тут-то как раз сменить платформу не проблема.
Djeux
Искренне завидую. На моем опыте, максимум удавалось раскрутить на "давайте стараться обновляться до последней версии не с задержкой в 5 лет", и то при условии что я это в свое свободное время делаю когда никто не работает над проектом.
joffer
тут поддержал бы ФанатаПХП - такой сценарий вообще выглядит как более-менее стандартный. Из моего опыта - начали делать проект на Yii2, запустились, что-то продали, через 1.5 года начали писать вторую версию на симфони, используя первый проект как документацию и набор логики.
Или там пришёл заказчик, у него был магазин на Вордпресс, магазин раскрутился и быстро упёрся в производительность - по итогам опять же параллельно подняли симфони проект, в который начали переносить атомарный функционал, получив в результате сначала бедную на функционал, но куда более быструю копию магазина.
Или там как-то был на проекте, там бы самописный кадавр, проект представлял из себя платформу заказов работ, админку, разделение прав доступа и что атм ещё, 7 лет бекенд писался исходя из парадигмы добавления функционала без единого рефакторинга. В результате какие-то классы работали с базой данных через голые запросы + через Eloquent-построитель (который прикрутили от Ларавель), и ещё в одном месте подключался SlimPHP - только чтобы пересылать обработанные данные на "реактивный" фронтенд. Там тоже это всё упёрлось в скорость обработки, первым делом выкинули всё стороннее, оставив или голые запросы или модели для Doctrine2, потом пытались с главным монолитом морочиться в попытках его причесать - потеряли года 1.5 времени, плюнули и стали параллельно поднимать ядро на симфони, в которое опять же постепенно начали перетаскивать какой-то фукнционал.
Справедливости ради, были и просто проекты на Yii2 и на Laravel, но там, как правило, это были проекты под невысокую посещаемость - вроде там складского учёта, документооборота фирмы и тому подобное, то там да, нагрузки не было никакой, активные пользователи в пределах 1000к человек за сутки, то производительности хватало. Единственно всё равно в сложных выборках не было веры ни Eloquent, ни Active Record и в моделях держали это всё в виде raw sql
dmi3mart
А чем выбешивал Eloquent? Можете привести какие-то примеры из реального опыта? Довольно интересно. Насколько я понимаю, в основном критика упирается в огромное количество магии и связанных с ней проблем с неочевидностью поведения.
SerafimArts
Не соглашусь (ну точнее не полностью). Имхо, основное преимущество Laravel в человеческих ресурсах, когда берёшь вчерашнего студента, сажаешь его на Laravel и вуаля, на выходе даже что-то работает. И там не то что фреймворк не обязательно знать, но и на PHP зачастую пофигу.
Ну потому что "фигак-фигак и в прод" можно и на симфе делать, и местами даже быстрее. Однако всё же квалификация под симфу требуется повыше.
FanatPHP
Не знаю, для меня "берешь студента и вуаля" и "фигак-фигак и в прод" это одно и то же разными словами :)
По моему опыту, средний проект на Ларе требует меньшей проработки, чем на Симфе. На долгой дистанции все эти тщательно выписанные ентити и конфиги сильно помогают расширять проект и добавлять на него разработчиков. Но объективно замедляют запуск и разработку в целом.
SerafimArts
Ну всё же нет. Студент симфу не осилит просто, по-моему. А "фигак-фигак" вполне может быть техническим требованием к продукту.
Получаем "тщательно выписанные энтити" vs "тщательно выписанные миграции". В ларке даже тут писанины больше, т.к. написать энтитю из которой сами миграции сгенерятся проще и быстрее, нежели вначале ап миграции, потом откат миграции, а потом ещё модель.
В симфе так же можно фигануть
App\: { resource: "path/to/app" }и забыть про конфиги сервисов, сделав вид, что оно работает так же как в ларке. Ну да, тут побольше писанины на одну строчку!Я же и говорю, при должном желании и компетенциях -- на симфе, имхо, почти всё получается быстрее, даже говнокод)
Поэтому и считаю что "фигак-фигак" и "вчерашний студент" - разные вещи, т.к. чтобы на симфе максимально лаконично и быстро что-то наклепать -- как минимум требуется знать где именно можно сократить что.
FanatPHP
Ну ок, я согласен отозвать формулировку с фигаком, если она вызывает такие принципиальные возражения. Я имел в виду в целом дух пхпе нулевых, когда любая домохозяйка, до этого незнакомая с программированием, делала сайт любимого клана в бк.
SerafimArts
Я понял, я просто пояснил что я подразумевал под "фигак-фигак".
Этот "фигак-фигак" можно рассматривать как требования к разработке сервиса свыше от манагеров. Мол, "надо чтобы было сделано уже вчера". Это о чём я говорю.
А то о чём ты говоришь, "фигак-фигак" -- это не требования к ПО, а возможности разработчика, когда он кроме такого пути ничего просто не умеет.
Cutcode Автор
надо сделать стрим, где посадим двух студентов на симфу и ларку и кто быстрее запилит)
joffer
тут Лара проиграет, потому что есть куда более быстрые и минималистичные в сборке фреймворки, также использующие компоненты симфони - тут ещё и вопрос такой, что за проект пилить будем, если просто контроллер + обслуживание апи - это одно, если какой-то магазин или полноценную платформу заказов или какой-то сервис с миллионом хитов в сутки - это тоже другое будет.
Лара выруливает, потому что это - самый популярный комбайн, но это не самый быстрый комбайн, не самый простой, не самый надёжный. Тут как с Wordpress ситуация - он не самый быстрый, не самый простой и есть решения лучше, но он - самый популярный, самое большое комьюнити, больше всего опыта в проектировании, разработке и исправлении ошибок
SerafimArts
Надо сажать не студентов, а профи в симфе и профи в ларе и дать им задачу запилить какое-либо ПО максимально всрато и в максимально сжатые сроки.
Ну, например, какой-нибудь сервис логина и регистрации акков с поддержкой OTLP мониторинга на уровне БД. И HTTP АПИ наружу, запрос-ответ, в каком-нибудь msgpack формате.
roxblnfk
Быстрая разработка на Laravel подразумевает, что человек знает все эти фасады и сокращения. Поэтому, сдаётся мне, вчерашние студенты одинаково медленно и отвратительно решат задачу на любом фреймворке :)
И выиграет в итоге тот, у которого будет Copilot.
Cutcode Автор
и еще надо не забыть про ide helper для ларавел)
GothicJS
Да кстати, я вот с удивлением всегда смотрю, когда говорят, что лара это суперпростой фрейм с самым низким порогом входа... Всю эту магию чтобы использовать, для начала изучить надо. И не только новичкам, ведь человек с опытом эту конкретную ларовскую магию тоже узнать должен. Поэтому как то перевернули все с ног на голову...
ilyatom
Вот-вот. Почему-то у Ларавел репутация не то что несложного, а прямо-таки общедоступного фрейворка. Да, Eloquent проще и понятнее Doctrine, и многие другие компоненты удобны, но в целом, на мой взгляд, очень много темной магии, с которой сначала нужно разобраться.
GothicJS
А что такого симфони даст, чтоб на нее переписывать с лары? Ведь и на ларе ж можно сделать не только микросервисы, но и просто модульный монолит с хорошей архитектурой.
И почему актив рекордс так не любят для сложных приложений? Только потому, что там в модели можно писать методы? Но ведь никто ж наверно не мешает использовать такую модель как ентити + сделать отдельно репозитории?
Sanchous98
А какой смысл тогда в моделях Laravel если их использовать как обычные объекты? Проблема же не в желании иметь репозитории, а в том, что у вас код сильно связан со схемой базы данных. Если попытаться в чистую архитектуру на laravel, то вы обнаружите, что ваши модели, будучи частью домена, ходят в базу данных, что уже есть инфраструктура. Решения тут три: полностью отказаться от eloquent в пользу дата маппера(doctrine, cycle orm), придумать свой костыль для того, чтобы модель eloquent кастовать в entity или если пойти в event sourcing, то можно события сохранять при помощи query builder, а eloquent использовать в проекциях. В общем, laravel удобен, пока проект не вырастает настолько, что нужно заботиться об его архитектуре
FanatPHP
В рамочку и на стену!
DarkKefir
Интересно, что вы думаете про Drupal архитектуру?
SerafimArts
Чтобы модели ёлки кастовать в энтити можно взять JMS или Symfony Serializer. С другой стороны и троллейбус из хлеба можно сделать...
Ну и всё же это не столько "чистая архитектура", сколько конкретная репрезентация в виде гексагоналки. Хотя не спорю что что-то адекватнее или какую-либо альтернативу сложно придумать.
GothicJS
То есть проблемы две - код связан со схемой бд и актив рекорд это не дата маппер?
В таком случае почему это проблема?
Что даст например ентити - что можно будет назвать поле не так, как столбец в бд? Почему всегда говорят, что дата мапер лучше для больших приложений?
Djeux
Лара уже научилась поддерживать композитные primary keys? Когда я последний раз работал с ларой, была принципиальная позиция не добавлять это.
А имхо, фреймворк не должен навязывать архитектуру хранения данных
Cutcode Автор
не научилась
roxblnfk
Что же они там три раза переписывали?
Мне хватило 1 раз переписать Cycle, чтобы композитные PK добавить :D
Cutcode Автор
Ну нет у них композитных зато findOrFail есть, а у тебя в Cycle есть findOne а вот findOneOrFail нету)
SerafimArts
Раунд!
roxblnfk
...->findOne() ?? throw new NotFoundException();
¯\_(ツ)_/¯Вспомнилась статья, в которой чувак рекомендует всегда использовать
firstOrFail(). А когда надо выкинуть своё исключение, то он оборачивает вtry/catch. Причём в его кейсе даже без$previous.Cutcode Автор
"Automatic Error Handling: It automatically triggers a 404 response, adhering to RESTful principles."
это и есть laraway