Ramiz’s blog about development

Configuring and Utilizing Multiple Databases in Laravel

2024-04-29T00:00:00+04:00

In Laravel, managing multiple databases is a common requirement for complex applications where data is distributed across different databases. Whether you need to interact with multiple databases for sharding, legacy systems, or simply for better organization, Laravel provides a convenient way to handle multiple database connections out of the box. n this guide, we’ll explore how to configure and utilize multiple database connections in Laravel, along with practical examples to demonstrate various scenarios.

Before diving into the usage, let’s set up multiple database connections in Laravel. Laravel’s database configuration is stored in the config/database.php file. Inside this file, you’ll find an array of database connections. To add a new connection, simply define a new array with the connection details.

'connections' => [
    'mysql' => [
        'driver' => 'mysql',
        'host' => env('DB_HOST', '127.0.0.1'),
        'port' => env('DB_PORT', '3306'),
        'database' => env('DB_DATABASE', 'forge'),
        'username' => env('DB_USERNAME', 'forge'),
        'password' => env('DB_PASSWORD', ''),
        'charset' => 'utf8mb4',
        'collation' => 'utf8mb4_unicode_ci',
        'prefix' => '',
        'strict' => true,
        'engine' => null,
    ],

    'second_db' => [
        'driver' => 'mysql',
        'host' => env('SECOND_DB_HOST', '127.0.0.1'),
        'port' => env('SECOND_DB_PORT', '3306'),
        'database' => env('SECOND_DB_DATABASE', 'forge'),
        'username' => env('SECOND_DB_USERNAME', 'forge'),
        'password' => env('SECOND_DB_PASSWORD', ''),
        'charset' => 'utf8mb4',
        'collation' => 'utf8mb4_unicode_ci',
        'prefix' => '',
        'strict' => true,
        'engine' => null,
    ],
],

We’ve added a new database connection named second_db here. Ensure you’ve updated the environment variables in your .env file accordingly.

Once you’ve set up the database connections, you can utilize them throughout your application. Laravel’s Eloquent ORM provides a convenient way to interact with databases.

1. Model Setup

When defining Eloquent models that use a different database connection, specify the $connection property.

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class SecondModel extends Model
{
    protected $connection = 'second_db';
}

2. Querying Data

When querying data from a specific database connection, you can use the on method on the Eloquent query builder.

$users = App\Models\SecondModel::on('second_db')->get();

3. Raw SQL Queries

You can execute raw SQL queries on a specific connection using the DB::connection() method.

$users = DB::connection('second_db')->select('select * from table_name');

Conclusion

Managing multiple databases in Laravel provides flexibility and scalability to your applications. By following the steps outlined in this guide, you can seamlessly configure and utilize multiple database connections in your Laravel projects. Whether it’s for distributed data storage, legacy integrations, or other requirements, Laravel’s robust database management capabilities make handling multiple databases a breeze.

Building Efficient Applications with MySQL Stored Procedures

2023-09-22T00:00:00+04:00

MySQL stored procedure is a powerful database function that allows you to store and execute a set of SQL statements in the database, similar to functions in programming. The storage process can greatly improve the performance, security and maintainability of the database. This article will introduce the use of MySQL stored procedures in detail.

What is a MySQL stored procedure?

MySQL stored procedures are a set of precompiled SQL statements that are stored in the database with a name and can be called and executed at any time. Stored procedures can accept input arguments, perform a series of operations, and return results. These characteristics make stored procedures an ideal tool for handling complex queries, data manipulation, and transaction management.

Create a stored procedure

To create a MySQL stored procedure, you use CREATE PROCEDURE statements. Here is a simple example:

DELIMITER //
CREATE PROCEDURE GetUser(IN user_id INT)
BEGIN
    SELECT * FROM users WHERE id = user_id;
END //
DELIMITER ;

DELIMITER Used to define the separator. Because the stored procedure contains multiple SQL statements, a separator different from the semicolon is required.
CREATE PROCEDURE Create a stored procedure that accepts an user_id input argument named and contains a set of SQL statements between BEGIN and END

Call stored procedure

Once the stored procedure is created, you can CALL execute it using the statement:

CALL GetUser(1);

This will call the stored procedure named and pass it GetUser the arguments 1

Arguments to stored procedure

Stored procedures can accept arguments, which can be input arguments, output arguments, or input/output arguments. In the above example, user_id it is an input argument because it is used to pass values to the stored procedure. You can define different types of arguments using the following syntax:

IN: Indicates that the argument is an input argument and can be used to pass values to the stored procedure.
OUT: Indicates that the argument is an output argument and can be used to return a value from a stored procedure.
INOUT: Indicates that the argument is an input/output argument and can be used to pass values and return values from stored procedures.

Stored procedure logic

The body of the stored procedure is contained BEGIN between END and and can contain various SQL statements, such as SELECT, INSERT, UPDATE, DELETE, IF statement, LOOP statement, etc. This allows you to perform complex logic in stored procedures, such as transaction processing, conditional judgments, and loop operations.

Advantages of the storage process

Using stored procedures has the following advantages:

Performance Optimization: Stored procedures are generally faster than individual SQL statements because they are compiled and cached on the database server, reducing communication overhead.
Security: Stored procedures can be used to encapsulate sensitive operations, thereby improving the security of the database. The user only needs to call the stored procedure without directly accessing the table.
Maintainability: Stored procedures allow commonly used business logic to be encapsulated in one place, reducing program code redundancy and making it easier to maintain.
Transaction management: Stored procedures can be used to manage complex transaction logic to ensure data consistency and integrity.
Reduce network latency: The storage process is executed on the database server, which can reduce network communication with the user.

Disadvantages of storage process

While the storage process has many advantages, there are also some disadvantages:

Complexity: Writing and maintaining complex stored procedures can become difficult, especially for developers who are unfamiliar with stored procedures.
Portability: The syntax and functionality of stored procedures vary between database systems and may not be portable enough.
Difficult to debug: Debugging stored procedures can be more challenging than debugging application code because they execute in a database.

Modify and delete stored procedures

To modify a stored procedure, you use ALTER PROCEDURE statements. To delete a stored procedure, you can use DROP PROCEDURE the statement.

These commands allow you to update the logic of a stored procedure or delete a stored procedure that is no longer needed.

Conclusion

MySQL stored procedures are a powerful tool that can improve the performance and security of the database, but they also need to be used with caution to ensure good code quality and maintainability. Stored procedures are often used to encapsulate complex business logic, optimize queries, and provide better database management and security. Whether you are processing large-scale data or performing complex transactions, stored procedures are a powerful tool for MySQL database management.

Simplifying data structures with ENUM in Laravel

2023-06-28T00:00:00+04:00

In modern web development, handling data structures efficiently is a crucial aspect of creating robust applications. ENUM (Enumerated Type) is a powerful feature in PHP that enables developers to define a set of named constants, making code more readable, maintainable, and less prone to errors. In this blog post, we will explore ENUM in PHP and discuss how it can be integrated into Laravel, one of the most popular PHP frameworks.

Laravel, with its elegant syntax and powerful features, provides built-in support for ENUM. Here’s a step-by-step guide on how to utilize ENUM in Laravel:

Create the ENUM Class:

Inside the app/Enums directory, create a new PHP file, e.g., StatusEnum.php. This file will contain the ENUM constants and their associated values:

<?php

namespace App\Enums;

enum StatusEnum: string {
    case Pending = 'pending';
    case Active = 'active';
    case Inactive = 'inactive';
}

Here, we’ve defined three constants: ACTIVE, INACTIVE, and PENDING, representing different statuses.

To make it even more convenient to work with ENUMs, we will use the kongulov/interact-with-enum package with the InteractWithEnum trait, which contains useful methods for working with ENUMs

Install the package via Composer:

# Install interact-with-enum
composer require kongulov/interact-with-enum

And use it in all our ENUMs to make it look like this

<?php

namespace App\Enums;

use Kongulov\Traits\InteractWithEnum;

enum StatusEnum: string {
    use InteractWithEnum;

    case Pending = 'pending';
    case Active = 'active';
    case Inactive = 'inactive';
}

Using ENUM in Code:

Once you’ve created the ENUM class, you can leverage it in your code. Here are a few examples:

Model Definition

In your Eloquent models, you can specify the ENUM field and its associated ENUM class using the $casts attribute:

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use App\Enums\StatusEnum;

class User extends Model
{
    // ...
    protected $fillable = [
        'name',
        'email',
        'status',
    ];

    protected $casts = [
        'status' => StatusEnum::class,
    ];
    // ...
}

By setting the status field’s cast type to StatusEnum, Laravel will automatically handle the conversion between the ENUM value and its corresponding constant.

Database Migrations

In your database migration files, you can define ENUM columns using the ->enum() method:

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
use App\Enums\StatusEnum;

class CreateUsersTable extends Migration
{
    public function up()
    {
        Schema::create('users', function (Blueprint $table) {
            // ...
            $table->enum('status', StatusEnum::values())->default(StatusEnum::Pending->value);
            // ...
        });
    }

    // ...
}

Here, we’ve created a status column in the users table, using the ENUM constants defined in StatusEnum.

Using ENUM in Validation:

Laravel’s validation rules allow you to validate ENUM values easily. Here’s an example:

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Validation\Rules\Enum;
use App\Enums\StatusEnum;

class UpdateUserRequest extends FormRequest
{
    public function rules()
    {
        return [
            'status' => ['required', new Enum(StatusEnum::class)],
        ];
    }
}

In this example, we’ve defined a validation rule for the status field, ensuring that it is required and can only contain one of the ENUM constants defined in StatusEnum.

Conclusion

ENUMs in Laravel provide an elegant solution for handling fixed sets of values, improving code readability and maintaining data integrity. By creating an ENUM class, you can define constants representing different values and easily use them throughout your application. Whether it’s in database migrations, models, or validation, ENUMs offer a robust way to manage and validate your data effectively. Implement ENUMs in your Laravel projects and experience the benefits of streamlined code and enhanced data structure management.

Install and Configure Supervisor for Laravel Queue

2023-04-07T00:00:00+04:00

Supervisor is a process control system for Linux that allows you to monitor and control processes on your server. It is particularly useful for managing long-running processes, such as Laravel queues, which can run for hours or even days at a time. In this post, we will go through the process of installing and using Supervisor with Laravel queue

1. Install Supervisor

The first step is to install Supervisor on your server. This can typically be done using your server’s package manager. For example, on Ubuntu, you can install Supervisor using the following command:

