DEV Community: Pedro Pessoa

IS DEPENDENCY INVERSION REALLY USEFUL?

Pedro Pessoa — Fri, 13 Jun 2025 21:01:01 +0000

Introduction

You've probably heard of — or even use on a daily basis — libraries or applications in laravel that implement "dependency inversion", but have you ever taken the time to understand what it's actually for, or looked for the best way to apply it in your own project? in this article, we'll explore what dependency inversion is, why it matters, and the best ways to implement it in your laravel project.

Dependency Inversion

dependency inversion is a fundamental software design principle that aims to increase code flexibility and maintainability. in short, it suggests that high-level classes should not depend directly on low-level classes — instead, both should depend on abstractions.

but what does that actually mean in practice?

imagine the following scenario: we have an application where one of the core business rules is sending sms messages to multiple users in the system. this creates an external dependency for something that is actually an internal rule of the system. so how can we address this?

a practical and efficient solution would be to implement multiple sms delivery systems. that way, if one service goes down, another can be activated to send the message to the user.

Usage Example

now you might be thinking, "couldn’t this just be done with a simple if-else?" — and technically, yes, it could. but now think in terms of maintainability and scalability: what if we need to integrate 10 more sms providers? or what if we need to change the behavior of just one specific provider?

with that in mind, a much better approach would be to create a separate class for each sms delivery system. this way, when one fails, we can easily switch to another — and our code remains clean, modular, and easy to maintain.

namespace App\Clients\Sms;
use App\Models\User;

class TwilioClient
{
    public function send(User $user): void
    {
        // send sms using twilio sdk
    }
}

example of the twilio provider for sending messages

namespace App\Clients\Sms;
use App\Models\User;

class VonageClient
{
    public function send(User $user): void
    {
        // send sms using vonage sdk
    }
}

example of the vonage provider for sending messages

you can notice that they both share the same responsibility, even having the same function names — the only difference is the implementation of each provider. in this way, they can be summarized into a single thing, right?

if you thought that, congratulations — you’ve just grasped the concept of dependency inversion. this single “thing” that we use to unify our providers is an interface, which determines which provider should be used during the project’s execution.

in our case, we’ll use laravel as an example, but you can apply these concepts in any framework and any programming language.

namespace App\Clients\Sms\Contracts;

use App\Models\User;

interface SmsClientContract
{
    public function send(User $user): void
}

this interface should be implemented by all sms sending providers — in our case, it should be implemented in the Twilioclient and Vonageclient classes.

now, we need to inform laravel that our interface refers to a specific provider. this way, whenever we need to use any of these providers, we just bind it to the interface through a service provider. then, every time this interface is referenced in the code, laravel will know to instantiate the specified class. example below:

namespace App\Providers;

use App\Clients\Sms\Contracts\SmsClientContract;
use Illuminate\Support\ServiceProvider;
use App\Clients\Sms\{
    TwilioClient,
    VonageClient
};

class SmsServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        $this->app->bind(SmsClientContract::class, TwilioClient::class);
    }
}

now, you just need to call the reference (the interface) somewhere in your code, either by dependency injection or by creating an instance from the application. laravel will always return a new instance of the class you registered in the service provider’s register method.

namespace App\Http\Controllers;

use Illuminate\Routing\Controller as BaseController;
use App\Clients\Sms\Contracts\SmsClientContract;

class UserController extends BaseController
{
    public function __construct(
        private SmsClientContract $smsClient
    ) { }

    public function sendSms(int $userId)
    {
        $user = User::findOrFail($id);
        $this->smsClient->send($user);

        return response()->noContent();
    }
}

in the example above, the controller retrieves the user and sends the sms through the twilio provider, since that’s the one registered in the service provider. notice how this makes the code more modular? whenever twilio is down, you can simply push a hotfix by changing the registration in the service provider to point to the vonage client — restoring the system without needing a new implementation.

dependency inversion is so modular that, in this case, you could even implement a validation flow before registering twilio, checking if it’s working properly before binding it. plus, you can safely use the sms client anywhere in your code with its public methods through the interface.

Conclusion, is this really necessary?

throughout my years of experience in web development, i've noticed that, over time, people tend to aim for more modularized projects, since that makes maintenance much easier. however, it's important to highlight that not everything actually needs to be modularized.

