Нет, цели разные. На клиенте для ux на сервере для консистентности.

Хороший пример всякие вадидации уникальности email. На клиенте у тебя по изменению поля отдельным запросом ты проверишь занято или нет, а на сервере можно просто констрейнт в базе повесить и кидать исключение

Dry больше про бизнес рулы. Валидация длины инпута редко есть бизнес рул.

Всем привет! Подскажите плз: заказчик хочет к бэку подключить второй клиент в нём функциональность отличаться не будет, только дизайн. Моя задача создать 2 БД и со 2 клиента чтобы туда инфа попадала. Нашёл вот такой вариант https://symfony.com/doc/current/doctrine/multiple_entity_managers.html в этом случае мне просто все сущности надо будет продублировать для новой базы и по идее всё должно быть норм. Вопрос в том правильный ли это подход делать так или лучше клонировать бэк полностью или ещё какой-нибудь вариант есть о котором я не знаю?

А почему второй бд? Это требование 1 бек - 2 фронта, 2 базы?

Требование 1 бек 2 фронта. Ну а с учетом того что приложения будут у разных подразделений то пользователи и контент не должны пересекаться и я сделал вывод что Бд тоже нужна отдельная.

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

А почему бы просто не поднять второй инстанс приложения с пустой бд? Как будут разруливаться две одинаковые базы в одном приложении? Что если во втором приложении будут какие-то отличия в логике от первого?

И не проще ли написать логику разделения контента между юзерами, чем зачем-то иметь вторую, которая точная копия первой?

Это не обязательно. Но вопрос в другом, админка для редактирования контента будет также разная? Или один менеджер может редактировать данные других?
Просто кроме фронта это же ещё и логика Бека. Если требования, что бы вообще все было отдельно, то только клон от каркаса. Можно оставить одно ядро, а верхний уровень (контролёры, инициализацию, конфиги) оставить каждому из приложений свой. На уровне базы рулить к примеру добавлением project в важные таблицы и добавлять к запросу. Но опять же, все должно быть от требований заказчика и до какого дня у вас логика будет одна и та же.

Вот насчёт двух баз в одном приложении там вроде не сложно, как раз здесь https://symfony.com/doc/current/doctrine/multiple_entity_managers.html описывается как сконфигурировать, как энтити менеджер вызывать в зависимости от того в какую базу хочу сохранять, вот с админкой тоже пока не понятно у меня соната и как там все это дело для второй базы сделать пока не знаю. Насчёт изменения функциональности я думаю что если одно подразделение захочет какую-то доп функциональность то наверное новые контроллеры писать к которым один клиент будет обращаться а другой нет?) Но вроде вопрос об изменении функциональности пока не стоит. Проблема только в том что одно приложение два подразделения продажников поделить не могут.

Сконфигурить несколько em не сложно. Вопрос в том нужно ли оно. Какие-то обновления логики - они будут выкатываться для обоих версий приложения или же со временем функционал будет расходиться и рано или поздно это будут вообще разные аппликухи?

А если потом эту же аппликуху захотят для третьего департамента - будешь третью базу создавать?) выглядит костыльно. не лучше ли в самой аппликухе реализовать разделение контента между юзерами в зависимости от их департамента? И тогда хоть 100 департаментов подключай, ничего в аппликухе менять не нужно

Плюс что делать с контентом, который должен быть доступен обоим департаментам? Копировать из базы в базу? А конфликты как разруливать?

Звучит как хороший план)) Но я вот сейчас с проджектом подробнее пообщался говорит что в будущем логику  одного из приложений надо будет сильно менять. В данном случае нет смысла разделять контент и проще тогда брать и второй инстанс создавать?

Админки будут разные. Говорят в скором будущем логику одного из приложений надо будет сильно менять.

Имхо или второй инстанс приложения или разруливать в одном. Вторая база - самое кривое решение, я считаю.

Всем привет, ребята а кто-то из вас использует API Platform? нужен совет

Скорое будущее это через год, два, три. Должны быть сроки. Если через месяц - нет смысла клонировать, лучше с нуля создать со своей бд. Если через год, то это может ещё 100 раз изменится, а логику 2 бд и разных доступов поддерживать сейчас, а потом вообще выпиливать.

Использовал, но не долго, не понравилось, но для CRUD rest api вполне сгодится

Спасибо за помощь🙏