Alex Wells

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

docker-compose'ом это собрать выйдет в 10 раз быстрее, и на сервере нужно будет буквально только docker и поставить. Конечно, начать с простенького варианта (просто один компоуз на все окружения).

Не совсем ясно, используете ли вы одну dev ветку или по одной на фиче. Первый вариант в топку - иногда релиз фичи надо отстрочить, отменить либо наоборот зарелизить прямо сейчас. Если в это же время на ветке будет куча недоделок с других фич - так не выйдет.

Второй вариант лучше всего с ПРами, а не мерджами напрямую в главную, даже если из команды их никто не смотрит - просто потому что девелопер сможет посмотреть, че он там накалякал перед мерджом. Ну и CI/CD ерунда автоматически становится доступной и простой, если речь об любом популярном git хосте (github/gitlab/bitbucket).

Собирать все лучше всего на CI-ке, там часто описано все с екзамплами (в т.ч. для сборки фронта и бэка) и есть кнопочки, с помощью которых можно прямо оттуда сразу релизить на серваки.

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

Просто залейте фронт на CDN-ку любую (cloudflare, aws) и будет вам счастье.

Мы на проекте решили использовать транзакции везде, кроме роутов только на выборку. В том числе и в джобах.

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

Есть минус - дедлоки. По-нормальному это решается какой-нибудь doctrine, либо повтором транзакций (если реально), либо фиксами долгих транзакций.

Нету ничего, что может делать "любой" фреймворк. Есть то, что может делать любой из популярных фреймворков.

Говоря об бэкэндовых HTTP фреймах, они НЕ занимаются:
- загрузка классов к этому не относится - этим занимается composer.
- отображение ошибок так же к этому не относится - этим занимается какой-либо фронтэнд.
- "готовые методы запросов в базу" так же к этому не относятся - это задача ORM, одну из которых фреймворки обычно предлагают как рекомендованую.

Они (или предлагаемые ими first-party решения), обычно, могут:
- раутинг
- dependency injection/container
- сессии
- валидация
- логирование
- хэндлинг ошибок
- работа с файлами
- кэш
- очереди
- консольные команды
- расписание выполнения чего либо
- хэши, криптование
- почта

Иногда шаблонизатор, аутентификация, авторизация, интернациолизация, веб-сокеты, event bus, тестинг.

laravel-mix к php отношения не имеет. Это инструмент для фронтэнд разработчиков.

По laravel-mix есть целая отдельная документация. Если кратко - yarn && yarn watch.

Список стран можно хранить в конфигах. Если так уж хочется - в БД, но без перевода.

Ну а потом по ключу доставать перевод где нужно. Хранить переводы в БД - не нужно, если только это не какие-то посты в интернациональном бложике.

А как вы думаете, что производительней: целая БД, разрабатываемая на быстром c++ с кучей оптимизаций, где ВСЕ заточено под ее нужды, или какой-то рыхлый класс-обертка в пхп? Как думаете, сколько памяти займет mysql для обхода миллиона записей, а сколько пхп?

.env файл не загружается в гит. На то он и env (environment - среда), что бы каждый раз настраивать его под нужную среду. Так что в проде он тоже используется.

"It is important to remember that this setup should only be used for development. For production you should still set your environment variables in the standard way" - написано в статье. Дочитывайте до конца) the standard way = .env

Начнем с того, что от "легкого фреймворка" вам легче не станет. Написание API-шного бекенда не изменяет бизнес логику и вам пригодятся все фишки "обычного" фреймворка.

Про админку: если вам действительно важно, что бы админка была на SPA, и вам не лень писать еще одно приложение для этого - тогда вам нужны два приложения. С другой же стороны, админка на SPA не нужна почти никогда и вместо нее проще использовать какой-нибудь пакет-генератор под ваш фреймворк. Никто не запрещает вам сделать часть приложения SPA-шной, а часть - обычной.

Так что тут все зависит от того, что это за админка и в каких целях/где она будет использоваться.