The Facade pattern is at the core of the Laravel framework. It is used extensively by Laravel under the hood, including many of Laravel’s services such as Auth, Cache, etc. Simply put, Laravel relies on it extensively. A facade provides a convenient way to define and access a class object without directly instantiating it. When I say “without initializing,” I do not mean that the object is never created; rather, its instantiation is abstracted away from the user so that they don’t have to create the object in a conventional way (e.g., using new MyClass()). This abstraction allows on-the-fly access to an object and contributes to Laravel’s clean, simple, and even “magical” feel.

Let me start by laying out some fundamentals. In Laravel, it is possible to “resolve” anything in a Laravel service provider from any class. For example, you can bind a string to a class as follows:

PHP
$this->app->bind('strHelper', function ($app) {
    return new \Illuminate\Support\Str();
});

Now, you can resolve strHelper to an instance of \Illuminate\Support\Str() from the container by calling app('strHelper'), which returns an instance of \Illuminate\Support\Str(). This allows you to call methods such as:

PHP
app('strHelper')->length('Hello from Laravel');

Facades use a similar pattern under the hood to resolve the underlying class instance.

Let’s create a very basic example to apply what we learned above:

PHP
<?php

namespace App\Services;

class GreetService
{
    public function getGreet(): string
    {
        return 'Hello, world!';
    }
}

Now, let’s try creating a very simple facade. If you explore any facade in the Laravel framework, you’ll notice that it always contains a function called getFacadeAccessor. This function must be defined in every facade class, and it returns the key used to resolve the underlying class instance from the Laravel service container

PHP
<?php

namespace App\Facades;

use Illuminate\Support\Facades\Facade;

class Greet extends Facade
{
    protected static function getFacadeAccessor()
    {
        return 'greet';
    }
}

As we have already bound 'greet' to GreetService, Laravel will resolve its instance under the hood. But how does Laravel enable us to call the method statically?

Notice that when you call Greet::getGreet(), there is no static method getGreet defined in GreetService. So, how does the call not fail? The secret lies in PHP’s magic method __callStatic. When a static method is called on a class and it does not exist, the __callStatic method is triggered—provided it has been defined. If we take a look at the Laravel Facade class, we see something like this:

PHP
public static function __callStatic($method, $args)
{
    $instance = static::getFacadeRoot();

    if (! $instance) {
        throw new RuntimeException('A facade root has not been set.');
    }

    return $instance->$method(...$args);
}

public static function getFacadeRoot()
{
    return static::resolveFacadeInstance(static::getFacadeAccessor());
}

protected static function resolveFacadeInstance($name)
{
    if (isset(static::$resolvedInstance[$name])) {
        return static::$resolvedInstance[$name];
    }

    if (static::$app) {
        if (static::$cached) {
            return static::$resolvedInstance[$name] = static::$app[$name];
        }

        return static::$app[$name];
    }
}

When the __callStatic method is invoked, it attempts to resolve the abstract from the service container using the resolveFacadeInstance method. In our case, it would return the GreetService instance. We are mostly concerned with the following line:

PHP
return static::$app[$name];

(For now, ignore the rest of the code; it will be explained later.) This line retrieves the underlying class instance from the service container, which is then used by __callStatic to call the method non-statically:

Conclusion

The magic lies in Laravel’s service container and PHP’s __callStatic method, which allows us to call non-static methods statically. By combining these two strategies, Laravel provides a clean way to use the underlying object without needing to instantiate it every time. While this approach is powerful and is used extensively under the hood, finding the right balance in its usage is key.

Happy coding! 🚀🚀

Blog