У меня есть проект, который по факту несколько веб сайтов: бекенд, фронтенд и 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. Но это уже другая история.
Добавлю комментарии от себя, возможно будут полезны.
Мне кажется тут вопрос больше архитектурный, нежели фреймворка. Потому что переписывание на другой фреймворк - вопрос инфраструктурный. Поменяли настройки, другие специфичные вещи для фреймворка и всё работает на новом фреймворке. Сложности возникают тогда, когда фреймворк проникает глубоко в код. Тогда выход один - отделять сервисный и доменный слой от фреймворка. Чтобы фреймворк остался только в контроллерах, либо отделены интерфейсами.
Когда код будет отделен от фреймворка, то тогда перейти на новый фреймворк проще. Так же можно зависеть от каких-то компонентов, вроде доктрины. Она везде может быть настроена, так что не специфична фреймворку.
Далее нужно понять как будут развиваться приложения backend и frontend. Если они планируются переписываться на UI фреймворк вроде next js или nuxt, то это одно. А если UI останется на Symfony/Zend это другое. Но в целом нужно стремиться к тому, чтобы эти приложения взаимодействовали через api (http). Тогда они будут гибче, а все сущности лежать в одном месте в приложении api. Даже не смотря на то, что если UI останется на Symfony или Zend, то для этих приложений можно сделать HTTP php Client, который будет запрашивать данные по api, а не напрямую из сущностей. Это позволит сущности вынести в api и оставить фронт и бек независимыми, в дальнейшем готовы к быстрому переписыванию на NextJS.
Или войти через: