Laravel: Do you need facades?

What are facades?

Laravel comes with an internal mechanism called Facades, which provides easy access to classes that are available in the application's service container.

Check the Illuminate\Support\Facades namespace.

Such middle layer abstracts the complexity of resolving Laravel's features from the container.

As Laravel provides an extensive range of features, there are various facades.

Facades as service locators

Facades are meant to be proxies we can test "just as we would test an injected class instance".

Behind the scene, Laravel uses __callStatic for dynamic code generation.

Roughly speaking, your calls will be passed to Laravel's instances:

class Route extends Facade
{
    /**
     * Get the registered name of the component.
     *
     * @return string
     */
    protected static function getFacadeAccessor()
    {
        return 'router';
    }
}

N.B.: You can even create custom facades by extending Facade.

The technical debt: obvious pros & cons

Unfortunately, you may still introduce some flaws in your design with facades.

❌ It's easy to misuse it:

• because of the easiness, you may add too many responsibilities to your services, breaking the "Single Responsibility" principle (SRP)
• you may couple your business logic to Laravel
• because of the "magic," the code may be harder to maintain (hidden dependencies) and refactor
• debugging can be harder too
• new team members may struggle to understand how the application works (complexity vs. readability)

✅ It's best if you can limit Facade usage, for example, to generic services that are frequently used.

The hidden costs of a bad implementation

❌ Overusing facades is a long-term mistake. You may break some principles and compromise your project.

✅ Code reviews can help discuss such critical decision.

Personal thoughts

It's easy to list some drawbacks. The documentation itself recommend using facades sparingly.

I know there are some ideological concerns (like using facades would be an anti-pattern), but it seems irrelevant when you actually use the framework.

Dev teams cannot afford to reinvent everything.

You must respect principles, but reading them at face value can be bad as well.

"Breaking" them might even be judicious in very rare occasion.

Besides, repetitive (and unnecessary) dependency injection does not improve your code.

It can even lead to constructor bloat.

Wrap up

As long as you don't overuse Laravel's facades, it does a fantastic job, simplifying the syntax for straightforward dev.

Comments

[david duymelinck]

Laravel facades are plain weird. If you look at the facade pattern then you understand why.
They feel like interfaces for lazy people. But to have some code discoverability they added the methods as comments.

My advise is to use the facades Laravel provides. Otherwise use the actual class, interfaces or abstract classes. The cases depend on how loose the coupling need to be.

[spO0q]

Laravel facades are plain weird. If you look at the facade pattern then you understand why

They provide these proxies to speed up your dev, so you can call critical features almost from everywhere without messing up everything.

[david duymelinck]

Facades are meant to make it easier to interact with a subsystem, for example SplFileObject and PDO make it easier to work with files and databases.
As you mentioned they are proxies, so they should be named proxies instead.

Apart from the naming the other weird thing is that the methods are called by using __callStatic, while all the methods are not static. So why not call them by using __call. that causes less confusion.

I hope they phase out their facade classes for something like a lazyable trait.

trait lazyable {
    public static function proxy() {
       $class = static::class;
      $reflector = new ReflectionClass($class);
      return $reflector->newLazyProxy(function ($object) use ($class) {
                // some container function to check the binding and return another class instead
                return new $class();
         });
    }
}

php 8.4 introduced lazy objects, which makes it so much easier to create proxy and ghost objects.