for example, one of the most common cases in laravel applications is creating separate containers for raw sql query builders and another for eloquent. but why is that a problem? actually, it's not as bad as it seems — it just doesn't make much sense.

laravel is a php framework designed with large, well-structured projects in mind. the framework itself offers solid tools for database interaction, which are unlikely to cause issues as long as your project is running on a secure and up-to-date version.

that means creating different providers to handle something that the framework already guarantees may just end up being unnecessary extra work.

HOW TO DEAL WITH EXCEPTIONS IN LARAVEL

Pedro Pessoa — Sun, 09 Jun 2024 17:06:03 +0000

Laravel is a free and open-source PHP web framework, created by Taylor Otwell and intended for the development of web applications, Laravel is based on Symfony (wiki).

The Framework provides a lot of features to help developers improve the error handling avoinding your application returns an unexpected errors, in this post you can learn more about how to deal with exceptions in laravel.

Exceptions

You may be asking "how can i deal with errors better than a simple try catch block code?"

public function index()
{
    try {
        //do anything...
    } catch(ExampleException $exception) {
        return response()->json([
            'error' => 'An error occurred.'
        ], 500);
    }
}

The above code is the most commun way that people deal with exceptions and it is not wrong, but it can be better, you can notice that the code is not the most secure way, if the ExampleException dispatches in elsewhere in the code you may add the try catch block in every place that the exception can be thrown, and sometimes you just don't know where it can be dispatched, but, what if there was a way to catch the exception regardless of where it is thrown?

Laravel Error Handling

There is a way to deal with any and all exceptions that your code raises and add logs, also send error reports to the cloud/email, thus having greater freedom to deal with errors in your system, allowing you to be aware of any error your project triggers in any code flow. Starting with version 11 of Laravel, it is possible to access the bootstrap/app.php file and view some rules that Laravel must follow during the initialization period of your application, in our case we will focus on the withExceptions method, which allows us execute some code when an exception is thrown.

->withExceptions(function (Exceptions $exceptions) {
    //
})

As you can see, the withExceptions method receives as a parameter a class called Exceptions, this class provides a series of methods that help you deal with exceptions thrown in your application. In this article, we will only look at the methods that you will probably use in your day-to-day life, but you can see all the methods in the documentation

Before we see the usefulness of some methods, we need to understand the process (in a simplified way) of how exception throwing works within Laravel:

In the example above we can see that, before an exception is returned to the request response, Laravel saves a LOG of the exception regardless of whether you have a registered handler or not, and this behavior can be changed according to the needs of your application. This allows you to prevent Laravel from saving logs automatically and you can choose exactly which log you want to save and in which log channel to save it, making your application more standardized and modularized according to your needs. When an exception is triggered, the log is saved in the file storage/logs/laravel.log

Creating Handler

To create your own handler, you can use the report method of the Exceptions class mentioned above. In this method, you pass a callable (an anonymous function or any other function that can be called) passing the exception you want to handle as a parameter. Example:

//inside withExceptions method

$exceptions->report(function (ExampleException $exception) {
    //handle ExampleException
});

In the example above, the callable parameter that we pass to the report method, we receive as a parameter the exception that we want to handle, within this callable we can do whatever we want with the exception, such as returning a standard response, in this way, every time the exception is triggered anywhere in the code (if it is not inside a try catch block), Laravel will execute the callable that we reported for the exception.

$exceptions->report(function (ExampleException $exception) {

    // default response for all ExampleException triggers
    return response()->json([
        'error' => true,
        'message' => 'An error occurred.',
    ], 500);
});

If you want to catch any exception regardless of the class, you can use the Throwable interface introduced in PHP 7:

$exceptions->report(function (Throwable $exception) {

    // default response for any exception
    return response()->json([
        'error' => true,
        'message' => 'Internal Server Error.',
    ], 500);
});

Saving Logs

If you want to stop laravel from automatically saving logs after throwing an exception and save your own logs you can stop the handling flow and go to the response through the stop() method.

$exceptions->report(function (Throwable $exception) {
    // Saving Logs
    Log::error("error: {$exception->getMessage()}", [
        'exception' => $exception->getTraceAsString()
    ]);

    // default response for any exception
    return response()->json([
        'error' => true,
        'message' => 'Internal Server Error.',
    ], 500);
})->stop();

