Alex Wells

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

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

Парень, возможно, использовал какие-то алгоритмы апскейлинга, но у него изначально была картинка адекватного разрешения. У вас же картинки в 300-400p, так еще и сжатые jpeg'ом. Улучшить их качество не выйдет.

https://rachidlaasri.com/php/laravel/macro/2018/04...

Если уж так сильно нужно, хотя ради такой мелочи я бы не стал что-то изобретать.

Потому что нужно читать правильный раздел: https://laravel.com/docs/5.7/hashing

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

Ну и куда вы запрос отправляете? Я вижу, что это DELETE запрос, значит идти он должен, судя по вашим раутам, на /posts/123, где вместо 123 айди вашего поста. Если изначально предполагалось делать что-то другое, а не DELETE, то меняйте его..

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

Вот сниппет с моего проекта. Собственно, я обычные реквесты не использую вообще, и вся валидация всегда в FormRequest'е, так что такое мне подходит. Валидировать как обычно - в rules, самыми обычными правилами, только названия параметров должны начинатся с { и заканчиватся на } - это на всякий случай, что бы нечайно не смешать разные параметры.

use Illuminate\Foundation\Http\FormRequest;

abstract class Request extends FormRequest
{
    /**
     * Get data to be validated from the request.
     *
     * @return array
     */
    protected function validationData()
    {
        return $this->all() + $this->routeParameters();
    }

    /**
     * Get route parameters for this request and wrap them into {} each.
     *
     * @return array
     */
    protected function routeParameters()
    {
        return collect($this->route()->parameters)
            ->mapWithKeys(function ($item, $key) {
                return ['{'.$key.'}' => $item];
            })
            ->toArray();
    }
}

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

Можно сделать EnumScreenSize, в котором написать некую логику, отдающая нужный инстенс исходя из Dimension. Первые 5 строчек уже сократятся в одну. Это же позволит вместо десятков >= <= && || делать size == EnumScreenSize.FULL_HD. Если scale величины относятся ко всем экранам в целом, и их можно вынести в энам - так тоже стоит сделать. Вместо if'ов можно использовать switch, и хоть он громаздкий, но выглядеть будет проще. Если setScale() и другие методы отдают this, то можно chain'ить их.

Вопрос уже был, вот мой ответ: Как управлять ролями и правами Laravel 5 и VUE.JS?

Да, отправлять клиенту client_secret это полный бред. Но никто вас об этом и не просит, собственно. С passport'ом я не работал, но перечитав всю доку я так и не нашел место, где client_secret (не _id) передавался бы клиенту. Единственное, что я там увидел - запросы к своему же серверу с этим параметром, а во всех других местах, где юзера редиректит, я вижу только client_id.

На TS есть фреймворк, называется Nest. Он изначально использует модульную структуру, и там она реализована достаточно хорошо. Гляньте.

Далее как я делаю в Laravel проекте:
- /vendor - зависимости компоузера, в виде сторонних библиотек и компонентов symfony/laravel. Там есть весь базовый функционал, как, например, работа с БД. Такие зависимости в любом случае будут тесно связанны с логикой приложения, и думать об их удалении не стоит вообще. Максимум, что вы можете - построить слой абстракции над /vendor, но это ПЛОХАЯ идея.
- /app/Ship - увидел это в другом фреймворке, называется Apiato. Сам по себе он хрень, но сама идея мне понравилась. Этот "корабль" - слой твиков, временных фиксов, загрузчиков и другого, что касается каких-то базовых, недостающий частей фреймворка/библиотек, и используется всемя модулями в проекте. Например:

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

В общем все то, что относится ко всему проекту в целому. Структура - хаотична.

Таким образом в третьем, финальном слое, у меня только чистая бизнес логика:
- /app/Containers - контейнеры - пафосное слово на замену модулям. Идея та же. В каждом контейнере, в корне, лежит класс с названием контейнера, в котором находятся такие штуки как: краткое название для авто-префикса ресурсов, список провайдеров и миграций (назовем их "штуками из фреймворка", к структуре не относятся).
Структура каждого контейнера:

• API/ - все, что касается хттп апи приложения
  - Controllers/ - контроллеры хттп
  - Requests/ - классы form request хттп
  - Tests/ - функциональные тесты этого апи
  - routes.php - файл раутов
  
• Broadcasting/ - все, что относится к броадкастингу через сокеты
  - Events/ - сами классы эвентов
  - channels.php - файл регистрации каналов броадкастинга
  
• Configs/ - конфиги этого конкретного контейнера (и НЕ его зависимостей)
  
• Extra/ - иногда бывает что-то, немного выходящее за рамки контейнера, но еще не входит в Ship. Идет сюда.
  
• Middlewares/ - хттп миддлвейры
  
• Database/ - все, что связано с базой данных
  - Factories/ - файлы пхп, регистрирующие фабрики моделей ларавель
  - Migrations/ - классы миграций
  - Seeders/ - сидеры базы
  - Setup/ - классы-фабрики, обложка над Factories
  
• Enums/ - энамы
  
• Exceptions/ - исключения
  
• JsonResources/ - гсон ресурсы
  
• Models/ - eloquent модели
  
• Providers/ - провадйеры
  
• Services/ - маленькие классы-сервисы, содержащие всю бизнес логику, не привязанные к ХТТП. Каждый сервис выполняет либо одну задачу, либо несколько мелких задач одного типа. Singleton
  
• Traits/ - трейты
  

Все, что я выше указал - либо часть самого языка (как трейты), либо часть фреймворка Laravel. Гуглите.

Есстественно, под разные фреймворки внутренняя структура каждого контейнера может и будет менятся.

PS: БД одна для всего проекта. Зачем вам разные БД, когда есть разные таблицы?)
PS2: то, что вы себе представили - называется микросервис. Выполняет какой-то небольшой набор задач, имеет отдельную базу и вообще изолирован от всего остального. Но раз вы задаете такие вопросы, вам они точно не нужны.

Вот то, что вы хотите: https://router.vuejs.org/guide/advanced/lazy-loadi...

Загружает части кода по нужде, и кэширует, естественно. Правда я все равно не понимаю, откуда у вас в app.js несколько МБ кода набралось.