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... */ IlluminateAuthAuthServiceProvider::class, IlluminateBroadcastingBroadcastServiceProvider::class, IlluminateBusBusServiceProvider::class, IlluminateCacheCacheServiceProvider::class, IlluminateFoundationProvidersConsoleSupportServiceProvider::class, IlluminateCookieCookieServiceProvider::class, IlluminateDatabaseDatabaseServiceProvider::class, IlluminateEncryptionEncryptionServiceProvider::class, IlluminateFilesystemFilesystemServiceProvider::class, IlluminateFoundationProvidersFoundationServiceProvider::class, IlluminateHashingHashServiceProvider::class, IlluminateMailMailServiceProvider::class, IlluminateNotificationsNotificationServiceProvider::class, IlluminatePaginationPaginationServiceProvider::class, IlluminatePipelinePipelineServiceProvider::class, IlluminateQueueQueueServiceProvider::class, IlluminateRedisRedisServiceProvider::class, IlluminateAuthPasswordsPasswordResetServiceProvider::class, IlluminateSessionSessionServiceProvider::class, IlluminateTranslationTranslationServiceProvider::class, IlluminateValidationValidationServiceProvider::class, IlluminateViewViewServiceProvider::class, /* * Package Service Providers... */ LaravelTinkerTinkerServiceProvider::class, /* * Application Service Providers... */ AppProvidersAppServiceProvider::class, AppProvidersAuthServiceProvider::class, // AppProvidersBroadcastServiceProvider::class, AppProvidersEventServiceProvider::class, AppProvidersRouteServiceProvider::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.
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, theboot
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... */ IlluminateAuthAuthServiceProvider::class, IlluminateBroadcastingBroadcastServiceProvider::class, IlluminateBusBusServiceProvider::class, IlluminateCacheCacheServiceProvider::class, IlluminateFoundationProvidersConsoleSupportServiceProvider::class, IlluminateCookieCookieServiceProvider::class, IlluminateDatabaseDatabaseServiceProvider::class, IlluminateEncryptionEncryptionServiceProvider::class, IlluminateFilesystemFilesystemServiceProvider::class, IlluminateFoundationProvidersFoundationServiceProvider::class, IlluminateHashingHashServiceProvider::class, IlluminateMailMailServiceProvider::class, IlluminateNotificationsNotificationServiceProvider::class, IlluminatePaginationPaginationServiceProvider::class, IlluminatePipelinePipelineServiceProvider::class, IlluminateQueueQueueServiceProvider::class, IlluminateRedisRedisServiceProvider::class, IlluminateAuthPasswordsPasswordResetServiceProvider::class, IlluminateSessionSessionServiceProvider::class, IlluminateTranslationTranslationServiceProvider::class, IlluminateValidationValidationServiceProvider::class, IlluminateViewViewServiceProvider::class, /* * Package Service Providers... */ LaravelTinkerTinkerServiceProvider::class, /* * Application Service Providers... */ AppProvidersAppServiceProvider::class, AppProvidersAuthServiceProvider::class, // AppProvidersBroadcastServiceProvider::class, AppProvidersEventServiceProvider::class, AppProvidersRouteServiceProvider::class, AppProvidersEnvatoCustomServiceProvider::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 fileapp/Providers/EnvatoCustomServiceProvider.php
that was created earlier and replace the existing code with the following.app->bind('AppLibraryServicesDemoOne', function ($app) { return new DemoOne(); }); } }There are two important things to note here:
- We've imported
AppLibraryServicesDemoOne
so that we can use it. TheDemoOne
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 theAppLibraryServicesDemoOne
dependency needs to be resolved, it'll call the closure function, and it instantiates and returns theAppLibraryServicesDemoOne
object.
So you just need to create the app/Library/Services/DemoOne.php
file for this to work.
And here's the code somewhere in your controller where the dependency will be injected.
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
.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 inapp/Library/Services/DemoOne.php
.Similarly,
DemoTwo
goes inapp/Library/Services/DemoTwo.php
.Now, instead of binding a class, we'll bind an interface. Revisit
EnvatoCustomServiceProvider.php
and change the code as shown below.app->bind('AppLibraryServicesContractsCustomServiceInterface', function ($app) { return new DemoOne(); }); } }In this case, we've bound the
AppLibraryServicesContractsCustomServiceInterface
interface to theDemoOne
implementation. Hence, whenever theAppLibraryServicesContractsCustomServiceInterface
dependency needs to be resolved, it instantiates and returns theAppLibraryServicesDemoOne
object. Now it makes more sense, doesn't it?Let's quickly revise the controller code as well.
doSomethingUseful(); } }As you may have guessed, the
$customServiceInstance
should be the instance ofAppLibraryServicesDemoOne
! The beauty of this approach is that you can swap theDemoOne
implementation with the other one easily.Let's say you want to use the
DemoTwo
implementation instead ofDemoOne
. In that case, you just need to make the following changes in the service providerEnvatoCustomServiceProvider.php
.Find the following line:
use AppLibraryServicesDemoOne;And replace it with:
use AppLibraryServicesDemoTwo;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', 'AppHttpViewComposersDemoComposer' ); }Of course, you want to import a facade
IlluminateSupportFacadesView
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', AppUser::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!