It is also possible to stop the handling flow by returning false in the report callable.

$exceptions->report(function (Throwable $exception) {
    // Saving Logs
    Log::error("error: {$exception->getMessage()}", [
        'exception' => $exception->getTraceAsString()
    ]);

    return false;
});

In this way, laravel does not execute the "CREATE LARAVEL LOGS" process mentioned previously in the error handling flow image

There are some other methods in the Exceptions class that can be used in your day to day life. Below you can see a table with the names of the methods and a description of their usefulness in use.

Class: Exceptions

Method	Utility
dontReport	receives an array with all the classes that you don't want to report to log channels
stopIgnoring	receives an array with all the classes that you want to stop ignoring by default, like http exceptions
render	receives a callable that uses two parameters, the first being the exception you want to handle and the second parameter being the request received, through this method it is possible to render a frontend page

Tip: It is possible to change the default laravel error pages by publishing them from the vendor

php artisan vendor:publish --tag=laravel-errors

Remember that this article is just a simplified demonstration and with a slightly more informal language so that it can reach as many people as possible, you can view in-depth details of each implementation through the Official Laravel Documentation

HOW TO IMPROVE LARAVEL REQUESTS

Pedro Pessoa — Wed, 16 Aug 2023 14:18:44 +0000

Laravel is a free and open-source PHP web framework, created by Taylor Otwell and intended for the development of web applications following the model–view–controller (MVC) architectural pattern and based on Symfony (wiki).

The Framework provides a lot of features to help developers improve APIs. To ensure that your API is developed in a secure way, Laravel offers classes that help in the security of the data being transited within the server. In this article you will learn how to create and validate data with this tool.

Requests

When a payload data is sent to the backend server it goes throug several processes, the most common validation proccess is created using a Laravel Request Object, as default, for every route that uses a method in controller Laravel sends as parameter a Request Object as a dependecy injection (learn more). For example:

namespace App\Http\Controllers;

use App\Models\User;
use Illuminate\Http\Request;

class UserController extends Controller
{
    public function index(Request $request)
    {
        //
    }
}

The Request Object located at Illuminate\Http\Request is sent as a parameter to route method

Request Object

The Request Object provided by Illuminate has some methods that improves your code security and makes it cleaner. For Example:

public function index(Request $request)
{
    $name = $request->input('name'); // secure way

    $name = $request->name; // insecure way
}

When you get a value from request without using input(), get() or post() methods make instabilities in code, cause you're trying to access a property that non exists in a class by default.
Those methods receives a second paramenter as default value if request parameter don't exists or it's null.

public function index(Request $request)
{
    // returns John Doe if name parameter don't exists in request
    return $request->input('name', 'John Doe'); 
}

Validating Requests

To make sure that the parameter is being sent correctly by the request, the Request object offers a method called validate() in which it receives an array, the keys of this array must be the name of the input to be validated and the value of the array being the rule for validation. For example:

public function index(Request $request)
{
    $request->validate([
        'name' => 'string' 
    ]);
}

In this case, the array informs that the "name" parameter sent through the Request must be a string, if this validation fails, the server returns a response with error code 422 (Unprocessable Entity), if the route is accessed through some browser, the request will be redirected to its origin, being possible to capture the error through a blade template.

<!-- resources/views/form.blade.php -->

@error('name')
   <div class="alert alert-danger">
       {{ $message }}
   </div>
@endif

You can edit the request validation return message in validation.php located at resources/lang/en

Creating Custom Requests

In Laravel, it is possible to create your own Request objects, with customized validation methods and rules, in addition to creating your own attributes, thus increasing code stability. Custom requests also make your Controller code cleaner. To create a new Request object in your project, run the artisan command:

php artisan make:request StoreUserRequest

Conventionally it is recommended to use the "Request" suffix for every request file you create. In order for you to maintain a clean and standardized code, it is recommended that you create a Request object for each and every request of a CRUD from your system, in a CRUD of users for example:

StoreUserRequest
GetUserRequest
UpdateUserRequest
DeleteUserRequest

When you open the request file generated through the artisan command, you will see a file of the class you created with two standard methods, namely the authorize() method that returns a boolean and the rules() method that returns a array.