sudo apt-get install supervisor

Once Supervisor is installed, you can start and stop it using the following commands:

sudo systemctl start supervisor
sudo systemctl stop supervisor

2. Configure Supervisor

The next step is to configure Supervisor to manage your Laravel queue processes. Supervisor uses configuration files to define the processes it should manage. These files are typically stored in the /etc/supervisor/conf.d/ directory.

Create a new configuration file for your Laravel queue using the following command:

sudo nano /etc/supervisor/conf.d/laravel-queue.conf

In this file, you will need to define the command that Supervisor should use to start your Laravel queue. Here is an example configuration file:

[program:laravel-queue]
process_name=%(program_name)s_%(process_num)02d
command=php /path/to/artisan queue:work --queue=default --sleep=3 --tries=3 --max-time=3600
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
user=www-data
numprocs=8
redirect_stderr=true
stdout_logfile=/var/log/laravel-queue.log

In this configuration file, we have defined a process called laravel-queue, which will run the queue:work command. We have specified that the process should start automatically and restart if it crashes, and we have set the number of processes to run to 8. We have also redirected the stderr output to a log file.

Save and close the configuration file when you are done.

3. Reload Supervisor

Once you have created your configuration file, you will need to tell Supervisor to reload its configuration:

sudo supervisorctl reread
sudo supervisorctl update

This will read your new configuration file and add the laravel-queue process to the list of processes that Supervisor should manage.

4. Start the Laravel Queue

With Supervisor configured, you can now start the Laravel queue using the following command:

sudo supervisorctl start laravel-queue:*

This will start all of the processes defined in your configuration file.

5. Monitor the Laravel Queue

This will display the status of all processes managed by Supervisor, including your Laravel queue processes.

Conclusion

In this post, we have gone through the process of installing and using Supervisor with Laravel queue. By using Supervisor to manage your Laravel queue processes, you can ensure that they run reliably and continuously, even if they encounter errors or crashes. This can help to ensure that your application runs smoothly and efficiently, even under heavy load.

You can read about how to create a queue in Laravel in the following article: Queues in Laravel

Understanding the Adapter Design Pattern in PHP

2023-02-21T00:00:00+04:00

The Adapter pattern is a structural design pattern that allows two incompatible interfaces to work together. This pattern is used to create a bridge between two incompatible interfaces by creating an intermediate adapter that can translate the interface of one object to another. The Adapter pattern is useful when you need to use an existing class, but its interface doesn’t match the one you need.

Let’s take a real-life example to understand the Adapter pattern better. Suppose you have a smartphone that uses a USB Type-C charging cable, and you want to charge it using an old charger that only has a Micro-USB port. To connect your smartphone to the old charger, you need a Type-C to Micro-USB adapter. This adapter acts as a bridge between the incompatible interfaces of your smartphone and the old charger, allowing them to work together.

In software development, the Adapter pattern is commonly used in legacy codebases where you need to use existing code or libraries that have an incompatible interface with your application. By creating an adapter, you can use the existing code without having to modify it.

Let’s take an example of a payment system to understand how the Adapter pattern works in PHP.

Suppose you are building an e-commerce website that needs to accept payments from multiple payment gateways, such as PayPal and Stripe. Each payment gateway has its own API and interface for processing payments. To make it easier to integrate these payment gateways into your website, you can create an adapter for each payment gateway that translates its API into a common interface that your website can use.

Let’s imagine that we have 2 classes of payment gateways PayPalGateway and StripeGateway, have their own payment processing interface, but they need to be adapted to our interface

class PayPalGateway
{
    public function sendPayment(float $amount): bool
    {
        // Send payment using PayPal API
        return true;
    }
}

class StripeGateway
{
    public function charge(float $amount): bool
    {
        // Charge payment using Stripe API
        return true;
    }
}

First, let’s create the PaymentAdapterInterface interface, which will define the general interface for processing payments.

interface PaymentAdapterInterface
{
    public function processPayment(float $amount): bool;
}

To make these payment gateways compatible with our payment system,we have created two adapter classes PayPalAdapter and StripeAdapter that implement the PaymentAdapterInterface and translate the API of the payment gateway to the common interface.

class PayPalAdapter implements PaymentAdapterInterface
{
    private $payPalGateway;

    public function __construct(PayPalGateway $payPalGateway)
    {
        $this->payPalGateway = $payPalGateway;
    }

    public function processPayment(float $amount): bool
    {
        return $this->payPalGateway->sendPayment($amount);
    }
}

class StripeAdapter implements PaymentAdapterInterface
{
    private $stripeGateway;

    public function __construct(StripeGateway $stripeGateway)
    {
        $this->stripeGateway = $stripeGateway;
    }

    public function processPayment(float $amount): bool
    {
        return $this->stripeGateway->charge($amount);
    }
}

Now we can use these adapters in our payment system to process payments from different payment gateways:

$payPalGateway = new PayPalGateway();
$payPalAdapter = new PayPalAdapter($payPalGateway);
$payPalAdapter->processPayment(100.00);

$stripeGateway = new StripeGateway();
$stripeAdapter = new StripeAdapter($stripeGateway);
$stripeAdapter->processPayment(100.00);

Using an Adapter pattern, we can easily integrate various payment gateways into your system.

Enhance Your PHP Code with Decorator Design Pattern

2023-02-08T00:00:00+04:00

The Decorator Design Pattern is a design pattern that is used to extend the behavior of an object dynamically, without changing its class. It is a structural pattern that can be used to add responsibilities to individual objects, instead of creating a new subclass.

The Decorator design pattern can be implemented by creating an interface or abstract class that defines the basic methods that must be implemented by all concrete decorators. The concrete decorators must inherit from the interface or abstract class and implement the necessary methods. To use a decorator, an object of the decorated class is passed to the constructor of the concrete decorator. The concrete decorator can then add or change the behavior of the decorated object.

The Decorator Design Pattern can be useful in several different contexts. For example, if you have a basic object, like a cup of coffee, and you want to add different types of flavors to it, such as whipped cream or chocolate syrup, the Decorator Design Pattern can be used.

Let’s consider an example to understand the Decorator Design Pattern.

First, we create the Coffee interface with two methods: getCost and getDescription. We also create a SimpleCoffee class that implements the Coffee interface. This class represents the basic functions of an object.

interface Coffee
{
    public function getCost(): int;
    public function getDescription(): string;
}

class SimpleCoffee implements Coffee
{
    public function getCost(): int
    {
        return 10;
    }

    public function getDescription(): string
    {
        return 'Simple Coffee';
    }
}

We then create an abstract CoffeeDecorator class that implements the Coffee interface and takes an instance of the Coffee interface as a parameter. This class is used as the base class for concrete decorator classes.

abstract class CoffeeDecorator implements Coffee
{
    protected $decoratedCoffee;

    public function __construct(Coffee $decoratedCoffee)
    {
        $this->decoratedCoffee = $decoratedCoffee;
    }
}

Finally, we create two concrete decorator classes, MilkCoffee and CreamCoffee, which extend from the CoffeeDecorator class.

class MilkCoffee extends CoffeeDecorator
{
    private const PRICE = 2;
    
    public function getCost(): int
    {
        return $this->decoratedCoffee->getCost() + self::PRICE;
    }

    public function getDescription(): string
    {
        return $this->decoratedCoffee->getDescription() . ', milk';
    }
}

class CreamCoffee extends CoffeeDecorator
{
    private const PRICE = 5;

    public function getCost(): int
    {
        return $this->decoratedCoffee->getCost() + self::PRICE;
    }

    public function getDescription(): string
    {
        return $this->decoratedCoffee->getDescription() . ', cream';
    }
}

Now let’s look at an example of calling classes

// Order simple coffee
$simpleCoffee = new SimpleCoffee();
echo $simpleCoffee->getCost(); // output: 10
echo $simpleCoffee->getDescription(); // output: Simple Coffee

// Order coffee with milk
$milkCoffee = new MilkCoffee($simpleCoffee);
echo $milkCoffee->getCost(); // output: 12 (SimpleCoffee cost + MilkCoffee cost)
echo $milkCoffee->getDescription(); // output: Simple Coffee, milk

// Order coffee with cream
$creamCoffee = new CreamCoffee($simpleCoffee);
echo $creamCoffee->getCost(); // output: 15 (SimpleCoffee cost + CreamCoffee cost)
echo $creamCoffee->getDescription(); // output: Simple Coffee, cream

What if we want to order coffee with milk and cream? Then we need to wrap one order in both decorators

// Order simple coffee
$simpleCoffee = new SimpleCoffee();
echo $simpleCoffee->getCost(); // output: 10
echo $simpleCoffee->getDescription(); // output: Simple Coffee

// Order coffee with milk
$milkCoffee = new MilkCoffee($simpleCoffee);
echo $milkCoffee->getCost(); // output: 12 (SimpleCoffee cost + MilkCoffee cost)
echo $milkCoffee->getDescription(); // output: Simple Coffee, milk

// Order coffee with milk and cream
// We create CreamCoffee from $milkCoffee because it contains both coffee and milk
$mixCoffee = new CreamCoffee($milkCoffee);
echo $mixCoffee->getCost(); // output: 17 (SimpleCoffee cost + MilkCoffee cost + CreamCoffee cost)
echo $mixCoffee->getDescription(); // output: Simple Coffee, milk, cream

Advantages of using the Decorator Design Pattern:

The Decorator design pattern allows you to extend the functionalities of existing objects in a flexible and easy-to-maintain way.
It allows you to add new behaviors and responsibilities to an object dynamically, without affecting the behavior of other objects from the same class.
The Decorator design pattern is a good alternative to inheritance when you want to add new functionalities to an object, but do not want to modify the source code of the original object.
It allows you to keep the implementation of the original object separate from the implementation of the new functionalities.

Mastering the Strategy Design Pattern in PHP

2023-01-25T00:00:00+04:00

The strategy design pattern is a behavioral design pattern that allows an object to change its behavior based on a given context. The pattern involves separating an object’s behavior into different strategies and allowing the object to switch between these strategies at runtime. This allows for greater flexibility and maintainability in the code, as the behavior of the object can be changed without modifying the object itself.

In PHP, the strategy design pattern can be implemented by creating an interface or abstract class that defines the behavior that all strategies must have. Concrete classes are then created that implement this interface or extend the abstract class, providing the specific implementation for each strategy.

