jazzus

Написать тесты. Например, PHPUnit для php. Для каждого языка есть много разных решений. Можно проверить на ошибки, права доступа для разных пользователей, что видит-не видит на странице, проверка логики и т.д.. Тестировать руками при каждом чихе это жесть и малоэффективно. Тесты очень помогают, ловят много мелких нюансов, связанных с логикой и правами доступа. Поэтому лучше писать тесты до разработки, во время разработки и после разработки.

LaravelRequest автоматом вернет ошибки и код в ответе. Т.е. можно не писать велосипеды.

Достать ошибки в js скрипте (фреймворк VUE)

// аякс запрос
.catch((error)=> {
  this.errors = error.response.data.errors;
});

подсчитать ошибки в computed

errors_count: function () {
   return Object.keys(this.errors).length;
},

будет доступно errors_count

Что говорит Ларавел? Он говорит разделить на контроллеры. Для продуктов ProductController и т.д. Именовать методы index show update и т.д. Массив данных для вьюхи можно получать из своего класса, но можно и так оставить если в контроллере данных мало. Я бы пересмотрел логику формирования данных и наименований т.к. вроде задач сложных нет, но процессы непонятные какие-то $arrayUrl alias entity ит.д.

$user->cars()
     ->whereNotNull('title')
     ->has('models')
     ->get();

Только непонятно, как cars могут не иметь models и как title может быть null

С помощью json методов

$this->postJson(route('register'), $data)
     ->assertCreated();

Тогда так

$users = User::doesntHave('phones')
             ->where('money', '>=', 100)
             ->get();

// в User
public function phones()
{
   return $this->hasMany('App\Models\Phone');
}

return CommentResource::collection($comments);
total в комплекте, взято отсюда

В ресурсные маршруты не нужно передавать названия параметров.
route('posts.show', $post)
Т.е. либо ресурс либо его идентификатор если ресурса нет. Ларавел автоматом свяжет и в контроллере уже будет нужный ресурс

public function show(Post $post)
{
  dd($post);
}

Если key не id, а например slug то определить в модели так
protected $primaryKey = 'slug';
В бд не нужно давать префиксы для полей типа $post->post_id. Правильно делать $post->id, name, active и т.д. т.к. post всегда и так будет перед ними в названии переменной.
И ресурсы нужно называть не post, а posts в роутах
Route::resource('posts', 'PostController');

Если закрыть сам переход юзера по маршруту и просмотр json то сделать middleware isAjax c проверкой

if (!$request->ajax()) {
 abort(404);
}
return $next($request);

При попытке зайти отдаст 404. Но это не "защита" т.к. содержимое в network всегда есть в полном составе. Лучшая защита это отдавать только те данные, которые юзер видит на странице и не больше. Т.е. использовать API Resources, protected $hidden в моделях и точно составлять json ответ

Помните, по умолчанию RouteServiceProvider включает ваши файлы роутов в группу пространства имён, позволяя вам регистрировать роуты контроллера без указания полного префикса пространства имён App\Http\Controllers.

Route::namespace('Backend\Docflow\Document')
     ->name('document.')
     ->prefix('document')
     ->group(function () {
  Route::get('edit/{document}', 'DocumentController@edit')->name('edit');
});

Код должен быть такой, чтобы открыл файл и понял логику. Без документаций и комментариев. Такое у меня получается делать только с большим количеством файлов. Т.е. по-максимуму задействовать функционал Лары (там уже куча своих классов) – это в первую очередь. Остальное в своих классах. Основные простыни у меня в моделях т.к. все запросы через scope(чтобы быстро компоновать новые запросы из скоупов-частей). Решаю использованием трейтов – убираю туда скопы по темам, чтобы быстро получить доступ к группе связанных запросов и быстро их править или составить новый. Некоторые такие трейты использую в разных моделях. Например скоупы ofActive/ofApproved можно дофига где использовать. Также делаю репозитории и сервисы. Не потому что надо, а потому что мне так удобней. Т.е. книг совершенная архитектура не читал, пару раз загуглил, но там люди не особо убедительно объясняют (либо я не догоняю), поэтому делаю как нравится мне. Цель -простота и наглядность логики. Чтобы запускалась не страница кода, а класс. Все изолировано и с проверкой аргументов. И есть возможность быстро поменять логику (по методу кирпичиков). Сервис классы - логика, проверить, запустить, исполнить итд. Репозитории чтобы сформировать массив данных для фронта. Коллекции, наборы роутов, текстов и т.д. Обычно создаю базовую репу от которой наследуются остальные, т.к. много общих данных. Минимум абстракций и автоматизаций, конкретные понятные прямые действия с минимумом if. Короче много файлов, в каждом минимум кода, все поделено. Но это мой непрофессиональный опыт т.к. профильные вузы не заканчивал, в гугле не работал, занимаюсь своими проектами и ответом нужно пользоваться с осторожностью.

это что с версии выше 5,8 он не работает?

Примерно с этой версии Laravel стал генерить миграции с bigIncrements ids тогда у многих посыпалось (кто не читал описание апгрейда, конечно)) как правильно ответил Алексей пропиши в blogs

$table->bigInteger('user_id')->unsigned();

на Laravel 6

Начинать лучше с 7й т.к. по сравнению с 6й есть моменты где можно потом нарваться на рефаукторинг)