Intro and Styling with Laravel Pint

Link to the repository

[Only for premium members]

Welcome to this course about reviewing a simple Laravel API. In this course, I will review the code and implement the changes.

Intro: The POINT Of This Course

Someone asked me to review this API project code (repository link at the end of this lesson) with just a few Controllers:

Route::apiResource('orders', OrderController::class)->except( ['update'] );
Route::patch('orders/{order}', [ OrderController::class, 'update' ]);
Route::put('orders/{order}', [ OrderController::class, 'replace' ]);
 
Route::apiResource('owners', OrderOwnerController::class);
Route::apiResource('owners.orders', OwnerOrdersController::class);

While looking at it, I realized it would be a great candidate for not only giving advice but actually making the changes I suggest.

So I've made exactly that: I spent a few days on refactoring and then spent a week writing it out in these 15 lessons.

The main problems I focused on:

• The code was written "Not in Laravel way": core features were not utilized enough: Resourceful Controllers, Route Model Binding, API Resource returns, Exception handling, etc.
• Over-complicated structure for Responses: Base API Controller + Trait
• Too long Controllers with unnecessary try-catch blocks
• Duplicated code with no specific reasons
• Not enough automated tests

From a practical perspective, my goal was to eliminate some unnecessary files, structures, and methods, making the codebase shorter and easier to understand.

By the end of this course, the routes will be shortened to this:

Route::apiResource('orders', OrderController::class);
Route::apiResource('users', UserController::class);

Of course, I couldn't just blindly delete the parts of the code, without making sure I didn't break anything. With API, you (almost) can't introduce breaking changes in the routes/request/response structure. That's why I took a slower approach of doing it step-by-step, writing automated tests along the way.

I also tried to mimic the real-life scenario, how I would do it if I worked at a real company, and tried to review/refactor the project before the "live" launch.

My goal was to explain not only WHAT to change but also WHY I'm changing it. And I'm not always right, so you can challenge/question my decisions in the comments.

Each lesson will have links to the specific commits in the GitHub repository related to that lesson. Also, you'll find links to the Laravel documentation and other related resources.

So, let's do some refactoring?

Let's Begin: Fix Code Styling with Pint

The first thing I usually do when reviewing the code is run Laravel Pint for code styling. Then, my eyes don't stop on some weird spacing issues, and I am entirely focused on reviewing the functionality.

./vendor/bin/pint

Here's the result: 68 issues fixed.

Here's the screenshot of some changes made:

What do we see here:

• Weird unnecessary...