Можно ли как то внедрить Laravel постепенно, например установить как основной каркас и в него уже встроить CMS?

Question

[Сергей Романов]

есть достаточно старый проект, который за годы оброс контентом и функционалом. Портал работает на самописной CMS (PHP 5 +MySQL), разработчики все время советуют перейти на новые технологии а если точнее на Laravel и с MySQL на PostgreSQL чтоб сайт не только стал современным но и работал шустрее.

Я понимаю что совет разработчика хороший вот только функционала и контента много было написано за 10 лет, в среднем чтоб переписать проект на Laravel потребуется минимум год, а скорей всего полтора, самое забавное что портал тоже постоянно дописываем новыми фишками и получается что обновленный проект вечно будет опаздывать, а еще хуже то что можно уйти в вечное дописывание и переписывание.

Вопрос, можно ли как то внедрить Laravel постепенно, например установить как основной каркас, в него уже встроить CMS и далее постепенно переписывать каждый компонент?

Comments

[tukreb]

Советую посмотреть в сторону Symfony.
Ларка хороша на короткой дистанции, когда нужно набросать тяп-ляп. Если что-то огромное и вы хотите, чтобы после вас там тоже разобрались, то лучше Symfony.

[ThunderCat]

tukreb, извините, но это бред собачий. То что у лары подход оторванный от ROR, не значит что она чем то хуже Симфы. Про то что там в базовом состоянии куча симфонических компонент зашита я вообще молчу. Опять же - что-то кроме карго культа в аргументах будет?

[DWS11]

tukreb, ну и бредятина. Тяп-ляп можно не чем угодно сделать. Фреймворк тут не спасет

[tukreb]

DWS11, конечно на чём угодно можно, только на ларке проще и обычно всегда и тяп-ляп )

[ThunderCat]

tukreb, я видел десятки проектов на ларе, симфони, зенде и фалконе, и да, на ларе больше проектов построенных "на коленке", в основном это проекты которые писались в одно рыло за 1-2 недели (что не баг, а фича, ни на зенде ни на симфе так быстро не сваяешь тот же объем). И "наколеночность" в основном связана с хреновым проектированием, а не с тем что движок чем-то плох. Проекты пишутся на ларке так как а) быстрее, б) компактнее в) на порядок проще в поддержке, так как найти прогеров под лару проще и дешевле. В производительности разницы ноль. Все понты вокруг Симфони строятся на "мы такой себе зенд, но без актив рекорд, чисто репозитории!". Красиво, волшебно, на практике сильно замедляет разработку, хотя сохраняет формальную чистоту моделей.

[tukreb]

ThunderCat, ну да, ларка так ускоряет разработку, что каждый "второй" плюётся, что IDE не может найти классы из-за магии. И на любой чих лезть в документацию, чтобы найти ссылку на класс, либо костылить плагинами IDE, чтобы она могла нормально ссылаться на библиотеки и вообще работал автоподстоновка.
В симфони всё работает из коробки и без всякой магии, ну кроме yaml и twig, там чтобы подстановка работало надо поставить всего лишь один бесплатный плагин Symfony.
Возможно вы и напишите на ларке приложение в 2 строки используя магию, где на сифмони для этого придётся создать 200 строк (образно), но как только вам нужно будет сделать шаг влево от документации, вы сразу окажитесь позади по скорости.

[ThunderCat]

tukreb,

IDE не может найти классы из-за магии.

Не знаю, никогда не сталкивался. Кто эти вторые - загадка.

В симфони всё работает из коробки и без всякой магии, ну кроме yaml и twig, там чтобы подстановка работало надо поставить всего лишь один бесплатный плагин Symfony.

Ага, половина настроек еще и написана аннотациями. И надо только взять соду и...

но как только вам нужно будет сделать шаг влево от документации, вы сразу окажитесь позади по скорости.

Так же будет в ЛЮБОЙ системе разработки, как это относится конкретно к ларе?

[tukreb]