Authorize Method

/**
* Determine if the user is authorized to make this request.
*
* @return bool
*/
public function authorize(): bool
{
    return false;
}

The authorize method is responsible for returning a boolean, when this boolean is false, Laravel will automatically return an error to the client side with code 401 (Unauthorized), this means that your authorize method will be the method that determines whether the request being made is allowed to proceed or whether it should be denied. Normally, the authorize method returns a validation to proceed with the request only if the user is logged into the system.

public function authorize(): bool
{
    return auth()->check();
}

In this case, the request will be accepted only if the user is authenticated in the system.

Rules Method

public function rules(): array
{
    return [
        //
    ];
}

The rules method created after generating a Request file is responsible for returning an array of rules for the request to proceed successfully, the logic of the array implies that the keys must receive the names of the fields you want to validate and the values must receive the type of validation that must be done.

public function rules(): array
{
    return [
        'email' => 'email|max:255',
        'name'  => 'string|max:255'
    ];
}

In this case, the rule says that, as a requirement, the email field to be received in the request must be of type “email” and have a maximum of 255 characters. The "name" field must respect the "string" format and contain only 255 characters. These values can also be organized by an array. For example:

public function rules(): array
{
    return [
        'email' => ['email', 'max:255'],
        'name'  => ['string', 'max:255']
    ];
}

There are several validations that can be done even with databases. (Learn more)

Creating Custom Rule

With Laravel it is also possible to create a custom rule for your request, for you to generate a rule class you must run the command:

php artisan make:rule UppercaseRule

When running the above command, Laravel will create a class called UppercaseRule in the app/rules folder, in this class you can find a method called validate

public function validate(string $attribute, mixed $value, Closure $fail): void
{
     //
}

The method receives 3 parameters:

$attribute: The name of field that will be validated
$value: The value of field that will be validated
$fail: A function that will execute indicating that field is not valid

public function validate(string $attribute, mixed $value, Closure $fail): void
{
    if (strtoupper($value) !== $value) {
        $fail('The :attribute must be uppercase.');
    }
}

In this case, the method will validate if a value is different from itself in upper case and then execute the fail closure passing a message as default. You can notice that the method has the void return type, that is, the method must not return any value, so if the $fail function is not executed, Laravel will interpret the response as positive, thus following the request process.

The example thus shows the functionality in version 10.x of Laravel, if you want to perform these steps in a different version, I suggest you check correctly how it should be done in the official documentation. (here)

Finally, to choose which field a certain rule should be applied to, you must go back to the method
rules() found in your Request class and instantiate or reference the rule class

public function rules(): array
{
    return [
        'email' => ['email', 'max:255', UppercaseRule::class] // or (new UppercaseRule),
        'name'  => ['string', 'max:255']
    ];
}

Conclusion

After learning a little more about How To Use Improve Requests In Laravel, we can see how useful are the tools that Laravel provides for validate any API data. Always remember to stay on top of the official Laravel documentation, which is always kept up to date (Laravel Documentation)

HOW TO USE RESTFUL RESOURCE CONTROLLERS IN LARAVEL

Pedro Pessoa — Fri, 16 Dec 2022 23:27:27 +0000

The Framework provides a lot of features to help developers improve APIs and CRUD (Create, Read, Update, Delete) Applications, in both cases the most used and recomended feature is named RESTful Resource Controllers, before we use this Feature, it is important to understand what API Resources are about, what these features are and what they are made for.

API Resources

Api Resources are HTTP protocol methods accessed by a client machine which requests a service provided by the server, for example, the GET method, is responsible for requesting a particular record or a set of data stored on the server. A resource-oriented API is generally modeled as a resource hierarchy, where each node is either a simple resource or a collection resource. For convenience, they are often called a resource and a collection, respectively. A collection contains a list of resources of the same type (See more).

Below we can see a table referring to the main HTTP protocols and their responsibilities within the server

HTTP METHOD	RESPONSABILITY
GET	Get a particular record or a set of data.
POST	Create a given record requested by a client machine.
PUT	Update a record on the server.
DELETE	Delete a record on the server.

Restful Resources Controllers