To illustrate this pattern, let’s consider an example of a shopping cart that can calculate the total cost of the items in it. Different strategies can be used to calculate the total cost, such as using a discount code, calculating shipping costs, or applying taxes.

First, we can create an interface for the strategy, which defines the methods that all strategies must implement. In this example, the strategy interface is called CalculateTotalCostStrategy and it has only one method calculate():

interface CalculateTotalCostStrategy {
    public function calculate(array $items);
}

We can then create concrete classes that implement this strategy. For example, one concrete strategy can be called DiscountCodeStrategy, which applies a discount code to the total cost:

class DiscountCodeStrategy implements CalculateTotalCostStrategy {
    public function calculate(array $items) {
        $discount = 10;
        // logic to apply discount code
        return array_sum($items) - $discount;
    }
}

Another concrete strategy can be called ShippingCostStrategy, which calculates shipping costs for the items:

class ShippingCostStrategy implements CalculateTotalCostStrategy {
    public function calculate(array $items) {
        $shippingCost = 10;
        // logic to calculate shipping costs
        return array_sum($items) + $shippingCost;
    }
}

We can also create a context class, which is the class that will change its behavior based on the strategy selected. The context class will have a property strategy that will hold the current strategy.

class ShoppingCart {
    private $strategy;
    
    public function __construct(CalculateTotalCostStrategy $strategy) {
        $this->strategy = $strategy;
    }
    
    public function calculateTotalCost(array $items) {
        return $this->strategy->calculate($items);
    }
}

Once the context class, interface and the concrete strategies are defined, we can use them to create the objects and switch between strategies at runtime.

$items = array(10, 20, 30);

$shoppingCart = new ShoppingCart(new DiscountCodeStrategy());
echo $shoppingCart->calculateTotalCost($items);
// output: 50 (total cost of items - discount)

$shoppingCart = new ShoppingCart(new ShippingCostStrategy());
echo $shoppingCart->calculateTotalCost($items);
// output: 70 (total cost of items + shipping cost)

This is a simple example of how the strategy pattern can be implemented

Abstract Factory Pattern in PHP

2023-01-12T00:00:00+04:00

The Abstract Factory pattern is a design pattern that provides an interface for creating families of related or dependent objects without specifying their concrete classes. It allows for the creation of objects that follow a certain pattern, without the need to specify the exact class of the object to be created.

The Abstract Factory pattern can be implemented in PHP using interfaces and abstract classes. The interface or abstract class defines a set of methods that must be implemented by concrete factory classes, which are responsible for creating the actual objects.

First, consider an example with an interface:

interface CarFactory {
    public function createCar(): Car;
    public function createTruck(): Truck;
}
interface Car {/*...*/}
class Sedan implements Car {/*...*/}
class SUV implements Car {/*...*/}
interface Truck {/*...*/}
class PickupTruck implements Truck {/*...*/}
class BoxTruck implements Truck {/*...*/}

class FamilyCarFactory implements CarFactory {
    public function createCar(): Sedan {
        return new Sedan();
    }
    public function createTruck(): PickupTruck {
        return new PickupTruck();
    }
}

class LuxuryCarFactory implements CarFactory {
    public function createCar(): SUV {
        return new SUV();
    }
    public function createTruck(): BoxTruck {
        return new BoxTruck();
    }
}

$familyCarFactory = new FamilyCarFactory();
$sedan = $familyCarFactory->createCar();
$pickupTruck = $familyCarFactory->createTruck();

$luxuryCarFactory = new LuxuryCarFactory();
$suv = $luxuryCarFactory->createCar();
$boxTruck = $luxuryCarFactory->createTruck();

In this example, CarFactory is an interface with two methods createCar() and createTruck() that need to be implemented by concrete factories. These methods will create an object of a certain class that implements the Car and Truck interface respectively.

The main benefit of using the Abstract Factory pattern in this scenario is that it allows for a separation of concerns between the classes that create objects and the classes that use them. The CarFactory interface defines the contract for creating cars and trucks, while the concrete factory classes are responsible for creating the actual objects.

By using this pattern, we can easily swap out the concrete factory classes to create different types of cars and trucks, without having to modify the code that uses them. For example, we can have different implementations of the CarFactory such as FamilyCarFactory and LuxuryCarFactory, where FamilyCarFactory can create Sedan and PickupTruck and LuxuryCarFactory can create SUV and BoxTruck.

We could also use an abstract factory to create different car factories that creates different type of fuel-based cars such as electric cars factory, petrol cars factory and diesel cars factory. This way we can create a whole family of related objects based on a certain category with a single factory class.

Now consider an example using an abstract class:

abstract class CarFactory {
    abstract public function createCar(): Car;
    abstract public function createTruck(): Truck;
}

abstract class Car {
    abstract public function drive();
}

abstract class Truck {
    abstract public function load();
}

class ElectricCar extends Car {
    public function drive() {
        // code to drive electric car
    }
}
class PetrolCar extends Car {
    public function drive() {
        // code to drive petrol car
    }
}
class ElectricTruck extends Truck {
    public function load() {
        // code to load electric truck
    }
}
class PetrolTruck extends Truck {
    public function load() {
        // code to load petrol truck
    }
}

class ElectricCarFactory extends CarFactory {
    public function createCar(): ElectricCar {
        return new ElectricCar();
    }
    public function createTruck(): ElectricTruck {
        return new ElectricTruck();
    }
}
class PetrolCarFactory extends CarFactory {
    public function createCar(): PetrolCar {
        return new PetrolCar();
    }
    public function createTruck(): PetrolTruck {
        return new PetrolTruck();
    }
}

$electricCarFactory = new ElectricCarFactory();
$electricCar = $electricCarFactory->createCar();
$electricCar->drive();

$petrolCarFactory = new PetrolCarFactory();
$petrolCar = $petrolCarFactory->createCar();
$petrolCar->drive();

In this example, the CarFactory abstract class defines two methods, createCar() and createTruck(), that must be implemented by concrete factory classes. The ElectricCarFactory and PetrolCarFactory classes implement these methods and return new objects of the ElectricCar, PetrolCar, ElectricTruck and PetrolTruck classes.

You can see that the abstract class of CarFactory defines the contract and structure of the factory, while the concrete factory classes are responsible for creating the actual objects of the Car and Truck.

Using abstract classes also provides an opportunity for sharing common functionality between concrete factories. The abstract class can provide a default implementation for some of the methods, which can be overridden by the concrete classes if needed.

In summary, The Abstract Factory pattern is a powerful tool that allows for the creation of families of related objects in a flexible and maintainable way. By using interfaces and abstract classes to define the creation methods, the concrete classes can be easily swapped out. Using an abstract class allows for providing a default implementation and share common functionality between concrete factories.

Queues in Laravel

2022-11-14T00:00:00+04:00

Sometimes individual processes take a long time to complete, such as sending email, payment gateway, etc. When you send an email for verification, it takes time. If you don’t want to make the user wait, then you need to use queues. This will make your service fast for the user.

To work with queues in Laravel, it is enough to know and be able to execute a few commands:

Create a queue handler: php artisan make:job ProcessSendingEmail
Send a new event to the queue: ProcessSendingEmail::dispatch($user);
And run the handler for all events: php artisan queue:work

As simple as possible, right? Let’s now look in more detail.

Principle of operation

The principle of operation of queues consists of two main components:

queue servers;
handler;

The queue server keeps a list of messages (or tasks, job queue) that the main application sends to it. A task is simply information about what needs to be done and how.

A handler (or worker) is a part of the main program that works with the queue in the opposite direction. It receives new messages from the queue and performs the appropriate actions.

Example

Let’s imagine a simple registration form with one email field and a “Register” button. By clicking on the button, we send the data to the server and check if we have a user with such an email in the database or not, if so, we will send a message to the form that the user already exists, and if not, we will send him an email to the specified email to confirm it. To send an email, we have 2 options:

send synchronously within a single request;
add a task to send an email to the queue;

In fact, there is no right answer, you need to look at the specific situation. If you have a small project, you have several people registering per hour and it is non-critical if they wait 5-10 seconds for a request to be processed, then the first option with synchronous sending of a letter suits you. But in most cases it is better to use a queue. To do this, let’s go back to the beginning of the article and follow a couple of simple steps:

1. Create a queue handler

Execute the command

php artisan make:job ProcessSendingEmail

All default handlers are created in app/Jobs. Open the created app/Jobs/ProcessSendingEmail.php file and update the handle function:

public function handle(User $user)
{
    Mail::send(
        'mail.confirm-registration',
        [
            'html' => 'Confirm your email using the link - https://kongulov.dev'
        ],
        function ($message) use ($user) {
            $message->to($user->email)->subject('Confirmation of registration');
        }
    );
}

Now our handler receives the user model and sends him a letter using the standard Mail package in Laravel, you can familiarize yourself with its capabilities in the documentation.

2. Send a new event to the queue

public function register(Request $request)
{
    // .... code
    ProcessSendingEmail::dispatch($user);
    // .... code
}

After calling the dispatch function, a new event will immediately fly to our queue, and we just have to run our queue handler and wait for the letter to be sent to the user.

3. Run the handler for all events in the console with the command

php artisan queue:work

After the handler is launched, all our events will be processed one by one, and if we had 100 letters to send in the queue, then the last letter will obviously not be sent soon and will be approximately like in the first picture, when everyone is waiting in line.

Luckily, we can solve this problem very easily by running multiple handlers with Supervisor and our emails will be sent in parallel. Of course, we must be careful with the choice of the number of handlers, because each will occupy the resources of our server and the optimal number must be selected from our capabilities, but remember that the more handlers, the faster all our messages will be processed.

Events and Listeners in Laravel

2022-10-18T00:00:00+04:00

Laravel Events provides a simple implementation of the Observer pattern, allowing you to subscribe to and monitor various events that occur in your application. Event classes are usually stored in the app/Events directory and their listeners in app/Listeners.

The advantage of this pattern is to separate the different logic in your application. In this case, one event can have many independent listeners. For example, you want to be notified every time that you have a new registered user on the site. To do this, you do not need to make changes to the user registration class or extend it in any way. It is enough to create a class of an independent event listener “Registration” (subscribe to the event), inside which the notification logic will be implemented.

What is an Event?

Events are the ways we hook into our application’s activity, it’s just a way to observe the activity, such as login, you can create a class to monitor the login activity, when the user logs in, the event class can perform some functions.

What is a Listener?

