Comments 40
Спасибо за отличный обзор! Я вот кстати тоже всегда говорил, что Ларвель следует изначальному подходу, заложенному ещё Расмусом - фигак-фигак и в продакшен :)
Разумеется, у этого подхода есть свои минусы. Но нельзя отрицать, что и своя ниша тоже есть. И пых захватил веб именно благодаря ей. И сюда же перекличка с Аджайлом. Если нам нужен MVP, то и надо пилить MVP, а не накручивать абстракции. А вот когда (если) проект выстрелит и разрастётся - можно будет неторопясь вдумчиво перепиливать его на Симфони. Или разбить на микросервисы на том же Ларавле.
А вот когда (если) проект выстрелит и разрастётся - можно будет неторопясь вдумчиво перепиливать его на Симфони.
Много ли вы подобного встречали на своем опыте?
Чаще "зачем тратить время на то что и так работает, погнали фичи пилить".
Сам много лет использовал Лару. Есть свои плюсы, но тот же eloquent выбешивал столько что сейчас я лучше потрачу чуть больше времени но без него.
На самом деле да. Большая часть проектов, на которых я работал, проходили по несколько стадий большого рефакторинга или даже сказать - смены платформ. Битрикс - чистый пых - Ларавель - Симфони. Эксель - чистый пых - Соната админ - Симфони. Монолит Ларавель - Ядро на Го, микросервисы на Ларавле но в качестве ORM - Доктрина.
Не скажу, что все эти переходы, и в особенности с Ларавля на Симфони, были вызваны насущной необходимостью (хотя многие как раз были) - часто это просто смена команды и/или руководителя. Но нарастание технического долга по мере развития проекта - это факт. А параллельная разработка полностью нового движка - один из вариантов решения. И вот тут-то как раз сменить платформу не проблема.
тут поддержал бы ФанатаПХП - такой сценарий вообще выглядит как более-менее стандартный. Из моего опыта - начали делать проект на Yii2, запустились, что-то продали, через 1.5 года начали писать вторую версию на симфони, используя первый проект как документацию и набор логики.
Или там пришёл заказчик, у него был магазин на Вордпресс, магазин раскрутился и быстро упёрся в производительность - по итогам опять же параллельно подняли симфони проект, в который начали переносить атомарный функционал, получив в результате сначала бедную на функционал, но куда более быструю копию магазина.
Или там как-то был на проекте, там бы самописный кадавр, проект представлял из себя платформу заказов работ, админку, разделение прав доступа и что атм ещё, 7 лет бекенд писался исходя из парадигмы добавления функционала без единого рефакторинга. В результате какие-то классы работали с базой данных через голые запросы + через Eloquent-построитель (который прикрутили от Ларавель), и ещё в одном месте подключался SlimPHP - только чтобы пересылать обработанные данные на "реактивный" фронтенд. Там тоже это всё упёрлось в скорость обработки, первым делом выкинули всё стороннее, оставив или голые запросы или модели для Doctrine2, потом пытались с главным монолитом морочиться в попытках его причесать - потеряли года 1.5 времени, плюнули и стали параллельно поднимать ядро на симфони, в которое опять же постепенно начали перетаскивать какой-то фукнционал.
Справедливости ради, были и просто проекты на Yii2 и на Laravel, но там, как правило, это были проекты под невысокую посещаемость - вроде там складского учёта, документооборота фирмы и тому подобное, то там да, нагрузки не было никакой, активные пользователи в пределах 1000к человек за сутки, то производительности хватало. Единственно всё равно в сложных выборках не было веры ни Eloquent, ни Active Record и в моделях держали это всё в виде raw sql
А чем выбешивал Eloquent? Можете привести какие-то примеры из реального опыта? Довольно интересно. Насколько я понимаю, в основном критика упирается в огромное количество магии и связанных с ней проблем с неочевидностью поведения.
Не соглашусь (ну точнее не полностью). Имхо, основное преимущество Laravel в человеческих ресурсах, когда берёшь вчерашнего студента, сажаешь его на Laravel и вуаля, на выходе даже что-то работает. И там не то что фреймворк не обязательно знать, но и на PHP зачастую пофигу.
Ну потому что "фигак-фигак и в прод" можно и на симфе делать, и местами даже быстрее. Однако всё же квалификация под симфу требуется повыше.
Не знаю, для меня "берешь студента и вуаля" и "фигак-фигак и в прод" это одно и то же разными словами :)
По моему опыту, средний проект на Ларе требует меньшей проработки, чем на Симфе. На долгой дистанции все эти тщательно выписанные ентити и конфиги сильно помогают расширять проект и добавлять на него разработчиков. Но объективно замедляют запуск и разработку в целом.
Не знаю, для меня "берешь студента и вуаля" и "фигак-фигак и в прод" это одно и то же разными словами :)
Ну всё же нет. Студент симфу не осилит просто, по-моему. А "фигак-фигак" вполне может быть техническим требованием к продукту.
все эти тщательно выписанные ентити
Получаем "тщательно выписанные энтити" vs "тщательно выписанные миграции". В ларке даже тут писанины больше, т.к. написать энтитю из которой сами миграции сгенерятся проще и быстрее, нежели вначале ап миграции, потом откат миграции, а потом ещё модель.
и конфиги
В симфе так же можно фигануть App\: { resource: "path/to/app" } и забыть про конфиги сервисов, сделав вид, что оно работает так же как в ларке. Ну да, тут побольше писанины на одну строчку!
Я же и говорю, при должном желании и компетенциях -- на симфе, имхо, почти всё получается быстрее, даже говнокод)
Поэтому и считаю что "фигак-фигак" и "вчерашний студент" - разные вещи, т.к. чтобы на симфе максимально лаконично и быстро что-то наклепать -- как минимум требуется знать где именно можно сократить что.
Ну ок, я согласен отозвать формулировку с фигаком, если она вызывает такие принципиальные возражения. Я имел в виду в целом дух пхпе нулевых, когда любая домохозяйка, до этого незнакомая с программированием, делала сайт любимого клана в бк.
Я понял, я просто пояснил что я подразумевал под "фигак-фигак".
Этот "фигак-фигак" можно рассматривать как требования к разработке сервиса свыше от манагеров. Мол, "надо чтобы было сделано уже вчера". Это о чём я говорю.
А то о чём ты говоришь, "фигак-фигак" -- это не требования к ПО, а возможности разработчика, когда он кроме такого пути ничего просто не умеет.
надо сделать стрим, где посадим двух студентов на симфу и ларку и кто быстрее запилит)
тут Лара проиграет, потому что есть куда более быстрые и минималистичные в сборке фреймворки, также использующие компоненты симфони - тут ещё и вопрос такой, что за проект пилить будем, если просто контроллер + обслуживание апи - это одно, если какой-то магазин или полноценную платформу заказов или какой-то сервис с миллионом хитов в сутки - это тоже другое будет.
Лара выруливает, потому что это - самый популярный комбайн, но это не самый быстрый комбайн, не самый простой, не самый надёжный. Тут как с Wordpress ситуация - он не самый быстрый, не самый простой и есть решения лучше, но он - самый популярный, самое большое комьюнити, больше всего опыта в проектировании, разработке и исправлении ошибок
Надо сажать не студентов, а профи в симфе и профи в ларе и дать им задачу запилить какое-либо ПО максимально всрато и в максимально сжатые сроки.
Ну, например, какой-нибудь сервис логина и регистрации акков с поддержкой OTLP мониторинга на уровне БД. И HTTP АПИ наружу, запрос-ответ, в каком-нибудь msgpack формате.
Быстрая разработка на Laravel подразумевает, что человек знает все эти фасады и сокращения. Поэтому, сдаётся мне, вчерашние студенты одинаково медленно и отвратительно решат задачу на любом фреймворке :)
И выиграет в итоге тот, у которого будет Copilot.
и еще надо не забыть про ide helper для ларавел)
Да кстати, я вот с удивлением всегда смотрю, когда говорят, что лара это суперпростой фрейм с самым низким порогом входа... Всю эту магию чтобы использовать, для начала изучить надо. И не только новичкам, ведь человек с опытом эту конкретную ларовскую магию тоже узнать должен. Поэтому как то перевернули все с ног на голову...
А что такого симфони даст, чтоб на нее переписывать с лары? Ведь и на ларе ж можно сделать не только микросервисы, но и просто модульный монолит с хорошей архитектурой.
И почему актив рекордс так не любят для сложных приложений? Только потому, что там в модели можно писать методы? Но ведь никто ж наверно не мешает использовать такую модель как ентити + сделать отдельно репозитории?
А какой смысл тогда в моделях Laravel если их использовать как обычные объекты? Проблема же не в желании иметь репозитории, а в том, что у вас код сильно связан со схемой базы данных. Если попытаться в чистую архитектуру на laravel, то вы обнаружите, что ваши модели, будучи частью домена, ходят в базу данных, что уже есть инфраструктура. Решения тут три: полностью отказаться от eloquent в пользу дата маппера(doctrine, cycle orm), придумать свой костыль для того, чтобы модель eloquent кастовать в entity или если пойти в event sourcing, то можно события сохранять при помощи query builder, а eloquent использовать в проекциях. В общем, laravel удобен, пока проект не вырастает настолько, что нужно заботиться об его архитектуре
laravel удобен, пока проект не вырастает настолько, что нужно заботиться об его архитектуре
В рамочку и на стену!
Интересно, что вы думаете про Drupal архитектуру?
Чтобы модели ёлки кастовать в энтити можно взять JMS или Symfony Serializer. С другой стороны и троллейбус из хлеба можно сделать...
Ну и всё же это не столько "чистая архитектура", сколько конкретная репрезентация в виде гексагоналки. Хотя не спорю что что-то адекватнее или какую-либо альтернативу сложно придумать.
То есть проблемы две - код связан со схемой бд и актив рекорд это не дата маппер?
В таком случае почему это проблема?
Что даст например ентити - что можно будет назвать поле не так, как столбец в бд? Почему всегда говорят, что дата мапер лучше для больших приложений?
Лара уже научилась поддерживать композитные primary keys? Когда я последний раз работал с ларой, была принципиальная позиция не добавлять это.
А имхо, фреймворк не должен навязывать архитектуру хранения данных
не научилась
Что же они там три раза переписывали?
Мне хватило 1 раз переписать Cycle, чтобы композитные PK добавить :D
Ну нет у них композитных зато findOrFail есть, а у тебя в Cycle есть findOne а вот findOneOrFail нету)
Раунд!
...->findOne() ?? throw new NotFoundException();¯\_(ツ)_/¯
Вспомнилась статья, в которой чувак рекомендует всегда использовать firstOrFail() . А когда надо выкинуть своё исключение, то он оборачивает в try/catch. Причём в его кейсе даже без $previous.
Интересная статья.
П.С. Идея с сокращением имени Тейлора выглядит кринжем. Наверно нужно было пойти дальше и сокращать вообще всё - "На самом деле я уважаю T, его фундаментальный продукт - L, а также труд и вклад в P сообщество" )
Если Т свой ORM называет простым, то он вообще его использовал в сколько-нибудь сложных сценариях? Там же можно в ногу выстрелить на каждом запросе, если не знать подводные камни. А в код давно смотрел? там же сплошной overengineering c невероятным количеством магии. Про реализацию тегов для кеширования вообще промолчу, это ж совершенно неюзабельно в 99% сценариев когда теги могли бы использоваться. Что-то прочитал я это всё, и как-то грустно стало. Походу таки надо подумать про выпиливание генератора неочевидных и непредсказуемых багов (это я про ORM)...
Хороший обзор интервью. Спасибо.
Какимто монстрообразным он становится от версии к версии
Хз куда он там движется, но уже в 7-й версии там внутри папки vendor такая каша, что в ней вот так запросто не разобраться...
Куда движется Laravel? Обзор интервью с Taylor Otwell