For those who haven’t actively used Service Providers in Laravel, it’s a mystical “term”: what “service” do they actually “provide”, and how exactly does it all work? I will explain it in this article.

Default Laravel Service Providers

Let’s start with the default service providers included in Laravel, they are all in the app/Providers folder:

They are all PHP classes, each related to its topic: general “app”, Auth, Broadcasting, Events, and Routes. But they all have one thing in common: the boot() method.

Inside of that method, you can write any code related to one of those sections: auth, events, routes, etc. In other words, Service Providers are just classes to register some global functionality.

They are separated as “providers” because they are executed really early in the Application Lifecycle, so it is convenient something global here before the execution script comes to Models or Controllers.

The most amount of functionality is in the RouteServiceProvider, let’s take a look at its code:

This is the class where route files are configured, with routes/web.php and routes/api.php included by default. Notice that for the API there are also different configurations: endpoint prefix /api and middleware api for all the routes.

You can edit those Service Providers however you want, they are not in the /vendor folder. Typical customization of this file happens when you have a lot of routes and you want to separate them in your custom file. You create routes/auth.php and put the routes there, and then you “enable” that file in the boot() method of the RouteServiceProvider, just add the third sentence:

Other default service providers have other functionality, you can analyze them by yourself. Except for AppServiceProvider, it is empty, like a placeholder for us to add any code related to some global application settings.

One popular example of adding code to the AppServiceProvider is about disabling the lazy loading in Eloquent. To do that, you just need to add two lines into the boot() method:

This will throw an exception if some relationship model isn’t eager loaded, which causes a so-called N+1 query problem with performance.

When Service Providers Are Executed?

If you look at the official docs about request lifecycle, these are the things executed in the very beginning:

Which providers are loaded? It’s defined in the config/app.php array:

As you can see, there’s a list of non-public service providers from the /vendor folder, you shouldn’t touch/edit them. The ones we’re interested in are at the bottom, with BroadcastServicerProvider disabled by default, probably because it’s rarely used.

All of those service providers are executed from top to bottom, iterating that list twice.

The first iteration is looking for an optional method register() which may be used to initiate something before the boot() method. I’ve never used it in my experience.

Then, the second iteration executes the boot() method of all providers. Again, one by one, from top to bottom of the 'providers' array.

And then, after all the service providers have been processed, Laravel goes to parsing the route, executing the Controller, using Models, etc.

Create Your Custom Service Provider

In addition to the existing default files, you can easily create your service provider, related to some other topics than the default ones like auth/event/routes.

Quite a typical example is configuration related to Blade views. If you want to create your Blade directive, you can add that code into any service provider’s boot() method, including the default AppServiceProvider, but quite often developers create a separate ViewServiceProvider.

You can generate it with this command:

You may remove the register() method, and inside of boot() add Blade directive code:

Another example of a ViewServiceProvider is about View Composers, here’s the snippet from the official Laravel docs:

To be executed, this new provider should be added to the array of providers in config/app.php, as mentioned above:

Examples from Open-Source Projects

Finally, I want to mention a few examples from freely available Laravel projects.

1. spatie/freek.dev: BladeComponentServiceProvider

A well-known company Spatie has published the source code for the personal blog of Freek Van der Herten, with this file.

app/Providers/BladeComponentServiceProvider.php:

One of the most-starred Laravel open-source projects has a separate file to register Collection macros:

app/Providers/MacroServiceProvider.php:

Laravel CMS called phpReel also has a service provider for Blade components, named even longer.

app/Providers/DashboardComponentsServiceProvider.php:

You can also find a few more examples of Service Providers at my LaravelExamples.com website.