vism

Массовое заполнение зло. Полностью теряется контроль над данными.
Никогда не использую.
Вобще вся эта магия типо красивая, а по факту "подложенная свинья", поддерживать всю эту магию еще та проблема.
Код должен быть в первую очередь максимально понятен полностью без текстовых комментариев, легко рефакториться и дебажиться.

Вобще best practices у него не плохие, но конкретно этот пункт похож на 99% статей о использовании репозитариев в ларавел. Бред непонятно кем начатый и индусами распространенный.

Апдейт.
Смотрю вы вот тоже репозитарий упомянули, вас тоже эта зараза коснулась, не поддавайтесь ей. Просто изучите что это и для чего.

там все далеко не просто.
досконально изучите laravel passport.
Неужели вы ждете, что вам тут на пальцах опишут то, что описано на дестяках литсах документации?

Отвечая на ваш вопрос. Достаточно токен без сессии. помогло? :)

ох блин, он зашил где-то в ядре...
Помоему в 6.0 его оттуда вынесли и позволили менять :(
Где именно уже не помню, но проблема популярна.

грузить новые на S3
При получении проверять если ли файл в С3, если нет, то брать с локалки.
Я так делал.

Другой вариант флаг в базе данных.

госпади, еще один хомячек не читающий документацию.
на.

$category_group = CategoryGroup::with(['slides.items', 'categories.items'])
        ->where('path', '=', $category_group_alias)->first();

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

А если нужен пакет обертка над другой системой, то надо искать по ней на гитхабе допустим.
А если вы сами будете писать адаптер на основе интерфейса для какой то фабрики типо Кэшира потратите в разы больше времени.

верно все, для этого и придуманы морфы. Оно даёт красоту решений.

Да, да 99% хомячков делают Repository даже не понимая зачем, и в качестве источника данных только БД и eloquent...
Да, правильно делать Service для логики. и DTO для передачи сложных данных в Service.

Во view передаете всё что хочется, ведь данные для view готовит контроллер как вы захотите.

В общем, хотелось бы услышать/увидеть, как кто делает на реальных проектах

На реальных проектах гонют коней и 99% логика хрен знает где и как, передается через пень колоду всё :)
Бизнесс не любит платить за красивую архитектуру ибо в раза 3 дольше и в перспективе редко выстреливает.
Да есть места, где она сэкономит времени, но часто это оверхэд.
Но минимум Сервис слой лучше ввести.
Другое дело, что если его ввести не правильно!!! а часто так и бывает, если вы не синьор или архитектор, и потом эти кривые сервисы мешают, а не помогают. Но попытка не пытка, темболее если заказчик готов вам платить раз в 5 больше, чем если бы писали на моделях...

Да, да все плохо.

Всегда отключаю only_full_group_by :)

Щас хэйтеры налетят, но прописывать десятки полей это жесть, и потом поддерживать если структура таблиц меняется

верно мыслишь.
Сервисный слой называется.
В сервисах содержится бизнес логика, а в моделях релейшены, скоупы и т.п.

Сделайте не
Document::select('documents.*', 'c.*', 't.*')
а
Document::select('documents.*'')
и
->groupBy('documents.id')

другого варианта насколько я знаю нет.

Вместо whereHas, использовать whereExist, и этот код преобразованый в query builder

select * from `products` as `laravel_reserved_0` inner join `products_gifts` on `laravel_reserved_0`.`id` = `products_gifts`.`gift_id` where `products`.`id` = `products_gifts`.`product_id` and `laravel_reserved_0`.`id` = 4

Луйший bouncer - вроде так.
Почему лучший не вспомню, по я для себя определился с год назад.

Можно из по signed url получить временную ссылку прямо через бибилотеку laravel.
Не ларавелевские signed url ф прямо амазоновские.