A listener is a class that listens to the events they are associated with and performs a task, that is, they perform the given task for the event. Let me illustrate. You might want to send a welcome email to a new user of your application and assign a role to the user based on the information provided during registration, etc. You wouldn’t want to do all of this in the RegisterController because we are violating the first SOLID (Single Responsibility Principle). When the Controller will perform more than one task, the RegisterController should only perform the actions of registering a new user. Thus, the event must be held during the registration process, which includes assigning a role, sending an email, etc. They are individual listeners within the event.

Creating Event and Listener class

To create an event class, use the artisan command make:event

php artisan make:event Register

This command will create a new class in your application’s app\Events folder, and that’s all you need to create an event class.

To create a listener class, use the artisan command make:listener

php artisan make:listener SendWelcomeEmail

This command, just like creating an event, will create a new class in your application’s app\Listeners folder, which is all you need to create a listener class.

Registering Event and Listener class

In order for our events and listeners to work, we must register them in the App\Providers\EventServiceProvider class, which was already set up for us during the installation of our Laravel project.

looking into the App\Providers\EventServiceProvider class you will see the $listen array in which we will register our events and listeners.

namespace App\Providers;

class EventServiceProvider extends ServiceProvider
{
    protected $listen = [
        Register::class => [
            SendWelcomeEmail::class,
        ],
    ];
}

Let’s take a look at our Register event and pass our new user into it

<?php
 
namespace App\Events;
 
use App\Models\User;
use Illuminate\Broadcasting\InteractsWithSockets;
use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\Queue\SerializesModels;
 
class Register
{
    use Dispatchable, InteractsWithSockets, SerializesModels;
 
    /**
     * The order instance.
     *
     * @var \App\Models\User
     */
    public $user;
 
    /**
     * Create a new event instance.
     *
     * @param  \App\Models\User  $user
     * @return void
     */
    public function __construct(User $user)
    {
        $this->user = $user;
    }
}

And now let’s look at our listener SendWelcomeEmail where all the logic of sending email will be

<?php
 
namespace App\Listeners;
 
use App\Events\Register;
 
class SendWelcomeEmail
{
    /**
     * Create the event listener.
     *
     * @return void
     */
    public function __construct()
    {
        //
    }
 
    /**
     * Handle the event.
     *
     * @param  \App\Events\Register  $event
     * @return void
     */
    public function handle(Register $event)
    {
        // Access the user using $event->user...
        // email sending logic for $event->user->email
    }
}

Dispatching an event

At the time of this writing, I was aware of two methods for dispatching your event and triggering listeners:

event(new EventClass()); // event(new Register($user));
EventClass::dispatch(); // Register::dispatch($user);

You should note that public properties declared on the event class can be accessed on the listener class that is associated with it.

Database transactions in Laravel

2022-10-03T00:00:00+04:00

In web development, data integrity and accuracy are important. Therefore, we need to be sure that we are writing code that securely stores, updates, and deletes data in our databases. In this article, we’ll take a look at what database transactions are, why they’re important, and how to get started using them in Laravel. We will also look at typical problems associated with third-party services and database transactions.

What are database transactions

Before we get started with transactions in Laravel, let’s take a look at what they are and how they are useful.

A transaction is an archive for database queries. It protects your data thanks to the all-or-nothing principle.

Let’s say you transfer money from one account to another. In the application, it looks like several operations

UPDATE `wallets` SET `amount` = `amount` - 100 WHERE `id` = 1;
UPDATE `wallets` SET `amount` = `amount` + 100 WHERE `id` = 2;

What if one request succeeds and the other fails? Then the integrity of the data will be violated. To avoid such situations, the DBMS introduced the concept of a transaction - an atomic impact on data. That is, the transfer of the database from one holistic state to another. In other words, we include several requests in the transaction, which must all be executed, but if at least one is not executed, then all the requests included in the transaction will not be executed. This is the all-or-nothing principle.

Using database transactions in Laravel

Now that we have an idea about transactions, let’s look at how to use them in Laravel.

First, let’s see what we have in the wallets table

| id | amount |
|----|--------|
| 1  | 1000   |
| 2  | 0      |

I intentionally made a mistake in the transfer method to see the consequences of a data violation.

public function transfer()
{
    Wallet::where('id', 1)->decrement('amount', 100);
    Wallet::where('id_', 2)->increment('amount', 100);
}

After executing the code, check the database

| id | amount |
|----|--------|
| 1  | 900    |
| 2  | 0      |

The first request passed, but the second one failed. And in the end: the funds from the first account were gone, but they did not come to the second one. Data integrity has been violated. To prevent this from happening, you need to use transactions.

It’s very easy to get started with transactions in Laravel thanks to the transaction() method, which we can access from the DB facade. Based on the previous code example, let’s look at how to use transactions in Laravel.

use Illuminate\Support\Facades\DB;

public function transfer()
{
    DB::transaction(function(){
        Wallet::where('id', 1)->decrement('amount', 100);
        Wallet::where('id_', 2)->increment('amount', 100); // <-- left an error
    });
}

Let’s run the code. But now both requests are in a transaction. Therefore, no query should be executed.

| id | amount |
|----|--------|
| 1  | 1000   |
| 2  | 0      |

An error occurred while executing the second request. Because of this, the transaction as a whole failed. The amounts on the wallets have not changed.

Let’s fix the transfer method and run the code

use Illuminate\Support\Facades\DB;

public function transfer()
{
    DB::transaction(function(){
        Wallet::where('id', 1)->decrement('amount', 100);
        Wallet::where('id', 2)->increment('amount', 100);
    });
}

After executing the code, check the database

| id | amount |
|----|--------|
| 1  | 900    |
| 2  | 100    |

All requests were completed without errors, so the transaction was successful. The amounts on the wallets have changed.

This was a simple example using a closure. But what if you have third-party services whose response is important and should affect an event in the code? Because not all services return exceptions, some just return a boolean. To do this, Laravel has several methods for manually processing transactions.

DB::beginTransaction() – for defining a transaction
DB::commit() – to execute all queries after DB::beginTransaction()
DB::rollBack() – to cancel all requests after DB::beginTransaction()

Let’s consider them with an example. We have a wallet with a balance of $100, and we have a card with a balance of $50, we want to use both balances to transfer $150 to another wallet.

use App\Services\ThirdPartyService;
use Illuminate\Support\Facades\DB;

private ThirdPartyService $thirdPartyService;
    
public function __construct(ThirdPartyService $thirdPartyService)
{
    $this->thirdPartyService = $thirdPartyService;
}
    
public function transfer()
{
    DB::transaction(function(){
        Wallet::where('id', 1)->decrement('amount', 100);
        $this->thirdPartyService->withdrawal(50); // <-- returns false
        Wallet::where('id', 2)->increment('amount', 150);
    });
}

Data integrity has been violated. Since the service does not throw an exception so that the transaction is not completed, but only returns a false value and the code continues to work. As a result, we replenish the balance by 150 without deducting 50 from the card

Now we use the above methods to manually use transactions

use App\Services\ThirdPartyService;
use Illuminate\Support\Facades\DB;

private ThirdPartyService $thirdPartyService;
    
public function __construct(ThirdPartyService $thirdPartyService)
{
    $this->thirdPartyService = $thirdPartyService;
}
    
public function transfer()
{
    DB::beginTransaction();
    
    Wallet::where('id', 1)->decrement('amount', 100);
    
    if(!$this->thirdPartyService->withdrawal(50)) {
        DB::rollBack();
        
        return;
    }
    
    Wallet::where('id', 2)->increment('amount', 150);
    
    DB::commit();
}

Thus, if a third-party service returns false to us, then by calling DB::rollBack() we will prevent the execution of requests and preserve the integrity of the data

Repository Pattern in Laravel - PHP Design Pattern

2022-09-26T00:00:00+04:00

Repositories are classes or components that contain the logic needed to access data sources. Repositories provide centralized functionality for accessing data, allowing better management and separation of the infrastructure or technology used to access data from the domain model. If you’re using an object-relational mapping (ORM) like the Laravel Framework, the code you need to implement is simplified thanks to Eloquent and strong typing. This allows you to focus on the data persistence logic rather than the data access helper functions.

Let’s take an example in Laravel.

We usually implement the repository pattern with an interface. An interface can reduce dependencies between classes, and the implemented class will use the same functionality as the interface.

And so let’s create our PostRepositoryInterface in the app/Interfaces/ folder

namespace App\Interfaces;

interface PostRepositoryInterface
{
    public function list();
    public function findById(int $postId);
    public function create(array $details);
    public function update(int $postId, array $details);
    public function delete(int $postId);
}

And now let’s create the PostRepository in the app/Repositories folder which will implements the PostRepositoryInterface

namespace App\Repositories;

use App\Interfaces\PostRepositoryInterface;
use App\Models\Post;

class PostRepository implements PostRepositoryInterface
{
    public function list()
    {
        return Post::all();
    }

    public function findById(int $postId)
    {
        return Post::query()->findOrFail($postId);
    }

    public function create(array $details)
    {
        return Post::create($details);
    }

    public function update(int $postId, array $details)
    {
        return Post::query()->where('id', $postId)->update($details);
    }

    public function delete(int $postId)
    {
        return Post::query()->where('id', $postId)->delete();
    }
}

Next in our class, through dependency injection, we use our PostRepositoryInterface

namespace App\Http\Controllers\Api;

use App\Http\Controllers\Controller;
use App\Http\Requests\Api\PostCreateRequest;
use App\Http\Requests\Api\PostUpdateRequest;
use App\Interfaces\PostRepositoryInterface;

class PostController extends Controller
{
    private PostRepositoryInterface $postRepository;
    
    public function __construct(PostRepositoryInterface $postRepository)
    {
        $this->postRepository = $postRepository;
    }

    public function list()
    {
        return $this->postRepository->list();
    }

    public function findById(int $postId)
    {
        return $this->postRepository->findById($postId);
    }

    public function create(PostCreateRequest $request)
    {
        return $this->postRepository->create($request->validated());
    }

    public function update(PostUpdateRequest $request, int $postId)
    {
        return $this->postRepository->update($postId, $request->validated());
    }

    public function delete(int $postId)
    {
        return $this->postRepository->delete($postId);
    }
}

But in order for PostRepositoryInterface to refer to PostRepository we need to bind the interface to the repository.

Go to the command line and run the following command at the root of the application to create a RepositoryServiceProvider.

php artisan make:provider RepositoryServiceProvider
// Provider created successfully.

