Как правильно раздедить фронтенд и бекенд в монолитном проекте на php?

Question

[Александр Буки]

Здравствуйте уважаемые участники!
Прошу быть снисходителтными к моему вопросу и проявить понимание.

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

Поэтому появилась идея проект разделить на два отдельных проекта. Условно назовём их новые фронтенд и бекенд.

Фронт будет на nuxt(vue) - выбран потому что есть опыт работы с ним и важно ssr и seo.
А бекенд на Laravel. Больше потому что тоже php и разработчик сможет изучать логику старого приложения.

Работать они будут как два отдельных приложения. Общение по http.

Так как разом такую штуку не провернешь и весь проект не перести одной итерацией, появилась идея делать это частями.

Сейчас сервер работает как связка ngnix + apache +php.

Поэтому есть возможность на уровне ngnix постранично перенаправлять пользователей на новое приложение фронта - nuxt, которое будет ходить в ларавел за данными.

В общем то вопросы такие. На сколько такое разделение будет правильным? Повлияет ли на Seo? Какие есть ещё варианты, чтобы оптимизировать разработку?

Answer 1

[flekst]

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

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

Comments

[Фёдор]

А что стало с кобольтом?

Answer 2

[3ton]

В свое время мы столкнулись с такой же проблемой - разделить монолит на фронт и бэк отдельно.

Пошли простым путем: выдали на бэке отдельно методы API для фронта, а с фронта работали с ними из CMS, в которой написали свои расширения и ими формировали функционал реализованный ранее лапшекодом.

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

Answer 3

[Владимир Коротенко]

Я бы поставил "затычки" в новом приложении ведущие в старое.
Метод не идеальный но позволяет вот прям и сейчас получить новый функционал.
Хотя в общем затраты на переезд будут больше.

Привет скраму и его идеологам.

Answer 4

[motomac]

А насколько большая команда разработчиков? Это я к тому, имеет ли смысл разделение на фронт+бэк? Если и фронт отдельно, и бэк отдельно очень сложные, и работать над ними будут две разные команды, либо будет несколько клиентов (фронт, мобилка, например), то да, определенно стоит разделить. Если же разработчиков немного, а фронт это только веб, я бы смотрел в сторону монолита на Laravel. Благо у него сегодня есть прекрасные инструменты для фронта (Livewire, тот же Vue из коробки). Просто затраты на согласование API, его расширение, апдейты, да и просто коммуникацию между фронтендерами и бэкендерами это довольно сильный тормозящий фактор и значительное усложнение всего. Выкатка одного мелкого изменения начинает затрагивать сразу несколько человек и кодовых баз. Иногда оно просто не стоит того.