Илья Чубаров

На сколько я вижу это инфраструктурный код - поэтому проще его тестировать функциональными тестами (которые в папке Laravel называются Feature)
1) Решается функциональным тестом, будет использоваться тот который укажете - подойдет просто оперативная память
Имеется в виду - что вы просто отправляете запрос и ждете определенный результат
2) Можно задать в тесте - а лучше в файле окружение env.testing
3) Почему у вас ищет метод environment в Container без контекста сказать сложно, этот метод в классе Application

И тот и другой инструмент под свой круг задач вполне подходит.
Livewire - как вам ответили выше, хорошо подходит mvp, небольших сайтов, где нет большой нагрузки и грандиозных планов.
Хотя кто-то берет на себя риски и делает все на нем. Из подводных камней, это у вас связаны руки в js, так же на каждое действие, он будет слать запрос на сервер. То есть написали букву в input, запрос на сервер(хотя можно оптимизировать, но тем не менее), в итоге получается такой оверхед на все.
Стоит иметь в виду о смеси ответственностей, точнее livewire будет вас постоянно склонять к этому, так как в классах php у вас постоянно логика фронта.
Еще могут быть не очевидные проблемы, при синхронизации данных, и вам надо будет подставлять задержки.
У меня была проблема с загрузкой файла, в кратце есть две настройки в вашем php.ini и отдельно в файле livewire, в каждом стоит свое максимальное значение размера файла.
Так вот- грузил я картинку по событию change, после загрузки была написана валидация, в кратце файл не грузился и в блок с валидации было пусто.
Проблема заключалось в том, что livewire не как об этом не сообщал и не намекал, просто не грузил файл и валидация не проходила.
Так что будьте готовы решать такие нюансы.
Мой субъективный опыт получился двоякий, с одной стороны мне понравилась скорость, с другой стороны что-то не работает, возможно это временно пока все шишки не набьешь.

С Inertia опыт пока только теоретический, но он уже ближе к нормальному стеку. Просто вам не надо думать о роутинге, api, вывода ошибок.
Врать не буду, ибо фраза:

В теории нет разницы между теорией и практикой. А на практике есть

Поэтому я дополню свой ответ позже - если посчастливиться его попробывать

Вывод
Рекомендую попробовать оба варианта несколько раз, тогда вы составите для себя полноценное мнение об этих инструментах.
Любой продукт который поддерживается и используется сообществом - уже лучше N фреймворка который знаете вы и еще двое людей.
Повторюсь еще раз, имеет место быть, так как для всех копеечных проектов которые живет два понедельника - писать spa - очень дорогое и бессмысленное удовольствие.

Исходить надо из того какая у вас стоит задача:
- Обычный сайт с серверным рендором
Это старая схема, где в Laravel для этого все есть. И базовая аутентификация через cookie и хранением сессий в разных местах.
- Сайт с отдельным клиентом
Тут бэкэнд обычно разделен от фронтенда. От бэкэнда нужно api(restful, graphql), клиент уже реализовывается как правило на js.
Тут уже может потребываться токен.
- Сайт с не одним клиентом
Тут может быть и сам сайт, и может мобильное приложение и любой другой, которой использует API бэкэнда.
Тут Passport более востребован но не обязателен.
- Сайт с требованием выдавать доступ сторонним клиентам
Тут Passport необходим

Проще говоря Passport берет на себя работу по организации аутентификации и авторизации внешних клиентов в ваш бэкэнд и вытекающие из этого последствия:
- хранение
- шифрование
- авторизация
- управление
- реализация Auth2.0

Для просто API laravel рекомендует sanctum

Рассмотрим пример когда вы разрабатываете свой пакет локально.
В корне проекта создается папка и добавляется запись в composer.json вроде такой

"repositories": [
    {
      "type": "path",
      "url": "author/package"
    }
  ]

Подробнее можно прочитать здесь в документации
При такой настройке, пакет создаст ссылку в vendor.

По поводу стандартных команд в Laravel(artisan) тут все индивидуально, к примеру, миграцию можно добавить ваш пакет такой командой

php artisan make:migration name_migration --path=author/package

В команде по созданию factories, за корень берется databasePath, выйти из ситуации след образом.
- В зависимости от контекста менять базовый путь
- Отнаследоваться или создать свою команду для формирования пути при создании фабрики

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

Еще можно воспользоваться консолью:

php artisan make:controller OurController && mv app/Http/Controllers/OurController.php author/package/pathWhereControllerStore

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

Из бесплатных могу вам порекомендовать orchid
Перечислю плюсы:
- Хорошо поддается кастомизации
- Бесплатен
- Документация на русском + разработчик тоже русский(я не приверженец только русского, наоборот за все английское) но часто напрямую обращался к разрабу решал какие то вопросы, на русском было конечно проще.
- Отличная поддержка, регулярно обновляется и telegram постоянная движуха.
- Из коробки есть сортировка, фильтры
- Из коробки некий свой UI Kit которой сводит к минимуму трату времени на отрисовку интерфейса
Минусы:
- Свой подход к разработке и термины, надо потратить время для изучения, но это такое, любое решение требует время для изучения.

Остальное можете прочитать в документации.

С точки зрение работы кода, у вас по двум маршрутам, обрабатывается request в одном контроллере и в одном методе, работать конечно будет.
Но с точки зрения кода - это конечно не perfect. Тут как в классике, "Все смешалось в доме Облонских".
- Контроллер кончено ж должен быть другой, и в данный момент не потому что просто так должно быть, а просто название route и контроллера вызывают диссонанс в первую очередь.
- Во вторых есть такой термин как REST API, и в духе Laravel больше подходит метод show, документация

Еще мне не нравиться ваш namespace Front, и есть ощущение что он больше не нужен, чем нужен.
И наверное category всегда лучше чем cat или c.
Еще можете прочитать про resources

Ну и главное, про сокращение кода:
- "Чтобы не создавать еще метод"(где-либо)
- Чтобы не создавать еще класс
- Чтобы не создавать еще таблицу в базе
- Чтобы не создавать еще ...
Более вероятно будет приводить к плохому коду и путаницы. Мало кода это не равно хороший код. В коммерческой разработке часто очень большая предметная область, с этим надо работать, поддерживать и тому подобное - это порождает больше кода, потому что:
- Лучше (иногда) создать еще метод
- Лучше (иногда) вынести в отдельный класс
- Лучше (иногда) нормализовать и вынести в отдельную таблицу
Advice - Прочтите документацию Laravel✌️

Тут зависит от ваших хотелок. Но самый простой "велосипед" можно в течении минут 10 сделать.
К примеру у вас mysql и есть утилита mysqldump.
Соответственно добавляете команды, к примеру:

php artisan backup:run
php artisan backup:refresh

В них заворачиваете ваш mysqldump, название возьмете из файла конфигурации database.php.