And this command should create a file RepositoryServiceProvider.php in the app/Providers.

Inside the RepositoryServiceProvider class, in the register() method, we will bind the interface to the repository. We will also bind all our other interfaces to repositories in this provider.

class RepositoryServiceProvider extends ServiceProvider
{
    /**
     * Register services.
     *
     * @return void
     */
    public function register()
    {
        $this->app->bind(PostRepositoryInterface::class, PostRepository::class);
        // $this->app->bind(CommentRepositoryInterface::class, CommentRepository::class);
        // $this->app->bind(UserRepositoryInterface::class, UserRepository::class);
    }
}

The last step is to register this service provider in our config/app.php. Open this file and add to the providers array our provider App\Providers\RepositoryServiceProvider::class

'providers' => [
    // ...other declared providers
    App\Providers\RepositoryServiceProvider::class,
];

And it’s all! Now our application knows what class it should use when we type objects by its interfaces.

Repository and ORM

Perhaps you have a question: why use a repository if I use an ORM? After all, ORM can work with data, operating with business objects.

However, there may be many cases where data storage is something more complex or specific than just an ORM. And then such a data layer is encapsulated using the repository pattern:

Working through interfaces, you can create multiple repository implementations. For example, MySql for data and a file system for storing images.
Centralizing the data access logic makes the code easier to maintain. For example, you may have some complex query that you need to call from somewhere else in your code.
Don’t Repeat Yourself (DRY): This technique reduces code duplication.
Independence of business logic from the storage method.

Conclusion

After we implemented the Repository Pattern, our code became more structured, more readable, and, importantly, easier to develop and more reusable in the future.

PHP Exceptions: Try Catch for Error Handling

2022-09-12T00:00:00+04:00

PHP 5 introduced us to a new error model that is still evolving today. This model allows you to throw and catch exceptions in your application - it’s a better way to handle errors than older versions of PHP. All exceptions are instances of the Exception base class, which we can extend to introduce our own custom exceptions.

It is important to note here that exception handling is different from error handling. When handling errors, we can use the set_error_handler function to set our custom error handling function so that whenever an error is fired, it will call our error handling function. This way you can manage errors. However, as a rule, some kinds of errors are not recovered and stop the program execution.

On the other hand, exceptions are something that is deliberately thrown by code and is expected to be caught at some point in your application. So we can say that exceptions are recoverable and not certain errors that are not recoverable. If the exception being thrown is somewhere in your application, program execution continues from where the exception was caught. And an exception that doesn’t hit anywhere in your application results in an error that stops the program from running.

Exception handling flow

Let’s take a look at the following diagram, which shows the general control flow of exception handling.

Exceptions can be thrown and caught using try and catch blocks. You are responsible for throwing exceptions if something happens that is not expected. Let’s take a quick look at the main flow of exception handling as shown in the following pseudocode.

// code before the try-catch block
 
try {
  // code
 
  // if something is not as expected
      // throw exception using the "throw" keyword
 
  // code, it won't be executed if the above exception is thrown
} catch (Exception $e) {
  // exception is raised and it'll be handled here
  // $e->getMessage() contains the error message
}
 
// code after the try-catch block, will always be executed

Most of the time, when you’re dealing with exceptions, you end up using a pattern, as shown in the snippet above. You can also use a finally block along with try and catch blocks, but we’ll get to that later in this article.

The try block is the one used when you suspect that your code may be throwing an exception. You should always wrap such code using try and catch.

Throwing an exception

The exception can be thrown by the function you are calling, or you can use the throw keyword to manually throw the exception. For example, you can validate some input before performing any operation and throw an exception if the input is invalid.

The important thing to note here is that if you throw an exception, but you haven’t defined a catch block that should handle that exception, it will result in a fatal error. Therefore, you need to make sure that you always define a catch block if you are throwing exceptions in your application.

When an exception is caught in a catch block, the Exception object contains the error message that was thrown using the throw keyword. The variable $e in the example above is an instance of the Exception class, so it has access to all the methods of that class. In this block, you must define your own exception handling logic - what exactly do you want to do with the error you catch.

In the next section, we’ll take a real world example to understand how exception handling works.

Example from a real project

In this section, we’ll build a real-life example to demonstrate PHP’s exception handling.

Let’s say you’ve created an application that loads the application’s configuration from a config.php file. Now it’s important that the config.php file is present when your application boots up. So your application cannot run if the config.php file is missing. So this is the ideal case to throw an exception and tell the user that they need to fix the problem.

try {
    // init bootstrapping phase
 
    $config_file_path = "config.php";
 
    if (!file_exists($config_file_path))
    {
      throw new Exception("Configuration file not found.");
    }
  
    // continue execution of the bootstrapping phase
} catch (Exception $e) {
    echo $e->getMessage();
    die();
}

As you can see in the example above, we check for the existence of a config.php file at the start of the bootstrap phase. If the config.php file is found, execution continues normally. On the other hand, we will throw an exception if the config.php file does not exist. Also, we would like to stop execution if there is an exception!

This is how you can use exceptions in your applications. You should throw exceptions for exceptional use cases - you should not unnecessarily throw exceptions for errors such as invalid user credentials, incorrect directory access permissions, etc. that you often expect. They are better handled by general error messages in the normal application’s thread of execution.

So this was an example of exception handling using the default Exception class. In the next section, we’ll look at how you can extend the main Exception class and create your own custom exceptions in your application.

How to create custom exceptions

In this section, we will discuss how you can create custom exceptions in your applications. In fact, we’ll extend the example we just discussed in the previous section to demonstrate custom exceptions.

In the previous example, we chose a configuration exception using the default Exception class. This is fine if you just want to deal with the error message. However, sometimes you want to do a little more depending on the type of exception being thrown. This is why custom exclusions are useful.

Let’s move on to the previous example as shown in the following snippet.

class ConfigFileNotFoundException extends Exception {}
 
try {
    // init bootstrapping phase
 
    $config_file_path = "config.php";
 
    if (!file_exists($config_file_path))
    {
      throw new ConfigFileNotFoundException("Configuration file not found.");
    }
  
    // continue execution of the bootstrapping phase
} catch (ConfigFileNotFoundException $e) {
    echo "ConfigFileNotFoundException: ".$e->getMessage();
    // other additional actions that you want to carry out for this exception
    die();
} catch (Exception $e) {
    echo $e->getMessage();
    die();
}

First, we have defined the ConfigFileNotFoundException class, which extends the main Exception class. It now becomes our custom exception class and we can use it when we want to throw a ConfigFileNotFoundException in our application.

We then used the throw keyword to throw a ConfigFileNotFoundException in case the config.php file does not exist. However, the important difference is in the catch block. As you can see, we have defined two catch blocks, and each block is used to catch a different type of exception.

The first one gets exceptions of type ConfigFileNotFoundException. So, if the exception being thrown is of type ConfigFileNotFoundException, this block will be executed. If the exception type does not match any particular catch block, it will match the latter, which should catch all generic exception messages.

Finally block

In this section, we’ll look at how you can use the finally keyword along with try and catch blocks. Sometimes you want to execute a piece of code regardless of whether an exception was thrown. This is where you can use the finally block, since the code you place in the finally block will always be executed after the try and catch blocks have been executed, regardless of whether an exception was thrown.

Let’s try to understand this using the following example.

try {
  // code
 
  // if something is not as expected
      // throw exception using the "throw" keyword
 
  // code, it won't be executed if the above exception is thrown
} catch (Exception $e) {
  // exception is raised and it'll be handled here
  // $e->getMessage() contains the error message
} finally {
  // code, it'll always be executed
}

The code in the above example is almost the same with the only exception that we have added a finally block after the catch block. And, as we discussed, the code in this block will always be executed.

The typical use cases we could come up with for using a finally block are usually related to resource cleanup. For example, if you opened a database connection or file on disk in a try block, you can perform cleanup tasks such as closing the connection in a finally block, as this is guaranteed.

Exception handling is a key coding skill, and you should consider how exceptions will be handled as you develop your applications. This will help you detect and recover from unexpected errors in your application. Hope this post inspires you to write better error handling code!

What are indexes and how do they work

2022-08-29T00:00:00+04:00

Indexes in MySQL are a great tool for optimizing SQL queries.
To understand how they work, let’s look at working with data without them.

1. Reading data from disk

What we see as files, the hard drive sees them as blocks. One file usually occupies several blocks. Each block knows which block comes after it. The file is divided into chunks and each chunk is stored in an empty block.

When reading a file, we go through all the blocks in turn and assemble the file piece by piece. Blocks of the same file can be scattered across the disk (fragmentation). Then reading the file will slow down, as you will need to jump over different parts of the disk.

When we look for something inside a file, we need to go through all the blocks in which it is stored. If the file is very large, then the number of blocks will be significant. The need to jump from block to block, which may be in different places, will greatly slow down the search for data.

2. Finding data in MySQL

MySQL tables are regular files. Let’s execute a query like this:

SELECT * FROM users WHERE age = 29

MySQL then opens a file that stores data from the users table. And then it starts to sort through the entire file to find the necessary records.

In addition, MySQL will compare the data in each row of the table with the value in the query. Let’s say you’re working with a table that has 10 records. Then MySQL will read all 10 records, compare each of their age column with the value 29, and select only the matching data:

So there are two problems when reading data:

Low speed of reading files due to the location of blocks in different parts of the disk (fragmentation).
It requires a large number of comparison operations to find the desired data.

3. Data sorting

Let’s imagine that we have sorted our 10 entries in descending order. Then, using the binary search algorithm, we could select the values we needed in a maximum of four operations:

In addition to fewer comparison operations, we would save on reading unnecessary records.

An index is a sorted set of values. In MySQL, indexes are always built on a particular column. For example, we could build an index on the age column from the example.

4. Selecting Indexes in MySQL

In the simplest case, an index must be created for those columns that are present in the WHERE clause.

Consider the query from the example:

SELECT * FROM users WHERE age = 29

We need to create an index on the age column:

CREATE INDEX age ON users(age);

After this operation, MySQL will start using the age index to perform similar queries. The index will also be used for selections by ranges of values for this column:

SELECT * FROM users WHERE age < 29

Sorting

For queries like this:

SELECT * FROM users ORDER BY register_date

The same rule applies — we create an index on the column by which sorting occurs:

CREATE INDEX register_date ON users(register_date);

Index storage internals

Imagine our table looks like this:

