Laravel

01The request lifecycle

Every request enters through public/index.php. Laravel boots the application (service providers register bindings and config), then passes the request through a stack of middleware, like a series of checkpoints at an airport. The router matches the URL and HTTP method to a route, which calls a controller method. The controller returns something (a model, an array, a Resource, a view), and Laravel converts it into an HTTP response that travels back out through the same middleware. In Laravel 11+ this wiring lives in bootstrap/app.php: you register routes, middleware and exception handling there instead of a separate Kernel class. Knowing this order explains most bugs: if auth fails, look at middleware; if data is wrong, look at the controller and below.

• Service provider: a class that registers things in the service container at boot.
• Service container: Laravel's dependency injection system; it builds classes and their dependencies for you.
• Middleware: code that runs before or after the controller (auth, throttling, locale, CORS).

02Routing, middleware and thin controllers

Routes map URLs to code. Group them by audience and attach middleware to the group, so every route inside inherits authentication, rate limits or a locale. Keep controllers thin: their job is to read the validated input, call a service that does the real work, and return a response. Business rules (how a price is calculated, when an order may be cancelled) belong in services or actions, and data access belongs in models. This split, controller to service to model, means you can call the same logic from an API endpoint, an Artisan command or a queued job without copying code.

1// routes/api.php
2use App\Http\Controllers\Api\OrderController;
3use Illuminate\Support\Facades\Route;
4 
5Route::middleware(['auth:sanctum', 'throttle:api'])
6    ->prefix('v1')
7    ->group(function () {
8        Route::get('orders', [OrderController::class, 'index']);
9        Route::post('orders', [OrderController::class, 'store']);
10        Route::get('orders/{order}', [OrderController::class, 'show']);
11    });

03Validation with FormRequests, output with API Resources

Validate at the edge. A FormRequest class holds the rules and the authorize() check for one action; if validation fails, Laravel returns a 422 response with field errors before your controller runs. Inside the controller, $request->validated() gives you only the fields that passed, which protects against mass assignment. On the way out, an API Resource turns a model into the exact JSON shape your clients expect. This decouples your database columns from your public contract: you can rename a column without breaking the mobile app. Resources also make conditional fields easy, such as including relations only when they were loaded.

1class StoreOrderRequest extends FormRequest
2{
3    public function authorize(): bool
4    {
5        return $this->user()->can('create', Order::class);
6    }
7 
8    public function rules(): array
9    {
10        return [
11            'items' => ['required', 'array', 'min:1'],
12            'items.*.product_id' => ['required', 'integer', 'exists:products,id'],
13            'items.*.qty' => ['required', 'integer', 'between:1,99'],
14            'note' => ['nullable', 'string', 'max:500'],
15        ];
16    }
17}

04Eloquent, relationships and eager loading

Eloquent is Laravel's ORM: each model class maps to a table, and relationships (hasMany, belongsTo, belongsToMany, morphMany) are methods on the model. The classic trap is the N+1 problem: you load 50 orders, then touch $order->customer in a loop, and Eloquent runs 50 extra queries. Eager loading with with() fetches the relation in one extra query. In development, call Model::preventLazyLoading() so lazy loads throw an exception and you catch N+1 early. Use withCount() for counts, select only the columns you need for large lists, and paginate everything a user can scroll. Laravel 13 also lets you configure many model properties with PHP attributes, but the classic properties still work.

1// AppServiceProvider::boot()
2Model::preventLazyLoading(! app()->isProduction());
3 
4// One query for orders, one for customers, one for items
5$orders = Order::query()
6    ->with(['customer:id,name', 'items.product:id,name,price'])
7    ->withCount('items')
8    ->where('status', OrderStatus::Paid)
9    ->latest()
10    ->paginate(20);
11 
12return OrderResource::collection($orders);

05Queues, the scheduler and authentication

Anything slow or unreliable (emails, SMS, payment callbacks, exports, ERP sync) goes into a queued job: the user gets a fast response and a worker process does the work in the background, with retries. The scheduler replaces a pile of cron entries with one: cron runs php artisan schedule:run every minute, and your schedule is defined in routes/console.php. For authentication, Sanctum is the default choice: cookie sessions for your own SPA on the same top-level domain, plus simple personal access tokens for mobile apps. Passport is a full OAuth2 server; choose it when third parties need OAuth flows or you already depend on its token model. Socialite adds Google, Apple and other social logins on top of either.

1// routes/console.php
2use Illuminate\Support\Facades\Schedule;
3 
4Schedule::command('subscriptions:expire')
5    ->dailyAt('02:00')
6    ->withoutOverlapping()
7    ->onOneServer();
8 
9Schedule::job(new SyncPricesFromErp)->hourly();
10 
11// crontab: * * * * * cd /var/www/app && php artisan schedule:run >> /dev/null 2>&1

06Production tips for the Laravel 13 era

Run on PHP 8.3 or newer, and use enums, readonly properties and typed signatures everywhere. On deploy, run php artisan optimize to cache config, routes, events and views, and never call env() outside config files, because cached config ignores it. Run migrations as a separate deploy step. Keep queue workers under a process manager and restart them on every deploy with php artisan queue:restart, otherwise they keep running old code. Use Telescope or Pail locally for debugging, and structured logs plus error tracking in production. Laravel 13 also ships a first-party AI SDK and JSON:API resources; adopt them when they solve a real problem, not because they are new.