В симфони настройки анотациями? Там давно всё идёт через атрибуты, анотации прошлый век в симфони и используются только для psalm. Там даже в конфиг файлы уже практически не нужно лезть, всё работает через атрибуты.

Так же будет в ЛЮБОЙ системе разработки, как это относится конкретно к ларе?

Тем, что пока вы не обмажете IDE плагинами, вы будете чувствовать, что работаете не в IDE, а в блокноте. Да и не факт, что плагины всюду поможет, и вам придётся везде пихать аннотации, чтобы IDE, понимала, что к чему.
К слову, в Сифмони аннотации можно полностью удалить начиная с php8, когда симфони ввела полную поддержку атрибутов и с каждым релизом, только сильнее расширяет этот удобный инструмент.

Answer 1

[ThunderCat]

разработчики все время советуют перейти на новые технологии а если точнее на Laravel и с MySQL на PostgreSQL чтоб сайт не только стал современным но и работал шустрее.

Переход с самописа на лару - хороший шаг, переход на постгрес нужен только если нужны конкретные задачи, решаемые постгресом лучше чем мускулем. Например, если у вас есть большой массив json данных, хранимых в соответствующих полях и требующий каких-либо выборок на основании этих полей, то есть по сути - если у вас база хранит ненормализованные сортируемые данные. В остальном выгода от перехода с мускуля на постгрес будет не видна без микроскопа.

Если база нормально спроектирована, то модели лары могут практически налету подхватить таблички, останется только написать зависимости в моделях, пошаманить контроллеры и перевести хтмл в блэйды. Задача не смотрится как "работы на год", однако сложно сказать за сколько справятся ваши прогеры, тут сильно зависит от исходных данных, типа насколько правильно спроектирована бд, что есть сложного в функционале такого, что долго переносить в ооп/мкв, насколько хорошо разбираются ваши спецы в том что было написано в легаси проекте, насколько они хорошо знают лару...

Обычно заявы по типу "мускуль гуано, надо менять на постгрес" без конкретных аргументов признак поклонников карго культа, а не профи. Так что я бы послушал аргументы для начала, а то потом окажется что там индексы только первичные на таблицах, про explain никто никогда не слышал, а выборки идут по тысяче в циклах, но виновата, конечно же, тормознутая бд.

Comments

[Daniel Green]

Ну, если в проекте большое количество таблиц с огромным количеством записей, разгица между мускулем и постгрес будет очень хорошо заметна) мы же не знаем, что за проект и какие масштабы. Вдруг человек хотел горизонтальное масштабирование подключить

[ThunderCat]

Daniel Green,

Ну, если в проекте большое количество таблиц с огромным количеством записей, разгица между мускулем и постгрес будет очень хорошо заметна

Трындеж, основанный ни на чем. Обе базы сопоставимы по производительности, сказки про то что постгрес как-то волшебно ускоряет большие объемы данных - городская легенда. Более того, при сопоставимой нагрузке мускуль будет жрать меньше памяти и проца.

И PostgreSQL, и MySQL известны как одни из самых быстрых решений СУБД на рынке. Однако в этой категории нет явного победителя. Вы можете довольно легко найти бенчмарки, которые рекомендуют одну базу данных на основе конфигурации, теста и оборудования. Одна может иметь преимущество в параллелизме, в то время как другая может лучше справляться на одноядерной машине с небольшим объемом памяти.

источник

Вдруг человек хотел горизонтальное масштабирование подключить

Так мускуль очень хорошо масштабируется в ширину. Есть небольшая разница в работе шардинга мускуля и постгреса, но однозначно сказать что подходит в конкретном случае сложно. Тем более нет смысла гадать без каких-то объективных данных.

Answer 2

[YepBro]

Можно. Ставите php8.4, cтавите «Ларавель», интегрируете аутентификацию, чтобы она была сквозной. Делаете лейаут из старого сайта. Делаете модели под таблицы. Новые модули делаете уже в «Ларавеле», постепенно переносите в него старые.

Проблемы, которые точно придется решать:

