If you've ever come across the Laravel framework, it's highly unlikely that you haven't heard of service containers and service providers. In fact, they're 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're going to have a glimpse of what the service container is all about, and following that we'll discuss the service provider in detail. In the course of this article, I'll also demonstrate how to create a custom service provider in Laravel. Once you create a service provider, you also need to register it with the Laravel application in order to actually use it, so we'll go through that as well.

There are two important methods, boot and register, that your service provider may implement, and in the last segment of this article we'll discuss these two methods thoroughly.

Before we dive into the discussion of a service provider, I'll try to introduce the service container as it will be used heavily in your service provider implementation.

Understand Service Containers and Service Providers

What Is a Service Container?

In the simplest terms, we could say that the service container in Laravel is a box that holds various components' bindings, and they are served as needed throughout the application.

In the words of the official Laravel documentation:

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

So, whenever you need to inject any built-in component or service, you could type hint it in your constructor or method, and it'll be injected automatically from the service container as it contains everything you need! Isn't that cool? It saves you from manually instantiating the components and thus avoids tight coupling in your code.

Let's have a look at a quick example to understand it.

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

As you can see, the SomeClass needs an instance of FooBar to instantiate itself. So, basically, it has a dependency that needs to be injected. Laravel does this automatically by looking into the service container and injecting the appropriate dependency.

And if you're wondering how Laravel knows which components or services to include in the service container, the answer is the service provider. It's the service provider that tells Laravel to bind various components into the service container. In fact, it's called service container bindings, and you need to do it via the service provider.

So it's the service provider that registers all the service container bindings, and it's done via the register method of the service provider implementation.

That should bring another question on the table: how does Laravel know about various service providers? Did you just say anything? I've just heard someone saying that, Laravel should figure that out automatically too! Oh boy, that's too much to ask: Laravel is a framework not a superman, isn't it? Kidding apart, that's something you need to inform Laravel explicitly.

Go ahead and look at the contents of the config/app.php file. You'll find an array entry that lists all the service providers that will be loaded during the bootstrapping of the Laravel application.