| id | name   | age |
|----|--------|-----|
| 1  | Den    | 29  |
| 2  | Alyona | 15  |
| 3  | Putin  | 89  |
| 4  | Petro  | 12  |

After creating an index on the age column, MySQL will store all its values sorted.
In addition, the relationship between the value in the index and the entry to which this value corresponds will be preserved. The primary key is usually used for this:

| age | index |
|-----|-------|
| 12  | 4     |
| 15  | 2     |
| 29  | 1     |
| 89  | 3     |

Unique indexes

MySQL supports unique indexes. This is useful for columns whose values must be unique throughout the table. Such indexes improve sampling efficiency for unique values. For example:

SELECT * FROM users WHERE email = 'example@example.com';

You need to create a unique index on the email column:

CREATE UNIQUE INDEX email ON users(email)

Then, when searching for data, MySQL will stop after finding the first match. In the case of a regular index, one more check (of the next value in the index) will be mandatory.

5. Composite Indexes

MySQL can only use one index per query (unless MySQL is able to combine select results across multiple indexes). Therefore, for queries that use multiple columns, composite indexes must be used.

Consider this query:

SELECT * FROM users WHERE age = 29 AND gender = 'male'

We need to create a composite index on both columns:

CREATE INDEX age_gender ON users(age, gender);

How a composite index works

To properly use composite indexes, you need to understand how they are stored. Everything works exactly the same as it would for a regular index. But for values, the values of all incoming columns are used at once. For a table with data like this:

| id | name   | age | gender |
|----|--------|-----|--------|
| 1  | Den    | 29  | male   |
| 2  | Alyona | 15  | female |
| 3  | Putin  | 89  | tsar   |
| 4  | Petro  | 12  | male   |

the result of the composite index will be:

| age_gender | index |
|------------|-------|
| 12male     | 4     |
| 15female   | 2     |
| 29male     | 1     |
| 89tsar     | 3     |

This means that the order of the columns in the index will play a big role. Generally, columns that are used in WHERE clauses should be placed at the beginning of the index. Columns from ORDER BY - to the end.

Search by range

Imagine that our query will not use a comparison but a range search:

SELECT * FROM users WHERE age <= 29 AND gender = 'male'

Then MySQL will not be able to use the full index because gender values will be different for different values of the age column. In this case, the database will try to use part of the index (only age) to execute this query:

| age_gender | index |
|------------|-------|
| 12male     | 4     |
| 15female   | 2     |
| 29male     | 1     |
| 89tsar     | 3     |

First, all data that matches the condition age <= 29 will be filtered. Then, a search for the value "male" will be performed without using an index.

Sorting

Composite indexes can also be used for sorting:

SELECT * FROM users WHERE gender = 'male' ORDER BY age

In this case, we will need to create the index in a different order because sorting (ORDER) occurs after filtering (WHERE):

CREATE INDEX gender_age ON users(gender, age);

This order of the columns in the index will allow you to filter by the first part of the index, and then sort the result by the second.

There can be more columns in the index if required:

SELECT * FROM users WHERE gender = 'male' AND country = 'UA' ORDER BY age, register_time

In this case, you should create an index like this:

CREATE INDEX gender_country_age_register ON users(gender, country, age, register_time);

6. Using EXPLAIN to analyze Indexes

The EXPLAIN statement will show index usage data for a particular query. For example

mysql> EXPLAIN SELECT * FROM users WHERE email = 'example@example.com';

The key column shows the index used. The possible_keys column shows all the indexes that can be used for this query. The rows column shows the number of records that the database had to read to execute this query (there are 336 records in the table).

As you can see, no index is used in the example. After creating the index:

mysql> EXPLAIN SELECT * FROM users WHERE email = 'example@example.com';

Only one entry was read because the index was used.

Checking the length of compound indexes

Explain will also help you determine if you are using a composite index correctly. Let’s check the query from the example (with an index on the age and gender columns):

mysql> EXPLAIN SELECT * FROM users WHERE age = 29 AND gender = 'male';

The value of key_len indicates the length of the index to use. In our case, 24 bytes is the length of the entire index (5 bytes age + 19 bytes gender).

If we change the exact comparison to a range search, we see that MySQL uses only part of the index:

mysql> EXPLAIN SELECT * FROM users WHERE age <= 29 AND gender = 'male';

This indicates that the created index is not suitable for this query. If we create the correct index:

mysql> Create index gender_age on users(gender, age);
mysql> EXPLAIN SELECT * FROM users WHERE age < 29 and gender = 'male';

In this case, MySQL uses the entire gender_age index, because the order of the columns in it allows you to make this selection.

7. Index selectivity

Let’s go back to the query:

SELECT * FROM users WHERE age = 29 AND gender = 'male'

For such a query, you need to create a composite index. But how to choose the right sequence of columns in the index? Option two:

age, gender
gender, age

Both will fit. But they will work with different efficiency.

To understand this, consider the uniqueness of the values of each column and the number of corresponding entries in the table:

mysql> select age, count(*) from users group by age;

+------+----------+
| age  | count(*) |
+------+----------+
|   15 |      160 |
|   16 |      250 |
|        ...      |
|   76 |      210 |
|   85 |      230 |
+------+----------+
68 rows in set (0.00 sec)

mysql> select gender, count(*) from users group by gender;

+--------+----------+
| gender | count(*) |
+--------+----------+
| female |     8740 |
| male   |     4500 |
+--------+----------+
2 rows in set (0.00 sec)

This information tells us the following:

Any value of the age column usually contains about 200 entries.
Any value of the gender column is about 6000 entries.

If the age column comes first in the index, then MySQL after the first part of the index will reduce the number of records to 200. It remains to make a selection on them. If the gender column comes first, then the number of entries will be reduced to 6000 after the first part of the index. That is, an order of magnitude more than in the case of age.

This means that the age_gender index will perform better than gender_age.

The selectivity of a column is determined by the number of records in the table with the same values. When there are few records with the same value, selectivity is high. Such columns should be used first in composite indexes.

7. Primary Keys

A primary key is a special type of index that is an identifier for records in a table. It is necessarily unique and is specified when creating tables:

CREATE TABLE `users` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
    `email` varchar(128) NOT NULL,
    `name` varchar(128) NOT NULL,
    PRIMARY KEY (`id`),
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8

When using InnoDB tables, always define primary keys. If there is no primary key, MySQL will still create a virtual private key.

Clustered indexes

Regular indexes are non-clustered. This means that the index itself only stores references to table entries. When working with an index, only the list of records (more precisely, the list of their primary keys) that match the query is determined. After that, another request occurs - to get the data of each record from this list.

Clustered indexes store entire record data, not references to them. When working with such an index, no additional data read operation is required.

Primary keys of InnoDB tables are clustered. Therefore, selections for them are very efficient.

Overhead

It is important to remember that indexes involve additional disk writes. Each time data is updated or added to the table, the data in the index is also written and updated.

Create only necessary indexes to avoid wasting server resources. Control index sizes for your tables:

mysql> show table status;

+-------------------+--------+---------+------------+--------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+---------+
| Name              | Engine | Version | Row_format | Rows   | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time         | Update_time | Check_time | Collation       | Checksum | Create_options | Comment |
+-------------------+--------+---------+------------+--------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+---------+
...
| users             | InnoDB |      10 | Compact    |    314 |            208 |       65536 |               0 |        16384 |         0 |            355 | 2014-07-11 01:12:17 | NULL        | NULL       | utf8_general_ci |     NULL |                |         |
+-------------------+--------+---------+------------+--------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+---------+
18 rows in set (0.06 sec)

When to create indexes?

Indexes should be created as slow queries are discovered. Queries that run for more than 1 second are prime candidates for optimization.
Start creating indexes with the most frequent queries. A query that runs for a second, but 1000 times a day does more damage than a 10-second query that runs several times a day.
Do not create indexes on tables with fewer than a few thousand records. For such sizes, the gain from using the index will be almost imperceptible.
Do not create indexes ahead of time, such as in a development environment. Indexes should be set exclusively for the form and type of load of the operating system.
Remove unused indexes.

The most important

Allow sufficient time to analyze and organize indexes in MySQL (and other databases). This can take much more time than designing the database structure. It will be convenient to organize a test environment with a copy of real data and test different index structures there.

Don’t create indexes on every column in a query, MySQL doesn’t work that way. Use unique indexes where necessary. Always set primary keys.

D - Dependency Inversion Principle | SOLID

2022-08-22T00:00:00+04:00

The Dependency Inversion Principle (DIP) is the fifth of the five basic principles of object-oriented programming and design, formulated by Robert Martin, known as Uncle Bob.

The principle says that

High level modules should not depend on low level modules; both should depend on abstractions. Abstractions should not depend on details. Details should depend upon abstractions.

The principle may seem complicated at first glance, but it is very easy to understand.
It’s better to see this with an example.

class EmailSender {
     private $emailProvider;
 
     public function __construct(Gmail $emailProvider) {
         $this->semailProvider = $emailProvider;
     }
     
     public function connect(){/*...*/}
}

Gmail is a low-level module, and EmailSender is a high-level one.
But according to the definition of the principle, which says to separate abstractions from implementation, this fragment violates it because the EmailSender class depends on the Gmail class.

If you later need to replace the email sending provider, then you will have to change the EmailSender class, which violates the principle of open/closed(OCP).

The EmailSender class doesn’t have to worry about the provider that is being used.
To fix this, we need to allocate an interface so that low-level and high-level modules depend on abstraction.

interface EmailProviderInterface {
     public function connect();
}

The interface has a connect method, and the Gmail class implements it. Also, instead of checking the type to see whether the passed object belongs to the Gmail class in the EmailSender constructor, we use the interface ownership check. And the EmailSender class no longer worries about the type of provider that will be used, the main thing is that there is a connection possibility and the OCP principle is not violated.

class Gmail implements EmailProviderInterface {
     public function connect() {
         return "Gmail connection";
     }
}
 
class EmailSender {
     private $emailProvider;
 
     public function __construct(EmailProviderInterface $emailProvider) {
         $this->semailProvider = $emailProvider;
     }
     
     public function connect(){/*...*/}
}

Now both modules (low-level and high-level) depend on abstraction.

I - Interface Segregation Principle | SOLID

2022-08-15T00:00:00+04:00

The Interface Segregation Principle (ISP) is the fourth of the five basic principles of object-oriented programming and design, formulated by Robert Martin, known as Uncle Bob.

The principle says that