• Deploy: composer install --no-dev --optimize-autoloader, migrate --force, optimize, queue:restart.
• Set APP_DEBUG=false in production; debug pages leak secrets.
• Prefer database transactions around multi-step writes, and dispatch jobs afterCommit.

07The service container, scopes and long-running workers

Classic PHP-FPM boots Laravel for every request and throws everything away afterwards, so sloppy state rarely hurts. Queue workers and Octane (FrankenPHP, Swoole or RoadRunner) boot the application once and then serve thousands of requests or jobs from the same memory. That changes the rules. A binding registered with bind() gives a fresh object every time it is resolved. singleton() gives one object for the life of the process, which is right for stateless clients such as an HTTP client for a payment gateway. scoped() gives one object per request or per job and is reset between them, which is what you want for anything holding the current user, tenant or locale. Putting request data into a singleton or a static property is the classic Octane bug: one customer briefly sees another customer's context.

1// AppServiceProvider::register()
2// Stateless client: safe to share for the whole process
3$this->app->singleton(PaymentGateway::class, fn () => new GatewayClient(
4    config('services.gateway.key'),
5));
6 
7// Holds per-request data: reset for every request and every queued job
8$this->app->scoped(CurrentTenant::class, fn () => new CurrentTenant());
9 
10// Cheap builder: a new instance on every resolve
11$this->app->bind(ReportBuilder::class);

08Eloquent on large tables: chunking, lazy collections and strict mode

Order::all() on a table with two million rows loads two million models into memory and kills the process. For batch work use chunkById(), which pages by primary key and stays correct even when you update the rows you are iterating (plain chunk() with offsets skips rows in that case). For exports, lazyById() returns a LazyCollection that streams rows with near-constant memory. Watch whereHas() on big tables: it compiles to a correlated EXISTS subquery that can be slow without the right composite index, and sometimes a join or a whereIn with a subselect is much faster. Model::shouldBeStrict() turns on three guards at once: prevent lazy loading, throw when you set an attribute that is not fillable instead of silently dropping it, and throw when you read an attribute that was not selected.

1// Backfill without loading everything
2Order::query()
3    ->where('status', OrderStatus::Paid)
4    ->whereNull('invoice_number')
5    ->chunkById(500, function ($orders) {
6        foreach ($orders as $order) {
7            GenerateInvoice::dispatch($order->id);
8        }
9    });
10 
11// Stream an export with near-constant memory
12foreach (Order::query()->select(['id', 'total', 'created_at'])->lazyById(1000) as $order) {
13    $csv->insertOne([$order->id, $order->total, $order->created_at]);
14}

09Race conditions: atomic updates, row locks and distributed locks

Two customers buy the last item at the same moment. Both requests read stock = 1, both pass the check, both decrement, and stock becomes -1. Reading, checking in PHP and then writing is never safe under concurrency. The cheapest fix is an atomic conditional update: let the database check and change in one statement, and look at the number of affected rows. When you need several reads and writes to stay consistent, use a transaction with lockForUpdate(), which holds a row lock until commit; keep such transactions short and always lock rows in the same order to avoid deadlocks. DB::transaction() accepts an attempts count and retries on deadlock. For work that spans processes, such as one ERP import at a time across servers, use Cache::lock() with a Redis or database store. A unique index remains the last line of defence.

1DB::transaction(function () use ($productId, $qty) {
2    $affected = Product::whereKey($productId)
3        ->where('stock', '>=', $qty)
4        ->decrement('stock', $qty);
5 
6    if ($affected === 0) {
7        throw new OutOfStockException($productId);
8    }
9}, attempts: 3);
10 
11// One import at a time across all servers (needs a shared cache store)
12Cache::lock('erp-import', 600)->block(5, function () {
13    app(ErpImporter::class)->run();
14});

10Hardening a Laravel API

Most Laravel security problems are configuration and habits, not framework bugs. Define named rate limiters per audience: generous for signed-in users, strict for anonymous traffic, very strict for OTP and password reset, keyed by user, phone and IP together. Scope nested route bindings with scopeBindings() so /shops/1/orders/99 fails when order 99 belongs to another shop. Use encrypted casts for sensitive columns such as tax ids or tokens, and remember that APP_KEY rotation is supported through APP_PREVIOUS_KEYS, so old values still decrypt while new ones use the new key. Use signed URLs for links in emails (unsubscribe, download) instead of inventing your own tokens. Keep Gate::before super-admin shortcuts narrow, because they bypass every policy. Finally, run composer audit in CI to catch packages with known vulnerabilities.

1// AppServiceProvider::boot()
2RateLimiter::for('api', function (Request $request) {
3    return $request->user()
4        ? Limit::perMinute(120)->by('user:'.$request->user()->id)
5        : Limit::perMinute(30)->by('ip:'.$request->ip());
6});
7 
8RateLimiter::for('otp', fn (Request $request) => [
9    Limit::perMinute(1)->by('otp-phone:'.$request->input('phone')),
10    Limit::perDay(20)->by('otp-ip:'.$request->ip()),
11]);
12 
13// routes: ->middleware('throttle:otp')