Добрый день возник вопрос насчет взаимодействия фронта и бэкенда, не

понимаю какой процесс правильный?

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

Я думал что фронт должен верстать в этих самих блейд шаблонах, а бэк должен выводить данные на эти блейды

все индивидуально. если фронтендщик знает про блейд - то он. Если не знает - то бэкенду будет проще "натянуть" верстку

То есть при дальнейших задачах, процесс продолжится и фронт так же будет отправлять html?

1. интегрировать нужно тогда, как верста будет более менее стабильная и принята. 2. располагайте ее на git`е , при ее изменениях - измените и у себя в ларавел

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

это норма для микрофирм

видимо так и есть🥲

А какие пакеты для хранения переводов можете порекомендовать, я сам использую astrotomic, может есть и другие более удобные Нашел также от spatie, но он в json хранит

Беги от json в базе

Почему? Есть задачи которые можно через json в базе решать

Очень интересно послушать аргументирование

отсутствие контроля данных поступающих в базу. бОльшая сложность вычислений, отсутствие нормальных индексов, и в целом скорость работы снижена, отсутствие нормализованности в любом виде. я могу бесконечно этот список продолжать, спроси еще у gpt, думаю он тоже парочку подкинет

тут даже аргументировать нечего. 90% случаев использования json в базе лень разраба, который проектировал базу

От части да, но есть проекты где реально нужен json

почему бы не использовать в таких проектах mongo ?

Твое не понимание зачем - это не аргумент почему его не надо использовать)

ну не знаю, использовать кучу разных баз не лучшее решение

несколько более узко специализированных баз ? у каждой из которых есть своя задача ?

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

я - никакой, нет задач. в моем пакете с пакетами есть такой - https://github.com/mcamara/laravel-localization

но он вроде не для хранения используется?

1) причем тут структура базы и контроль данных поступаюших в нее, о контроле нужно думать до взаимодействия с инфраструктурой 2) добовляя джсон в поле, нужно изначально подумать о том, будет ли индексация в этой колонке, очевидно, что если будет, то джсон не вариант, есть куча задач, где индексация будет во вред 3) экономия на спичках, я скорее поверю, что в приложении куча дублирующих запросов, чем узкое горло из за джсон 4) нормализация это не панацея, конечно порнографию в структуре не надо создавать, но слепо следовать нормализации во всем, приведет к тому, что даже простая задача будет иметь кучу таблиц 5) gpt аргументирует почему и где джсон таки уможно использовать)

Ну опять же, исходя из твоих слов приходим к тому, что json удобен для небольших метаданных, но не для мегабайтов(гигабайтов) текста в разных локалях

Я хранил например настройки картинок в джсон хранил, а там было 15 свойств в обьекте, картинки генерились кнопкой из админки и не слишком часто, обновлялись тоже не часто, по этому спокойно можно было хранить прямо у сущности в поле settings, не создавая отдельной таблицы