Many client-specific interfaces are better than one general-purpose interface.

This principle is very easy to understand, and following it is necessary so that classes that implement an interface only know about the methods they use, which leads to a reduction in the amount of unused code.

Here is an example from an online store.
Assume our products have a promotional code, a discount, a price, a condition, and so on.
If it is clothing, then it is determined by what material it is made of, color, and size.
Let’s describe the following interface.

interface ItemInterface
{
    public function applyDiscount($discount);
    public function applyPromocode($promocode);
    
    public function setColor($color);
    public function setSize($size);
    
    public function setCondition($condition);
    public function setPrice($price);
}

This interface is bad because it includes too many methods. And what if our product category is not eligible for a discount or promotional code, or if it makes no sense to install the material from which it is made (for example, books)? Thus, in order not to implement unused methods in each class, it is better to divide the interface into several small ones and implement the necessary interfaces with each specific class.

interface ItemInterface
{
	public function setCondition($condition);
	public function setPrice($price);
}

interface ClothesInterface
{
	public function setColor($color);
	public function setSize($size);
	public function setMaterial($material);
}

interface DiscountableInterface
{
	public function applyDiscount($discount);
	public function applyPromocode($promocode);
}

class Book implemets ItemInterface, DiscountableInterface
{
    public function setCondition($condition){/*...*/}
    public function setPrice($price){/*...*/}
    public function applyDiscount($discount){/*...*/}
    public function applyPromocode($promocode){/*...*/}
}

class KidsClothes implemets ItemInterface, ClothesInterface
{
    public function setCondition($condition){/*...*/}
    public function setPrice($price){/*...*/}
    public function setColor($color){/*...*/}
    public function setSize($size){/*...*/}
    public function setMaterial($material){/*...*/}
}

L - Liskov Substitution Principle | SOLID

2022-08-08T00:00:00+04:00

The Liskov Substitution Principle (LSP) is the third of the five basic principles of object-oriented programming and design, formulated by Robert Martin, known as Uncle Bob.

The principle says that

Subclasses should be substitutable for their base classes.

In simple terms, we can say that the behavior of inherited classes should not contradict the behavior specified by the base class, that is, the behavior of extended classes must be expected as in the base class.

This implies a ban on manipulating the data of the parent class and overriding the methods of the parent class with a change (but not an extension) of their functionality. It was a revolutionary approach for its time and still remains one of the most powerful design principles.

First, let’s look at an example that violates the LSP principle.

class MediaPlayer
{
    public function playAudio()
    {
        return 'Playing audio...';
    }
    
    public function playVideo()
    {
        return 'Playing video...';
    }
}

class VlcMediaPlayer extends MediaPlayer
{
    public function playAudio()
    {
        return 'Playing audio...';
    }
    
    public function playVideo()
    {
        return 'Playing video...';
    }
}

class WinampMediaPlayer extends MediaPlayer
{
    public function playAudio()
    {
        return 'Playing audio...';
    }
}

The LSP principle states that classes should treat base class methods equally.
And WinampMediaPlayer only supports audio playback and is incompatible with video playback, and therefore we will get an error

$vlc = new VlcMediaPlayer();
$vlc->playAudio();
$vlc->playVideo();

$winamp = new WinampMediaPlayer();
$winamp->playAudio();
$winamp->playVideo(); // There will be an error

Now consider an example that does not violate the LSP principle

class MediaPlayer
{
    public function playAudio()
    {
        return 'Playing audio...';
    }
}

class VideoMediaPlayer extends MediaPlayer
{
    public function playVideo()
    {
        return 'Playing video...';
    }
}

class VlcMediaPlayer extends VideoMediaPlayer
{

}

class WinampMediaPlayer extends MediaPlayer
{
    public function playAudio()
    {
        return 'Playing audio...';
    }
}

Now inherited classes do not violate the behavior of base classes, and therefore the LSP principle is not violated.

O - Open-Closed Principle | SOLID

2022-08-01T00:00:00+04:00

The Open-Closed Principle (OCP) is second of the five basic principles of object-oriented programming and design, formulated by Robert Martin, known as Uncle Bob.

The principle says that

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification

This means that these entities can change their behavior without changing their source code.

Following the principle of OCP is that software changes not by changing existing code, but by adding new code. That is, the code originally created remains “intact” and stable, and new functionality is introduced either through implementation inheritance, or through the use of abstract interfaces and polymorphism.

Consider the OrderRepository class as an example.

class OrderRepository
{
    public function load($orderID)
    {
        $pdo = new PDO(
            $this->config->getDsn(),
            $this->config->getDBUser(),
            $this->config->getDBPassword()
        );
        $statement = $pdo->prepare('SELECT * FROM `orders` WHERE id=:id');
        $statement->execute([':id' => $orderID]);
        return $query->fetchObject('Order');	
    }
    public function save($order){/*...*/}
    public function update($order){/*...*/}
    public function delete($order){/*...*/}
}

In this case, the storage is the DB database. But if we want to expand the functionality and upload our order data through a third-party server using the API, then what will need to be done for this?

There are several options:

First, you can directly change the methods of the OrderRepository class, but this one does not follow the open/closed principle, since the class is closed for modification, and making changes to an already well-functioning class is undesirable.

Second, you can extend the OrderRepository class and override all methods, but this is not the best solution. since when adding a new method to OrderRepository we will have to add similar methods in all extended classes.

Therefore, to implement the open/closed principle, it is better to apply the following solution:
Create an OrderSourceInterface, which will be implemented by the corresponding classes DBOrderSource, ApiOrderSource, and so on.

class OrderRepository
{
    private $source;

    public function __construct(OrderSourceInterface $source)
    {
        $this->source = $source;
    }

    public function load($orderID){/*...*/}
    public function save($order){/*...*/}
    public function update($order){/*...*/}
}

interface OrderSourceInterface
{
    public function load($orderID){/*...*/}
    public function save($order){/*...*/}
    public function update($order){/*...*/}
    public function delete($order){/*...*/}
}

class DBOrderSource implements OrderSourceInterface
{
    public function load($orderID){/*...*/}
    public function save($order){/*...*/}
    public function update($order){/*...*/}
    public function delete($order){/*...*/}
}

class ApiOrderSource implements OrderSourceInterface
{
    public function load($orderID){/*...*/}
    public function save($order){/*...*/}
    public function update($order){/*...*/}
    public function delete($order){/*...*/}
}

Thus, we can change the source and, accordingly, the behavior for the OrderRepository class by setting the class we need that implements OrderSourceInterface, without changing the OrderRepository class.

S - Single Responsibility Principle | SOLID

2022-07-25T00:00:00+04:00

The Single Responsibility Principle (SRP) is the one of the five basic principles of object-oriented programming and design, formulated by Robert Martin, known as Uncle Bob.

The principle says that

A class should be one, and only one, reason to change.

In this article, I will try to explain this principle with a simple example.
We have a User class where there is a CRUD of the user with his documents.

class User
{
    public function list() {/*...*/}
    public function get(int $id) {/*...*/}
    public function create(array $data) {/*...*/}
    public function update(array $data, int $id) {/*...*/}
    public function delete(int $id) {/*...*/}
    
    public function documentList(int $userId) {/*...*/}
    public function getDocument(int $userId, int $id) {/*...*/}
    public function createDocument(int $userId, array $data) {/*...*/}
    public function updateDocument(int $userId, array $data, int $id) {/*...*/}
    public function deleteDocument(int $userId, int $id) {/*...*/}
}

This approach violates SRP since the class is responsible for two jobs: Working with users and working with documents.

The problem can be solved by dividing the class into two separate classes.

class User
{
    public function list() {/*...*/}
    public function get(int $id) {/*...*/}
    public function create(array $data) {/*...*/}
    public function update(array $data, int $id) {/*...*/}
    public function delete(int $id) {/*...*/}
}

class UserDocument
{
    private $user;
    
    public function __construct(User $user)
    {
        $this->user = $user;
    }
    
    public function list() {/*...*/}
    public function get(int $id) {/*...*/}
    public function create(array $data) {/*...*/}
    public function update(array $data, int $id) {/*...*/}
    public function delete(int $id) {/*...*/}
}

Now the class does exactly one thing and has exactly one reason to change.

How to register and use the Laravel service providers

2022-07-18T00:00:00+04:00

If you’ve ever been familiar with the Laravel framework, it’s unlikely that you haven’t heard of service containers and service providers. In fact, they are the backbone of the Laravel framework and do all the heavy lifting when you launch an instance of any Laravel application.

In this article, we’ll see what a service container is, and after that, we’ll discuss service providers in detail. In the course of this article, I’ll also demonstrate how to create your own custom service provider in Laravel. When you create a service provider, you also need to register it with your Laravel application in order to use it, so we’ll cover that as well.

There are two important methods: boot and register, that your service provider can implement, and we’ll discuss them in detail in the last section of this article.

Before moving on to the discussion of the service provider, I will try to introduce the service container as it will be heavily used in your service provider implementation.

Understanding Service Containers and Service Providers

What is a service container?

In the simplest terms, we can say that a container in Laravel is a box that contains the bindings of various components, and these are maintained as needed throughout the application.

According to the official Laravel documentation:

The Laravel service container is a powerful tool for managing class dependencies and performing dependency injection.

This way, whenever you need to inline any bean or service, you can specify it in your constructor or method and it will be automatically inlined from the service container as it contains everything you need! Isn’t that cool? This saves you the hassle of manually laying out components and thus avoids hard coupling in your code.

Let’s look at a quick example to understand this.

Class SomeClass
{
    public function __construct(FooBar $foobarObject)
    {
        // use $foobarObject object
    }
}

As you can see, SomeClassneeds an instance FooBarto instantiate. So basically, it has a dependency that needs to be built in. Laravel does this automatically by looking at the container and injecting the appropriate dependency.

And if you’re wondering how Laravel knows which components or services to include in a container, the answer is a service provider. The service provider tells Laravel to include various components in the service container. In fact, this is called binding to service containers, and you need to do it through the service provider.

Thus, the service provider registers all of the container’s bindings, and this is done through the register method of the service provider’s implementation.

Another question that should immediately pop up is: how does Laravel know about the different service providers? Did you just say something? I just heard someone say that Laravel should figure this out automatically too! Oh, you’re asking too much: Laravel is a framework, not a superhuman, is it? So service providers are what you need to tell Laravel directly.

Go ahead and see the contents of the file config/app.php. You will find an array entry that lists all the service providers that will be loaded during the initial load of the Laravel application.

