Intro and Styling with Laravel Pint

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 spaces in function parameters: ( LoginUserRequest $request ) fixed to (LoginUserRequest $request)
• Curly brace for function beginning should be on the new line
• Empty line before return in the function

You can see all changes in this GitHub Commit.

Generally, Laravel Pint is built on top of PHP-CS-Fixer and uses its own code styling standard called laravel. You can read the list of all of its configurations here on GitHub:

But if you want to use another standard like PSR-12, you can create a pint.json file in the main folder of your project.

pint.json:

{
    "preset": "psr12"
}

Notice: Also, you can run Pint in --test mode, first, to just check if there are any issues, without auto-fixing them.

In my case, I don't care that much which styling standard is used. I care about easily reading the code. That part is fixed now. Let's move on.