'providers' => [

        /*
         * Laravel Framework Service Providers...
         */
        Illuminate\Auth\AuthServiceProvider::class,
        Illuminate\Broadcasting\BroadcastServiceProvider::class,
        Illuminate\Bus\BusServiceProvider::class,
        Illuminate\Cache\CacheServiceProvider::class,
        Illuminate\Foundation\Providers\ConsoleSupportServiceProvider::class,
        Illuminate\Cookie\CookieServiceProvider::class,
        Illuminate\Database\DatabaseServiceProvider::class,
        Illuminate\Encryption\EncryptionServiceProvider::class,
        Illuminate\Filesystem\FilesystemServiceProvider::class,
        Illuminate\Foundation\Providers\FoundationServiceProvider::class,
        Illuminate\Hashing\HashServiceProvider::class,
        Illuminate\Mail\MailServiceProvider::class,
        Illuminate\Notifications\NotificationServiceProvider::class,
        Illuminate\Pagination\PaginationServiceProvider::class,
        Illuminate\Pipeline\PipelineServiceProvider::class,
        Illuminate\Queue\QueueServiceProvider::class,
        Illuminate\Redis\RedisServiceProvider::class,
        Illuminate\Auth\Passwords\PasswordResetServiceProvider::class,
        Illuminate\Session\SessionServiceProvider::class,
        Illuminate\Translation\TranslationServiceProvider::class,
        Illuminate\Validation\ValidationServiceProvider::class,
        Illuminate\View\ViewServiceProvider::class,

        /*
         * Package Service Providers...
         */
        Laravel\Tinker\TinkerServiceProvider::class,

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

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

What Is a Service Provider?

If the service container is something that allows you to define bindings and inject dependencies, then the service provider is the place where it happens.

Let's have a quick look at one of the core service providers to understand what it does. Go ahead and open the vender/laravel/framework/src/Illuminate/Cache/CacheServiceProvider.php file.

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 register method, which allows you to define service container bindings. As you can see, there are three bindings for the cache, cache.store and memcached.connector services.

Basically, we're informing Laravel that whenever there's a need to resolve a cache entry, it should return the instance of CacheManager. So we're just adding a kind of mapping in the service container that can be accessed via $this->app.

This is the proper way to add any service to a Laravel service container. That also allows you to realize the bigger picture of how Laravel goes through the register method of all service providers and populates the service container! And as we've mentioned earlier, it picks up the list of service providers from the config/app.php file.

And that's the story of the service provider. In the next section, we'll discuss how to create a custom service provider so that you can register your custom services into the Laravel service container.

Create Your Custom Service Provider

Laravel already comes with a hands-on command-line utility tool, artisan, which allows you to create template code so that you don't have to create it from scratch. Go ahead and move to the command line and run the following command in your application root to create a custom service provider.

$php artisan make:provider EnvatoCustomServiceProvider
Provider created successfully.

And that should create the file EnvatoCustomServiceProvider.php under the app/Providers directory. Open the file to see what it holds.

<?php
namespace App\Providers;

use Illuminate\Support\ServiceProvider;

class EnvatoCustomServiceProvider 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, boot and register, that you'll be dealing with most of the time when you work with your custom service provider.

The register method is the place where you define all your custom service container bindings. On the other hand, the boot method is the place where you can consume already registered services via the register method. In the last segment of this article, we'll discuss these two methods in detail as we'll go through some practical use cases to understand the usage of both the methods.

Register Your Custom Service Provider

So you've created your custom service provider. That's great! Next, you need to inform Laravel about your custom service provider so that it can load it along with other service providers during bootstrapping.

To register your service provider, you just need to add an entry to the array of service providers in the config/app.php file.

'providers' => [

        /*
         * Laravel Framework Service Providers...
         */
        Illuminate\Auth\AuthServiceProvider::class,
        Illuminate\Broadcasting\BroadcastServiceProvider::class,
        Illuminate\Bus\BusServiceProvider::class,
        Illuminate\Cache\CacheServiceProvider::class,
        Illuminate\Foundation\Providers\ConsoleSupportServiceProvider::class,
        Illuminate\Cookie\CookieServiceProvider::class,
        Illuminate\Database\DatabaseServiceProvider::class,
        Illuminate\Encryption\EncryptionServiceProvider::class,
        Illuminate\Filesystem\FilesystemServiceProvider::class,
        Illuminate\Foundation\Providers\FoundationServiceProvider::class,
        Illuminate\Hashing\HashServiceProvider::class,
        Illuminate\Mail\MailServiceProvider::class,
        Illuminate\Notifications\NotificationServiceProvider::class,
        Illuminate\Pagination\PaginationServiceProvider::class,
        Illuminate\Pipeline\PipelineServiceProvider::class,
        Illuminate\Queue\QueueServiceProvider::class,
        Illuminate\Redis\RedisServiceProvider::class,
        Illuminate\Auth\Passwords\PasswordResetServiceProvider::class,
        Illuminate\Session\SessionServiceProvider::class,
        Illuminate\Translation\TranslationServiceProvider::class,
        Illuminate\Validation\ValidationServiceProvider::class,
        Illuminate\View\ViewServiceProvider::class,

        /*
         * Package Service Providers...
         */
        Laravel\Tinker\TinkerServiceProvider::class,

        /*
         * 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\EnvatoCustomServiceProvider::class,
],

And that's it! You've registered your service provider with Laravel's scheme of things! But the service provider we've created is almost a blank template and of no use at the moment. In the next section, we'll go through a couple of practical examples to see what you could do with the register and boot methods.

Go Through the Register and Boot Methods

To start with, we'll go through the register method to understand how you could actually use it. Open the service provider file app/Providers/EnvatoCustomServiceProvider.php that was created earlier and replace the existing code with the following.

<?php
namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use App\Library\Services\DemoOne;

class EnvatoCustomServiceProvider extends ServiceProvider
{
    public function boot()
    {
    }

    public function register()
    {
        $this->app->bind('App\Library\Services\DemoOne', function ($app) {
          return new DemoOne();
        });
    }
}

There are two important things to note here:

• We've imported App\Library\Services\DemoOne so that we can use it. The DemoOne class isn't created yet, but we'll do that in a moment.
• In the register method, we've used the bind method of the service container to add our service container binding. So, whenever the App\Library\Services\DemoOne dependency needs to be resolved, it'll call the closure function, and it instantiates and returns the App\Library\Services\DemoOne object.

So you just need to create the app/Library/Services/DemoOne.php file for this to work.

<?php
namespace App\Library\Services;

class DemoOne
{
    public function doSomethingUseful()
    {
      return 'Output from DemoOne';
    }
}

And here's 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();
    }
}

That's a very simple example of binding a class. In fact, in the above example, there's 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 have been really useful if you had bound an interface to a certain implementation. Let's go through an example to understand it.

Let's create a very simple interface at app/Library/Services/Contracts/CustomServiceInterface.php.

<?php
// app/Library/Services/Contracts/CustomServiceInterface.php
namespace App\Library\Services\Contracts;

Interface CustomServiceInterface
{
    public function doSomethingUseful();
}

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

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

<?php
// app/Library/Services/DemoOne.php
namespace App\Library\Services;

use App\Library\Services\Contracts\CustomServiceInterface;

class DemoOne implements CustomServiceInterface
{
    public function doSomethingUseful()
    {
      return 'Output from DemoOne';
    }
}

Similarly, DemoTwo goes in app/Library/Services/DemoTwo.php.

<?php
// app/Library/Services/DemoTwo.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'll bind an interface. Revisit EnvatoCustomServiceProvider.php and change the code as shown below.

<?php
namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use App\Library\Services\DemoOne;

class EnvatoCustomServiceProvider 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've bound the App\Library\Services\Contracts\CustomServiceInterface interface to the DemoOne implementation. Hence, whenever the App\Library\Services\Contracts\CustomServiceInterface dependency needs to be resolved, it instantiates and returns the App\Library\Services\DemoOne object. Now it makes more sense, doesn't it?

Let's quickly revise the controller code as well.

<?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, the $customServiceInstance should be the instance of App\Library\Services\DemoOne! The beauty of this approach is that you can swap the DemoOne implementation with the other one easily.

Let's say you want to use the DemoTwo implementation instead of DemoOne. In that case, you just need to make the following changes in the service provider EnvatoCustomServiceProvider.php.

Find the following line:

use App\Library\Services\DemoOne;

And replace it with:

use App\Library\Services\DemoTwo;

Similarly, find this one:

return new DemoOne();

That should be replaced by:

return new DemoTwo();

The same approach can be used should you want to replace any core implementation with your own. And it's not only the bind method you could use for your service container bindings; the Laravel service container provides various ways of binding into the service container. Please check the official Laravel documentation for the complete reference.

The next candidate is the boot method, which you could use to extend the core Laravel functionality. In this method, you could access all the services that were registered using the register method of the service provider. In most cases, you want to register your event listeners in this method, which will be triggered when something happens.

Let's have a look at a couple of examples that require the boot method implementation.

You want to add your own custom form field validator to Laravel.

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

Should you wish to register a view composer, it's the perfect place to do that! In fact, we could say that the boot method is frequently used to add view composers!

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

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

In the same territory, you could share the data across multiple views as well!

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 usage of the boot method. The more you get into Laravel, the more reasons you'll find to implement it!

And with that, we've reached the end of this article. I hope you've enjoyed the topics that were discussed throughout this article.

Conclusion

It was the discussion of service providers that was the center attraction of this article, although we began our article with the service container as that was an important ingredient in order to understand the service provider.

Following that, we developed a custom service provider, and in the latter half of the article we went through a couple of practical examples.

For those of you who are either just getting started with Laravel or looking to expand your knowledge, site, or application with extensions, we have a variety of things you can study at Envato Market.

If you've any queries or comments, just shoot it using the feed below!