🏛️ Laravel Framework Architecture

What Is Laravel?

Laravel is a free, open-source PHP web framework created by Taylor Otwell in 2011. It is by a wide margin the most popular PHP framework today, valued for its expressive syntax, its "batteries-included" feature set, and a design that consistently favours convention over configuration — sensible defaults that get out of your way until you need to change them.

Think of Laravel as a well-organised professional kitchen. A home cook can make dinner with one pot and a single knife (raw PHP), but a professional kitchen gives you dedicated stations, sharp tools within reach, and a clear workflow so you spend your energy on the food, not on hunting for equipment. Laravel provides routing, an ORM, a templating engine, authentication, queues, testing tools, and more — already wired together.

💡 The framework's own promise: Laravel describes itself as a framework with "expressive, elegant syntax" whose foundation is already laid so you can build without sweating the small things. This lesson is about understanding that foundation.

This course targets a current Laravel release (Laravel 11+ on PHP 8.2 or newer). Recent versions slimmed the default skeleton considerably — for example, HTTP middleware and exception handling are now configured in bootstrap/app.php rather than a large Kernel class. We will point out these modern conventions as we go.

The MVC Pattern

Laravel is built around Model–View–Controller (MVC), an architecture that splits an application into three cooperating roles. Separating them keeps presentation, logic, and data independent, so each can change without breaking the others.

A restaurant makes the roles intuitive: the model is the kitchen and pantry (where the real work with ingredients/data happens), the view is the beautifully plated dish handed to the guest, and the controller is the waiter who takes the order, relays it to the kitchen, and brings the finished plate back.

The Request Lifecycle

Every request to a Laravel app follows the same journey. Understanding it demystifies almost every "where does this happen?" question you will ever ask.

1. Entry point. The web server sends every request to public/index.php — the single "front controller." Nothing else in your project is web-accessible.
2. Bootstrap. Laravel loads the framework, reads your configuration, and prepares the service container (next section).
3. Middleware. The request passes through layers such as CSRF protection, session handling, and authentication — each can inspect, modify, or reject it.
4. Routing. The router matches the URL and HTTP verb to a route and its handler.
5. Controller. The matched controller method runs, usually asking one or more models for data.
6. Response. The handler returns a response — a rendered view, JSON, a redirect, or a file — which travels back out through the middleware to the browser.

It resembles mail delivery: your letter (the request) passes through a series of sorting and security centres (middleware) before reaching the right desk (controller), which then posts a reply (the response) back along the same route.

Service Container & Dependency Injection

The service container (also called the IoC container) is the engine at Laravel's core. Its job is to create objects and to automatically supply the other objects they depend on — a technique called dependency injection.

Instead of a class reaching out and constructing its own dependencies, it simply declares what it needs in its constructor, and the container provides them. This keeps classes loosely coupled and dramatically easier to test.

<?php

namespace App\Http\Controllers;

use App\Repositories\UserRepository;

class UserController extends Controller
{
    // Type-hint the dependency in the constructor —
    // Laravel's container resolves and injects it automatically.
    public function __construct(
        private readonly UserRepository $users
    ) {}

    public function show(int $id)
    {
        return view('users.show', [
            'user' => $this->users->find($id),
        ]);
    }
}

Notice the modern PHP 8 constructor property promotion (private readonly UserRepository $users) — the parameter is declared and stored as a property in one step. You never write new UserRepository(); the container does it for you.

💡 Analogy: The container is a skilled assistant who knows where every tool lives. You say "I need a user repository and a logger," and they are placed in your hands — you never rummage through drawers yourself.

Directory Structure

Laravel's folder layout mirrors its architecture. Once you internalise it, you always know where to look — and where new code belongs.

app/                  # Your application code
├── Http/
│   ├── Controllers/  # Controllers
│   ├── Middleware/   # Custom middleware
│   └── Requests/     # Form request (validation) classes
├── Models/           # Eloquent models
├── Providers/        # Service providers
bootstrap/
├── app.php           # App creation + middleware/exception config (Laravel 11+)
config/               # Configuration files
database/
├── migrations/       # Schema definitions
├── seeders/          # Sample/seed data
└── factories/        # Model factories for testing
public/               # Web root — index.php + compiled assets
resources/
├── views/            # Blade templates
├── js/  css/         # Frontend source assets
routes/
├── web.php           # Web routes (sessions, CSRF)
├── console.php       # Artisan command definitions
└── api.php           # API routes (added via install:api)
storage/              # Logs, cache, compiled views, uploads
tests/                # Automated tests
vendor/               # Composer dependencies (never edited or committed)

It is like a well-run office building where every department has a known floor. You would not search for the accounting team on the loading dock — and you would not look for a controller in resources/.

Service Providers

Service providers are the central place where the framework and your app are wired together. During bootstrap, each provider gets a chance to register things into the container and then to boot — run setup once everything is registered.

<?php

namespace App\Providers;

use App\Services\PaymentGateway;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        // Bind services into the container.
        // singleton() ensures the same instance is reused everywhere.
        $this->app->singleton(PaymentGateway::class, function ($app) {
            return new PaymentGateway(config('services.payment'));
        });
    }

    public function boot(): void
    {
        // Runs after ALL providers are registered.
        // A good place to configure things that depend on other services.
    }
}

The two methods have a strict order and purpose:

• register() — only bind things into the container here. Do not assume other services exist yet.
• boot() — runs after every provider has registered, so all bindings are available. Configure views, define validation rules, register event listeners, etc.

If a Laravel app were a theatre production, service providers would be the stage crew: they set up every prop and light before the curtain rises (before a request is handled) so the performance runs without a hitch.

The Laravel Ecosystem

Laravel is more than a framework — it is a family of official packages and tools that snap together with the core. You do not need them to start, but knowing they exist tells you what problems are already solved for you.

This integrated approach is like a single manufacturer's product line: each tool is designed to work seamlessly with the core, so adopting one rarely means fighting the others.

Hands-on Exercise

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

class WelcomeController extends Controller
{
    public function index()
    {
        return view('welcome', ['name' => 'Ray']);
    }
}

<?php
// routes/web.php
use App\Http\Controllers\WelcomeController;
use Illuminate\Support\Facades\Route;

Route::get('/hi', [WelcomeController::class, 'index']);

Summary & Quiz

📚 Further Reading

• Laravel Official Documentation
• Laravel Docs — Request Lifecycle
• Laravel Docs — Service Container
• Laracasts — video tutorials

🚀 What's Next?

Now that you can trace a request through the framework, the next lesson zooms in on the two layers you will touch most often: routing and controllers — how URLs map to your code and how controllers process what arrives.