Задать вопрос
alexbuki
@alexbuki
программист js

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

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

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

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

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

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

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

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

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

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