Народ кто-то сталкивался с такой проблемой? Есть к примеру энтитя Page. Она софт делитабл, т.е. есть флаг у нее isDeleted. Так же у нее есть юник поле урл
Уникальный ключ можно навесить на два поля - url и deleted_at (софт делит лучше не флагом делать, а датой удаления, если нулл - значит не удалена).
Alexander
Юра
Кстати интересно да
Юра
А как себя нул в юник ключе поведет
Юра
Он будет считаться как уникальное значение?
Alexander
Надо проверять, думаю как и ожидается - как уникальное.
https://symfony.com/doc/current/reference/constraints/UniqueEntity.html#errorpath
Alexander
Вот пример с двумя полями
Alexander
А как сейчас модно делить монолит на "приложения"?
Есть много старого кода, есть несколько точек входа, например /web/api/public/internal с разными конфигами и прочим.
Документация предлагает сделать несколько кернелов https://symfony.com/doc/current/configuration/multiple_kernels.html
Но смущает замечание:
> "Creating applications with multiple kernels is no longer recommended by Symfony. Consider creating multiple small applications instead."
У нас сейчас сделано примерно так https://stackoverflow.com/questions/45925697/more-than-one-application-per-project-repository-with-symfony-4 и это настоящий ад, когда этих эпликейшенов 8 штук.
Может у кого есть опыт?
Alexander
Боюсь что смысл давно утерян.
Если грубо, то по одному роуту разные контроллеры резолвятся, в зависимости от кернела (в нашем случае APP_NAME).
Ну и контейнеры, конечно, тоже разные.
Иван
Боюсь что смысл давно утерян.
Если грубо, то по одному роуту разные контроллеры резолвятся, в зависимости от кернела (в нашем случае APP_NAME).
Ну и контейнеры, конечно, тоже разные.
ну делать или одно приложение с роутами по хосту
или разные
Иван
в принципе с друпалом тоже игрались игрались с мультисайтингом на общей кодовой базе да как-то бросили
Юра
Мне кажется вся суть микросервисов в разнесение репов, сервреров и т.д.
Юра
Просто делаешь два симфони проекта и всё
Юра
Общий код сабмодулями
Юра
Типо там энтити к примеру
Юра
Либо лучше не сабмодулями даже а композером
Alexander
Возможно вы путаете с окружениями, с ними у нас примерно так и было, но уже давно в порядок привел эту часть )
У нас саас сервис с несколькими тысячами доменов и с десяток своих сервисов, большая часть из них в одном монолите живёт, но имеют разные точки входа.
Alexander
Мне кажется вся суть микросервисов в разнесение репов, сервреров и т.д.
Сам склоняюсь к вынесению общего кода в отдельный репозиторий (бандлом, например) и разделением сервисов по разным репозиториям. До МИКРОсервисов нам ещё далеко :)
При таком подходе смущает что в общем бандле будут сущности, как то это мне кажется не по фен шую. Да и есть вопросы к срокам такого рефакторинга, ищу попроще подходы.
Юра
Рефакторинг и микросервисы вещь несовместимая
Юра
Заколдуй все через queue bus и общайся между сеовисами сообщениями
Юра
Там целая наука вообщем. Как по мне проблем больше чем профита
Юра
Очень много лишних сущностей вылазит сразу и инфраструктура растет как грибы
Юра
Я вообще не понимаю какую проблему решают микросервисы
Юра
Ты не можешь поменять что-то в одном месте и спать спокойно
Иван
Ты не можешь поменять что-то в одном месте и спать спокойно
рефакторинг означает, что все контракты остаются
Иван
то есть, ничего не должно изменится
Юра
Ага. Ненужные контракты которые порождает сама микросервиснач архитектура
Юра
Архитектура ради архитектуры, вещь в себе
Юра
Какую конкретно проблему решают микросервисы?
Юра
Я знаю только один кейс кому это реально нужно но мне интересно другие услышать
Иван
масштабирование по микросервисам, раздельный деплой
Юра
А что монолит не масштабируется?
Иван
целиком
Юра
Вопрос в том что надо масштабировать
Иван
если нужно обновление архитектуры, то монолит до него может не дойти никогда
с микросервисами такого вопроса не возникает
Юра
Ниче. Недавно обновлял проект с четвертой симфы на пятую. Да пару месяцев ушло, но это возможно. Особенно если тесты есть
Юра
Иде сильно помогает
Юра
И то там больше проблем было с апи платформ а не с нашим кодом
Юра
Деплой раздельный говоришь
Юра
А если у тебя меняется контракт
Юра
Как ты его деплоить будешь
Юра
Тут все наоборот сложнее становится причем в на порядок простл
Юра
Потому что у тебя скорее всего будет очередь какая-то для общентя медду сеовисами типо ребита, и в очереди одновременно будут сообщения разных версий, надо чтобы и то и то обработалось правильно
Dmitry
Потому что у тебя скорее всего будет очередь какая-то для общентя медду сеовисами типо ребита, и в очереди одновременно будут сообщения разных версий, надо чтобы и то и то обработалось правильно
Если монолит предоставляет API для мобильных приложений, которые обновляются на смартфонах по полмесяца, и если работает с API вконтакте и других сервисов, то будет такая же задача с версиями. Так что с монолитом это не сильно проще.
Юра
По-моему проще бизнес логику все в монолите держать, а какие-то задачи требующие ресурсов выносить в воркеры
Nikolay
На работе один большой монолит и к нему в довесок микросервисы
Юра
Просто бизнес логику как по мне лучше не делить
Юра
Вообще тут вопрос такой где кончается монолит и начинается микросервисы спорный
Юра
Усли у меня spa, еать бек апи, и еще пару сервисов которые общаются с беком по апи это микросервисы уже или нет еще
Юра
Или мне надо каждый рест эндпоинт засунуть в свой докер контейнер?
Юра
Они еще дальше пошли теперь и сделали lambda, облачные функции. Давайте каждую функцию засунем в свое облако
Dmitry
Просто бизнес логику как по мне лучше не делить
Если бизнес сложный, то в нём есть несколько областей (производство, продажи, доставка, склад и т.п).
И при автоматизации такого бизнеса вполне логично каждое его подразделение программировать отдельно.
Иначе, если всё спрограммировать одним монолитом, там будут тонны кода.
Юра
А ну это норм. Я против более белкого деления
Юра
Когда внутри одной бизнес сущности начинают делить дальше
Юра
Типо этот сервис рендерит фронт, а этот сервис принимает заказ, а другой обрабатывает, а третий процессит оплату, пятый отвечает за деливери и т.д. и так до бесконечности
Юра
Наверное если ты амазон то это имеет смысл
Юра
Это как вечный вопрос как группировать модули, по типу или по функционалу
Юра
Например почти везде все контроллеры в одной папке, все шаблоны в другой, стили в третьей. Мне кажется логичнее делить по модулям, тут модуль отвечающий за юзеров со своими шаблонами, контроллерами, хелперами и т.д.
Юра
И минимум связей между модулями
Юра
Если у тебя в таоей архитектуре есть несколько функционально слабо связанных модулей, то наверное резонно их разделить на сервисы
Юра
А если у тебч один сервис не может жить без другого, то блин как-то странно их делить
Юра
Я как-то читал статью про микрофронтенды, вот где веселуха )
Юра
На одной странице у тебя и реакт и ангуляр и все это как-то работает криво косо билдится, но они продолжают свой бой ) сложность сборки такая что скоро без ИИ не разобраться
Иван
Например почти везде все контроллеры в одной папке, все шаблоны в другой, стили в третьей. Мне кажется логичнее делить по модулям, тут модуль отвечающий за юзеров со своими шаблонами, контроллерами, хелперами и т.д.
у Валентина Удальцова доклад есть на эту тему
надо по фичам перегруппировать
Юра
Да но сплошь и рядом вижу что так мало кто делает
Юра
Та же симфа к примеру
Юра
К примеру на вью я стараюсь делать так фронт, чтобы вот папку удалил с ненужным модулем и все продолжило работать. А не выискивать по всему проекту где что надо удалить
Юра
То же самое дно к примеру в андроид разработке. В одной папке все ресурсы всего приложения, в другой папке все xml лейауты всего приложения и т.д.
Alexander
Звучит правдоподобно
Alexander
Ну вообще, сколько работаю, во всех проектах для контролеров, энтитей и тд отдельные папки
Alexander
Вроде, так даже в доке симфонии
Юра
Не ну это логично. Решили выкинуть из приложения к примеру какую-то страницу. Нашел папку с модулем этой страницы и улалил. Врятли кто-то когда-то решит удалить например все картинки всего приложения или все лейауты
Юра
Ну вообще, сколько работаю, во всех проектах для контролеров, энтитей и тд отдельные папки
Да то понятно. А я за такую структуру говорю
UserModule
Controller/...
Entity/...
templates
OrderModule
Controller
Entity
.....
Юра
SharedModule
Entity
Helpers
Alexander
Хм, возможно, стоит присмотреться
Юра
Такое возможно сделать бандлами
Alexander
Выглядит вполне неплохо
Юра
Но мало кто так делает