🏛️ Laravel Framework Architecture

What Laravel Is (and Isn't)

Laravel is an open-source PHP web framework created by Taylor Otwell in 2011. It follows the MVC (Model–View–Controller) pattern and pairs it with an elegant, readable syntax that prioritizes developer experience. The current version, Laravel 11, requires PHP 8.2 or higher and ships with a deliberately slim application skeleton.

A framework is not a library you call occasionally — it is scaffolding that calls your code. You place your routes, controllers, and models into the slots Laravel provides, and the framework runs the plumbing: parsing the HTTP request, matching a route, resolving dependencies, and formatting the response.

💡 A useful analogy: Building raw PHP is like assembling a house with hand tools — possible, but slow and inconsistent. Laravel is the modern job site: power tools, pre-fabricated components, and a blueprint everyone on the team already knows how to read.

Laravel's Core Philosophy

Laravel's design choices all trace back to a handful of principles. Knowing them makes the rest of the framework feel predictable rather than magical.

• Developer happiness — expressive APIs that make common tasks a single, readable line of code.
• Convention over configuration — sensible defaults (a controller in app/Http/Controllers, a model that maps to a pluralized table) so you configure only the exceptions.
• Progressive framework — trivial to start with, yet it scales to queues, broadcasting, and horizontally-scaled deployments as your app grows.
• Batteries included, swappable — routing, ORM, auth, caching, mail, and queues ship in the box, but each layer is replaceable through the container.

The Request Lifecycle

Every HTTP request that hits a Laravel app travels the same path. Understanding it is the single most useful mental model you can build — when something breaks, you will know exactly which stage to inspect.

1. Entry point. The web server sends every request to public/index.php, the one publicly exposed file. It loads Composer's autoloader and boots the application defined in bootstrap/app.php.
2. Kernel. The HTTP kernel receives the request and runs it through the global middleware stack — session handling, CSRF protection, cookie encryption, and so on.
3. Routing. The router matches the URL and HTTP verb to a route you defined in routes/web.php or routes/api.php, then dispatches to its controller action (after any route-specific middleware).
4. Controller. Your code runs: it reads input, calls models and services, and decides what to return.
5. Response. A view, JSON payload, redirect, or file travels back out through the same middleware (which can still modify it) and is sent to the browser.

<?php
// bootstrap/app.php — the Laravel 11 application definition
use Illuminate\Foundation\Application;
use Illuminate\Foundation\Configuration\Exceptions;
use Illuminate\Foundation\Configuration\Middleware;

return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(
        web: __DIR__.'/../routes/web.php',
        commands: __DIR__.'/../routes/console.php',
        health: '/up',
    )
    ->withMiddleware(function (Middleware $middleware) {
        // Register global or aliased middleware here
    })
    ->withExceptions(function (Exceptions $exceptions) {
        // Customize exception reporting/rendering here
    })->create();

The Service Container

The service container (sometimes called the IoC container) is the beating heart of Laravel. It is a registry that knows how to build your classes and automatically supplies (injects) the dependencies each one needs. You almost never call new for a service — you type-hint it, and the container hands you a fully-built instance.

💡 Analogy: Think of the container as an expert stagehand. You say "I need a payment processor," and it appears in your hands, already assembled with its API key and logger, exactly when the scene calls for it. You never build the props yourself.

Suppose you are building an e-commerce app. Instead of hardcoding Stripe everywhere, you code against an interface and bind a concrete implementation once. Swapping to a different provider later is a one-line change.

<?php
// Define the contract your app depends on
interface PaymentProcessor
{
    public function charge(int $amountInCents, string $token): string;
}

// A concrete implementation
class StripePaymentProcessor implements PaymentProcessor
{
    public function __construct(private string $apiKey) {}

    public function charge(int $amountInCents, string $token): string
    {
        // ...call the Stripe API...
        return 'ch_123'; // charge id
    }
}

<?php
// Bind the interface to an implementation (see the next section for where)
$this->app->bind(PaymentProcessor::class, function ($app) {
    return new StripePaymentProcessor(config('services.stripe.key'));
});

<?php
// Anywhere you type-hint the interface, the container resolves it for you
class CheckoutController extends Controller
{
    public function store(Request $request, PaymentProcessor $processor)
    {
        $chargeId = $processor->charge(1999, $request->input('token'));

        return response()->json(['charge' => $chargeId]);
    }
}

Service Providers

If the container is the what, service providers are the where. They are the central place where you register bindings, event listeners, and other bootstrapping. Every Laravel feature — the database, mail, queues — is booted by a provider. Your own live in app/Providers and are listed in bootstrap/providers.php.

A provider has two methods, and the distinction between them matters:

• register() — bind things into the container. Runs for all providers first. Never resolve a service here; other providers may not be booted yet.
• boot() — runs after every provider has registered. Safe to resolve services, register view composers, define gates, etc.

<?php

namespace App\Providers;

use App\Contracts\PaymentProcessor;
use App\Services\StripePaymentProcessor;
use Illuminate\Support\ServiceProvider;

class PaymentServiceProvider extends ServiceProvider
{
    // Phase 1: only register bindings here
    public function register(): void
    {
        $this->app->bind(PaymentProcessor::class, function ($app) {
            return new StripePaymentProcessor(config('services.stripe.key'));
        });
    }

    // Phase 2: everything is registered — safe to use services
    public function boot(): void
    {
        // e.g. register event listeners, publish config, define view composers
    }
}

Generate one with Artisan, and Laravel 11 registers it in bootstrap/providers.php automatically:

php artisan make:provider PaymentServiceProvider

💡 Analogy: Providers are department managers. During register() each manager sets up their own desk. Only once every desk is ready — boot() — do they start collaborating across departments. Trying to collaborate before everyone has a desk (resolving in register()) is how you get "class not found" surprises.

Facades

Facades give you a clean, static-looking syntax over objects that actually live in the container. Cache::put(...) reads like a static call, but under the hood the facade resolves the real cache service and forwards the call to it — so you keep the convenience of statics and the testability of dependency injection.

<?php
use Illuminate\Support\Facades\Cache;

// The convenient facade syntax
Cache::put('key', 'value', now()->addMinutes(60));

// What it actually does under the hood — resolve from the container, then call
app('cache')->put('key', 'value', now()->addMinutes(60));

Because the target still comes from the container, you can swap it for a fake in tests — Cache::shouldReceive('put') — something plain static methods could never allow.

💡 Analogy: A facade is the dashboard of a car. The button that says "AC" is a simple interface to a genuinely complex system behind the panel. You press one control; the container wires up the compressor, fans, and sensors for you.

Laravel vs Other PHP Frameworks

Laravel is not the only PHP framework, and choosing one is about trade-offs. Here is how the major players compare at a glance:

Interestingly, Laravel is built on top of many Symfony components (the HTTP foundation and routing internals, for example) — so it is less "Laravel vs Symfony" and more "Laravel's opinionated layer over shared foundations."

Hands-on Exercise

<?php
// app/Contracts/Greeter.php
namespace App\Contracts;

interface Greeter
{
    public function greet(string $name): string;
}

<?php
// app/Services/FriendlyGreeter.php
namespace App\Services;

use App\Contracts\Greeter;

class FriendlyGreeter implements Greeter
{
    public function greet(string $name): string
    {
        return "Welcome to Laravel, {$name}!";
    }
}

<?php
// app/Providers/AppServiceProvider.php (register method)
use App\Contracts\Greeter;
use App\Services\FriendlyGreeter;

public function register(): void
{
    $this->app->bind(Greeter::class, FriendlyGreeter::class);
}

<?php
// app/Http/Controllers/GreetingController.php
namespace App\Http\Controllers;

use App\Contracts\Greeter;

class GreetingController extends Controller
{
    public function __invoke(Greeter $greeter)
    {
        return $greeter->greet('Ray');
    }
}

<?php
// routes/web.php
use App\Http\Controllers\GreetingController;

Route::get('/greet', GreetingController::class);

Summary & Quiz

📚 Further Reading

• Laravel Docs — Request Lifecycle
• Laravel Docs — Service Container
• Laravel Docs — Service Providers
• Laravel Docs — Facades

🚀 What's Next?

Now that you understand how Laravel is wired together, the next lesson gets your hands dirty: installing Laravel 11, exploring its directory structure, configuring the environment, and running your first Artisan commands.