1. Всё время придется поддерживать два шаблона для сайта.
2. Если старый сайт использует одну точку входа index.php, а там уже определение роутинга, то придется слегка помучиться. Тогда сперва запрос должен принимать «Ларавель», искать подходящий роут, а потом, если нет совпадения, то проксировать его в старую систему (разумеется, с передачей всех данных).
3. Бардак в структуре проекта.
4. Настроить работу одновременно с двумя php (5-ой и 8-ой версии). Скорее всего придется делать два внутренних домена и перед ними ставить nginx как прокси. Можно на него попробовать и возложить проблему распределения роутов между старым и новым кодом.

Ну и по ходу наверняка еще будет много подводных камней.

В общем задача сложная, но очень интересная :)

С MySQL на PostgreSQL переходить не обязательно. Подробно об этом выше ThunderCat написал. Полностью согласен с ним.

Answer 3

[Александр]

Нельзя.
Через извращение можно.
Как устроена у вас Аутентификация? Можно попробовать вход переписать.
Как устроена самописная CMS? Можно попробовать вызвать render или вызывать страницы с другого сервера. Извращеный API.

Answer 4

[BabrHabr]

Совершенно точно не нужно преходить на postgre. Это ничего не даст
Совершенно точно не обязательно переходить на laravel. Это тоже может не принести никаких результатов кроме потерянного времени
Обязательно нужно сделать вот что
1. Перейти на современную версию php сразу на последнюю 8.4 А также на современную версию mysql. Одно это может вылится в многомесячный марафон. Но это придется сделать в любом случае. Как вы до сих пользуетесь 5 версией которую невозможно установить на современную ОС и на котороую уже годы не приходят обновления?
2. Двигать в сторону ООП если этого еще не сделано и писать все в классах

Answer 5

[Eugene]

Все очень просто. Добавьте второго разработчика у которого Лара Мейнстрим фреймворк и дайте ему задачу переписать вашу CMS на Лару. Паралельно добавляя ему таски тех фич которые добавляются у вас.

Answer 6

[Тимофей]

Если переходить то сразу или просто трансформировать проект постепенно используя пакеты symfony, laravel и другие. Иначе может превратиться в долгострой который никогда не будет завершен.

Answer 7

[Daniel Green]

Чтобы сменить БД, нужны веские причины. Для перехода на постгрес, как писали, выше, это может быть хранение JSON. Но на мой взгляд, учитывая лучшую производительность postgres в других аспектах, если у Вас очень большая база данных с раздутыми таблицами, или если у Вас совершается очень много join-ов, то переход также может быть оправдан. Опять же, нужно смотреть, тянет ли MySQL запросы, или нет. Может достаточно просто настроить индексы, и происзодительности хватит. В общем, перед переходом на postgres нужно попытаться выжать из MySQL максимум, т.к. такой масштабный переход часто бввает моторным.

По поводу ларавеля. Люди задавали правильные вопросы. Самый первый был про авторизацию и аунтефикацию. Если механизмы будут одинаковы, в теории можно запустить две версии сайта одновременно. Далее хороший вопрос: каким образом посылаются запросы на сервер? Через XHR/fetch? Или прямой переход на другую страницу? Если 1 вариант, то это упрощает плавный переход, т.к. можно часть эндпоинтоы переписать на ларе. Тогда на первом этапе у Вас на ларе будет только бэкенд. В ином случае, нужно будет сперва перевести все шаблоны под лару, опционально - с использованием компоновщика (в последней версии это vite).

Если же нет возможности параллельно развернуть сайты, или это трудно/неэффективно/и т.д., то, поздравляю, Вы в одной лодке со мной) советую сначала перевести макеты под лару, затем поэтапно (по частям) внедрять бизнес-логику: писать роуты, создавать модели и контроллеры, и т.д. Где можно, лучше сначала сделать заглушки. Таким образом, можно будет сразу тестировать внедрённый функционал. В таком случае даже необязательно писать в точности такую же систему авторизации - главное, чтобы не пропали учётки пользователей и не поменялось шифрование паролей)