Как перейти на Symfony и разделить проект?

У меня есть проект, который по факту несколько веб сайтов: бекенд, фронтенд и API на разных доменах. Через API происходят все запросы, начиная от логина, заканчивая выборкой статей и товаров. Сейчас это всё на Zend монолите с ужасным кодом. Решил перейти на Symfony. Но теперь вопрос: как эти три сервиса разнести?

Можно конечно в routes.yml сделать несколько хостов и держать все на одном монолите просто в разных папках src/backend, src/frontend, src/api.

Можно сделать все три абсолютно отдельных инстанса приложения (3 установки приложения), что звучит здорово. Но как быть с Entity? Они все работают с одной и той же базой. Условный User есть во всех трёх приложениях. Копировать Entity из одного приложения в другое? Звучит странно. Но и монолит как-то не очень хочется. Как бы вы поступили?

Решил перейти на Symfony.

Я бы для такого перехода начал с постепенного обновления того монолита, какой есть.

На легаси я сначала ставлю Psalm на слабом 9-ом уровне, чтобы он хотя бы проверял, что не побьются классы при рефакторинге, и искал несовместимости с каждой версией PHP. И постепенно выправляю недочёты, доведя до прохождения 6-го уровня.

Потом поштучно довожу классы до вида, совместимого с Symfony, чтобы потом было проще перейти на новый фреймворк. Постепенно в Composer подключаю symfony/* компоненты и внедряю их для работы параллельно со старыми.

И уже при желании я бы это разносил по папкам внутри src.

Как эти три сервиса разнести?

Пока бы оставил как есть. А если бы потом захотел вообще разнести проекты, то сущности бы оставил только в api/src, а backend/src и frontend/src сделал бы на простыми фронтендами с запросами к этому api. Но это уже другая история.

Дмитрий Елисеев
elisdn.ru
Комментарии (1)
Максим (@myks92)

Добавлю комментарии от себя, возможно будут полезны.

Мне кажется тут вопрос больше архитектурный, нежели фреймворка. Потому что переписывание на другой фреймворк - вопрос инфраструктурный. Поменяли настройки, другие специфичные вещи для фреймворка и всё работает на новом фреймворке. Сложности возникают тогда, когда фреймворк проникает глубоко в код. Тогда выход один - отделять сервисный и доменный слой от фреймворка. Чтобы фреймворк остался только в контроллерах, либо отделены интерфейсами.

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

Далее нужно понять как будут развиваться приложения backend и frontend. Если они планируются переписываться на UI фреймворк вроде next js или nuxt, то это одно. А если UI останется на Symfony/Zend это другое. Но в целом нужно стремиться к тому, чтобы эти приложения взаимодействовали через api (http). Тогда они будут гибче, а все сущности лежать в одном месте в приложении api. Даже не смотря на то, что если UI останется на Symfony или Zend, то для этих приложений можно сделать HTTP php Client, который будет запрашивать данные по api, а не напрямую из сущностей. Это позволит сущности вынести в api и оставить фронт и бек независимыми, в дальнейшем готовы к быстрому переписыванию на NextJS.

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий

Или войти через:

Google
GitHub
Yandex
MailRu