Developers usually create their Controllers and Models through the Artisan command directives, provided in the installation of the Laravel project, but what many developers do not know is that it is possible to create a Controller with ready-made methods that are directly related to the previously mentioned HTTP methods, for this we must use the --resource option after the controller creation command, for example:

php artisan make:controller ApiController --resource

When running this command in your console, Artisan will create a new Controller in the app/Http/Controllers folder with some predefined methods, all these methods are related to API resources, all methods generated by the command have comments in the PHP DOCS standard (See More), with a brief description of each one's functionality.

For example, the method responsible for returning a listing (whether it has pagination or not) is called index(), in the examples below, we will use the case of a Model User.

Listing itens

By default, when a method inside a Controller returns a resource from an application's Model, Laravel returns a Response in JSON format, so we don't need to specify the method's return type, despite being a good practice.

/**
* Display a listing of the resource.
*
* @return \Illuminate\Http\Response
*/
public function index()
{
    return User::all(); // Can be overridden by a pagination method
}

Creating new Itens

To create new records in the database, Laravel creates two new methods, a method called create and another method called store, note that, by default the store method receives a request as a dependency injection parameter, this happens because, unlike the create method, the store method is only responsible for creating a new record in the database, unlike the create method, which, by default, should return a view with a form in which the system user must fill it out in order to be inserted into the database through the store method. In this case, we will only use the store method, but know that it is possible to use the create method in any type of Laravel application, preferably one that returns views and styles.

/**
* Store a newly created resource in storage.
*
* @param  \Illuminate\Http\Request  $request
* @return \Illuminate\Http\Response
*/
public function store(UserRequest $request)
{
    /**
    * Can be overwritten by a validation coming from
    * a different request object
    */
    return User::create($request->validated()); 
}

Updating Itens

Following the pattern of the creation methods, the update methods are also divided in two, in this case, the edit method will be responsible for returning a view with a form responsible for sending the data that will be updated in a certain item in the system, while the update method will be responsible for updating a certain item in the application directly in the database.

/**
 * Update the specified resource in storage.
 *
 * @param  \Illuminate\Http\Request  $request
 * @param  int  $id
 * @return \Illuminate\Http\Response
 */
public function update(Request $request, $id)
{
    /**
    * Can be overwritten by a validation coming from 
    * a different request object
    */
    return User::update($request->validated()); 
}

In some more recent versions of Laravel, you can replace the int $id parameter with a parameter that makes more semantic sense within the application, for example User $user, this way, Laravel automatically searches the database for the user by the ID received from the request and put it inside the $user variable, making your code cleaner and more semantic.

Deleting Itens

Different from the creation and update methods, the method of removing items from the database is unique, the method called destroy is responsible for destroying an item from your API. The method takes an id parameter, which is used to find the user in the database and then delete it.

/**
 * Remove the specified resource from storage.
 *
 * @param  int  $id
 * @return \Illuminate\Http\Response
 */
public function destroy($id)
{
    User::findOrFail($id)->delete();
}

Note that it is also possible to change the id parameter by the object to be searched, as in the editing method, in this way, the method would receive the User $user parameter and then remove it directly with the delete method , using $user->delete(), leaving the code cleaner.

Get specific Item

Through the index() method we can see all items within a table in the database, but Laravel also creates the show() method, which is responsible for returning a specific item from the database. The show() method receives, by default, an int $id parameter, which would be the id of the item that the request should return, as shown below.

/**
 * Display the specified resource.
 *
 * @param  int  $id
 * @return \Illuminate\Http\Response
 */
public function show($id)
{
    /**
    * It can be rewritten by directly 
    * passing Model as a method parameter, as shown above.
    */
    return User::findOrFail($id);
}

Routing

After creating the Controller and its methods, now we must write the routes that correspond to each method, however, in addition to the length of the code, this could make the code less clean than usual. To solve these problems, Laravel provides a creation method of routes called resource, which configures each parameter and method automatically. You can check more features, like adding middleware in the route, or adding exceptions for certain methods through the official documentation (See more).

Route::resource('users', ApiController::class);

Conclusion

After learning a little more about How To Use RESTFUL Resource Controllers In Laravel, we can see how useful are the tools that Laravel provides for creating and manipulating API data. Always remember to stay on top of the official Laravel documentation, which is always kept up to date (Laravel Documentation)