5 Things you should NOT do in Laravel

4 min readMay 22, 2021

Laravel is one of the most popular PHP frameworks to be used today. Using Laravel, everything is working seamlessly. Because most of the features that we may need for building the app are already provided by Laravel.

However, be aware of all of these features. Because everything is working great, sometimes we don’t even think about the performance that our app may have. We may not be using the OOP properly or maybe we select the wrong technique when building the app. So here, based on my experience, there are several things that we should not do in our Laravel apps. Most of my points there are not only related to Laravel, but it could be related to the general idea of how we work as web developers.

Content Overview

One Controller for Everything
Procedural Code
Local for Everything
Nested If-Else
No Log, No DB Transaction

#1 One Controller for Everything

I’ve seen some developers treat the Laravel controllers to do everything. So we’ll have a very big fat controller with thousands of codes inside. Well, it might not be a good idea, because controllers should only handle one specific thing. For example, if we want to have a controller that handles the profile of the user, then we may need the ProfileController. What if we need another controller to handle the User transactions? Then, we should create another controller, for example, ProfileTransactionController, instead of having all of the transaction functionalities inside the ProfileController.

Route::apiResource('profiles', ProfileController::class);Route::apiResource('profiles.transactions', ProfileTransactionController::class);

This configuration also supports the SOLID principle where the first principle is stated that a class can only have one responsibility.

#2 Procedural Code

When we have some codes running to do the specific thing, we may need these codes again in other places, in other words, the codes need to be reusable. So, what are we gonna do? Of course, we need to make our codes as modular as possible and avoiding writing…