'providers' => [
    /*
     * Laravel Framework Service Providers...
     */
    Illuminate\Auth\AuthServiceProvider::class,
    Illuminate\Broadcasting\BroadcastServiceProvider::class,
    Illuminate\Bus\BusServiceProvider::class,
    /*...*/
    Illuminate\Translation\TranslationServiceProvider::class,
    Illuminate\Validation\ValidationServiceProvider::class,
    Illuminate\View\ViewServiceProvider::class,

    /*
     * Package Service Providers...
     */

    /*
     * Application Service Providers...
     */
    App\Providers\AppServiceProvider::class,
    App\Providers\AuthServiceProvider::class,
    // App\Providers\BroadcastServiceProvider::class,
    App\Providers\EventServiceProvider::class,
    App\Providers\RouteServiceProvider::class,
],

So, this was the container at your disposal. In the next section, we’ll focus on the service provider, which is the main topic of this article!

What is a service provider?

If the container is what allows you to define bindings and install dependencies, a service provider is where it all happens.

Let’s take a quick look at one of the major service providers to see what it does. Open filevender/laravel/framework/src/Illuminate/Cache/CacheServiceProvider.php

public function register()
{
    $this->app->singleton('cache', function ($app) {
        return new CacheManager($app);
    });
  
    $this->app->singleton('cache.store', function ($app) {
        return $app['cache']->driver();
    });
  
    $this->app->singleton('memcached.connector', function () {
        return new MemcachedConnector;
    });
}

The important thing to note here is the method register that allows you to define container bindings. As you can see, there are three bindings for the cache, cache.store and memcached.connector.

Basically, we inform Laravel that whenever there is a need to allow a service to be retrieved cache, it should return an instance of CacheManager. So we just add this match to the container, which can be accessed via $this->app.

This is the correct way to add any service to a Laravel container. It also allows you to understand how Laravel goes through the register method of all service providers and populates the container! As we mentioned earlier, it uses the list of service providers from the config/app.php.

And it was a story about a service provider. In the next section, we’ll discuss how to create a custom service provider so that you can register your custom services with a Laravel container.

Creating your own service provider

Laravel already has a handy command line utility, artisan, that allows you to generate template code so you don’t have to create it from scratch. Go to the command line and run the following command at the root of the application to create a custom service provider.

php artisan make:provider DemoCustomServiceProvider
// Provider created successfully.

And this command should create a file DemoCustomServiceProvider.php in the app/Providers. When we open the file, we will see the following code

<?php
namespace App\Providers;
  
use Illuminate\Support\ServiceProvider;
  
class DemoCustomServiceProvider extends ServiceProvider
{
    /**
     * Bootstrap the application services.
     *
     * @return void
     */
    public function boot()
    {
        //
    }
  
    /**
     * Register the application services.
     *
     * @return void
     */
    public function register()
    {
        //
    }
}

As we discussed earlier, there are two methods, register and booy, that you will deal with most of the time when working with your custom service provider.

The method register is where you define all custom container bindings. On the other hand, a method boot is a place where you can use services already registered via the register method. In the last section of this article, we will discuss these two methods in detail as we go through some practical examples to understand the use of both methods.

Register your custom service provider

Thus, you have created your own service provider. Wonderful! You then need to tell Laravel about your custom service provider so that it can load it along with other providers during bootstrap.

To register a service provider, you simply need to add an entry to the service provider array in the config/app.php.

'providers' => [
    /*
     * Laravel Framework Service Providers...
     */
    Illuminate\Auth\AuthServiceProvider::class,
    Illuminate\Broadcasting\BroadcastServiceProvider::class,
    Illuminate\Bus\BusServiceProvider::class,
    /*...*/
    Illuminate\Translation\TranslationServiceProvider::class,
    Illuminate\Validation\ValidationServiceProvider::class,
    Illuminate\View\ViewServiceProvider::class,

    /*
     * Package Service Providers...
     */

    /*
     * Application Service Providers...
     */
    App\Providers\AppServiceProvider::class,
    App\Providers\AuthServiceProvider::class,
    // App\Providers\BroadcastServiceProvider::class,
    App\Providers\EventServiceProvider::class,
    App\Providers\RouteServiceProvider::class,
    App\Providers\DemoCustomServiceProvider::class, // <- Insert class here
],

That’s all! You have registered your service provider with the Laravel Schema! But the service provider we created is almost an empty template and is not used at the moment. In the next section, we’ll look at some practical examples to see what you can do with the register and boot methods.

Let's go through the register and boot methods

First, we’ll take a look at the method register to understand how you can use it. Open the service provider file you created earlier app/Providers/DemoCustomServiceProvider.php and replace the existing code with the following.

<?php
namespace App\Providers;
  
use Illuminate\Support\ServiceProvider;
use App\Library\Services\DemoOne;
  
class DemoCustomServiceProvider extends ServiceProvider
{
    public function boot() {/*...*/}
  
    public function register()
    {
        $this->app->bind('App\Library\Services\DemoOne', function ($app) {
          return new DemoOne();
        });
    }
}

There are two important points here:

We have imported App\Library\Services\DemoOne so that we can use it. The class DemoOne hasn’t been created yet, but we’ll do that in a moment.
In the register method, we used the bind service container method to add our service binding to the container. Thus, whenever a dependency needs to be resolved App\Library\Services\DemoOne, it invokes a closure that instantiates and returns a App\Library\Services\DemoOne.

To do this, you just need to create a app/Library/Services/DemoOne.php.

<?php
namespace App\Library\Services;
  
class DemoOne
{
    public function doSomethingUseful()
    {
      return 'Output from DemoOne';
    }
}

And here is the code somewhere in your controller where the dependency will be injected.

<?php
namespace App\Http\Controllers;
  
use App\Http\Controllers\Controller;
use App\Library\Services\DemoOne;
  
class TestController extends Controller
{
    public function index(DemoOne $customServiceInstance)
    {
        echo $customServiceInstance->doSomethingUseful();
    }
}

This is a very simple class binding example. In fact, in the above example, there is no need to create a service provider and implement the register method as we did, since Laravel can automatically resolve it using reflection.

A very important note from the Laravel documentation:

There is no need to bind classes into the container if they do not depend on any interfaces. The container does not need to be instructed on how to build these objects, since it can automatically resolve these objects using reflection.

On the other hand, it would be very helpful if you would bind an interface to a specific implementation. Let’s take an example to understand this.

Let’s create a very simple interface in app/Library/Services/Contracts/CustomServiceInterface.php.

<?php
namespace App\Library\Services\Contracts;
  
Interface CustomServiceInterface
{
    public function doSomethingUseful();
}

Next, let’s create two implementations of this interface. Basically, we just need to create two classes that implement the CustomServiceInterface.

Create a class DemoOne in app/Library/Services/DemoOne.php.

<?php
namespace App\Library\Services;
  
use App\Library\Services\Contracts\CustomServiceInterface;
  
class DemoOne implements CustomServiceInterface
{
    public function doSomethingUseful()
    {
      return 'Output from DemoOne';
    }
}

Likewise, DemoTwo will be in App/Library/Services/DemoTwo.php.

<?php
namespace App\Library\Services;
  
use App\Library\Services\Contracts\CustomServiceInterface;
  
class DemoTwo implements CustomServiceInterface
{
    public function doSomethingUseful()
    {
      return 'Output from DemoTwo';
    }
}

Now, instead of binding a class, we will bind an interface. Open again DemoCustomServiceProvider.php and modify the code as shown below.

<?php
namespace App\Providers;
  
use Illuminate\Support\ServiceProvider;
use App\Library\Services\DemoOne;
  
class DemoCustomServiceProvider extends ServiceProvider
{
    public function boot()
    {
    }
  
    public function register()
    {
        $this->app->bind(
            'App\Library\Services\Contracts\CustomServiceInterface',
            function ($app) {
                return new DemoOne();
            }
        );
    }
}

In this case, we have bound the interface App\Library\Services\Contracts\CustomServiceInterface to the implementation DemoOne. Therefore, whenever a dependency needs to be resolved App\Library\Services\Contracts\CustomServiceInterface, an instance will be created and an object will be returned App\Library\Services\DemoOne. Now that makes sense, doesn’t it?

Let’s quickly review the controller code.

<?php
namespace App\Http\Controllers;
  
use App\Http\Controllers\Controller;
use App\Library\Services\Contracts\CustomServiceInterface;
  
class TestController extends Controller
{
    public function index(CustomServiceInterface $customServiceInstance)
    {
        echo $customServiceInstance->doSomethingUseful();
    }
}

As you may have guessed, $customServiceInstance must be an instance of App\Library\Services\DemoOne! The beauty of this approach is that you can easily replace the implementation DemoOne with another class.

Let’s say you want to use an implementation DemoTwo instead of DemoOne. In this case, you just need to make the following changes to the service provider DemoCustomServiceProvider.php.

Now let’s make small changes to the code

// Find the following line:
use App\Library\Services\DemoOne;
// And replace it with:
use App\Library\Services\DemoTwo;

// Find this in a similar way:
return new DemoOne();
// This should be replaced with:
return new DemoTwo();

The same approach can be used if you want to replace any core implementation with your own. And it’s not just the bind method that you could use to bind a service to a container; The Laravel container provides various binding methods. Please see the official Laravel documentation for a complete reference.

The next candidate is a method boot that can be used to extend the functionality of Laravel’s core. In this method, you can access all services that have been registered using the register method on service providers. In most cases, you want to register event listeners on this method that will fire when something happens.

Let’s look at a few examples that require the implementation of the boot method.

You want to add your own form field validation tool to Laravel.

public function boot()
{
    Validator::extend('my_custom_validator', function ($attribute, $value, $parameters, $validator) {
        // validation logic goes here...
    });
}

If you want to register a display builder, this is the perfect place to do it! In fact, you could say that the boot method is often used to add display builders!

public function boot()
{
    View::composer(
        'demo', 'App\Http\ViewComposers\DemoComposer'
    );
}

Of course, you need to first import the facade Illuminate\Support\Facades\View in your service provider.

In the same territory, you can share data across multiple views!

public function boot()
{
    View::share('key', 'value');
}

It can also be used to define explicit model bindings.

public function boot()
{
    parent::boot();
  
    Route::model('user', App\User::class);
}

These were a few examples to demonstrate the use of the boot method. The more you dive into Laravel, the more reasons you will find to implement it!