Alex Wells

https://laravel.com/docs/8.x/database#database-tra...

Нормально, если сабов не много. Со временем упрешься в лимит джобы по времени из-за ->each(). Потом упрешься в кол-во нотификейшенов, которые ты пишешь в базу на каждого саба. Еще позже - в отправку броадкаста по личному каналу каждому юзеру, а не всем сразу в какой-то один.

Решай проблемы по ходу дела, нет смысла пытаться решить их наперед.

Напиши оптимизированные запросы в базу. Группирование обязательно на стороне запроса. 99% что это решит твою проблему, ибо данных у тебя точно не много. А если вдруг, то експлейн и индексы в помощь.

Нормально - никак. И судя по примеру, тебе нужно переделать структуру таблиц.

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

Как только в API появятся еще задачи, оба воркера опять будут разгребать только API, пока там не станет пусто.

Для автоматической балансировки есть horizon.

Потому что required не имеет влияния на другие правила. Нужен nullable.

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

Отвечая на вопрос, DB::transaction(callable) откатит транзакцию при exception'е, остальное (ручное) управление - ничего автоматически не делает, за исключением хендлинга нескольких специфичных ерроров, которые сбрасывают уровень транзакции сами.

В общем в ручное управление лучше не лезть, ведь про*батся ОЧЕНЬ легко, дебажить - сложно, а лара не все просчитывает.

Никакое. Eloquent не знает, какие столбцы есть, да и задача поставлена неправильно.

Laravel Echo is a JavaScript library

Под капотом у echo все равно pusher. Клиентские либы для pusher'а общедоступны - выбери любую и используй.

То, что ты хочешь, делается с помощью аннотаций или подобного им механизма.

Только в этом случае ничего подобного тебе не нужно. Разграничивать права нужно не по раутам, а по действиям. Для этого есть policies и библиотеки ими заведующие, типа bouncer. Читай и гугли.

Самое простое решение - прикрыть node.js проксей из laravel. Не ясно, нахера вообще сдался node js в laravel проекте. Какой конкретно юс кейс?

Решение очень тупое и неправильное.

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

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

Поля в доп таблице могут иметь айди поста как primary key без проблем, своя айдишка им не нужна.

json поле типа meta - тоже вариант, но он медленней. Если выборки и связи не нужны или не особо нужны, то это вообще отличный вариант.

Отдельная таблица meta_name и meta_value - это вообще худший из худших вариантов. Ни плюсов отдельных таблиц, ни какого-то профита над обычным json полем (потому что если тебе сильно нужны выборки, то отдельные таблицы дают тебе типы, нормальную индексацию, нормальные констреинты, форейны и прочее, а если не нужны - то json тупо проще отдельной таблицы). Выбирай из двух вариантов выше.

https://github.com/itsgoingd/clockwork

Точку убери с 'as' => 'admin.'

https://laravel.com/docs/8.x/session

Везде пишешь UTC. На сервере, для ПХП, для ларки. Во VueJS берешь и конвертируешь дату в нужную.