DEV Community: Marcc Atayde

Progressive Web Apps in 2025: A Production-Focused Guide to Service Workers, Caching, and the Install Experience

Marcc Atayde — Tue, 15 Sep 2026 01:00:05 +0000

There's a version of this article that starts with "PWAs are the future." This isn't that article. Instead, let's talk about what PWAs actually buy you in production — where the real complexity lives, what the spec glosses over, and how to ship something that behaves reliably across Chrome, Safari, and Firefox without losing your mind.

If you've built SPAs with Laravel backends or worked in the TALL stack, you already have most of the mental models. Service workers are just cache interceptors with a lifecycle. The manifest is just metadata. The hard part is the orchestration — and the gaps in the spec that nobody warns you about.

What a PWA Actually Is (Past the Marketing)

Strip away the buzzwords and a PWA is three things working together:

A web app manifest — JSON metadata that lets the browser offer an install prompt and controls how the app looks when installed.
A service worker — a JS script running in a separate thread that intercepts network requests and manages caches.
HTTPS — mandatory. No negotiation.

Nothing in that list requires React, a SPA, or even JavaScript-heavy architecture. A server-rendered Laravel app with Blade templates can be a perfectly valid PWA. The confusion happens when people conflate PWA capabilities with SPA patterns. They're orthogonal concerns.

The Manifest: More Than `name` and `icons`

Most tutorials show you a bare-bones manifest and move on. Here's a more complete version reflecting what you actually want in production:

{
  "name": "Field Service Tracker",
  "short_name": "FSTracker",
  "description": "Real-time job dispatch and field technician tracking.",
  "start_url": "/dashboard?source=pwa",
  "display": "standalone",
  "background_color": "#1e293b",
  "theme_color": "#3b82f6",
  "orientation": "portrait-primary",
  "icons": [
    { "src": "/icons/icon-192.png", "sizes": "192x192", "type": "image/png", "purpose": "any" },
    { "src": "/icons/icon-512.png", "sizes": "512x512", "type": "image/png", "purpose": "any" },
    { "src": "/icons/icon-maskable-512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
  ],
  "screenshots": [
    { "src": "/screenshots/desktop.png", "sizes": "1280x720", "type": "image/png", "form_factor": "wide" },
    { "src": "/screenshots/mobile.png", "sizes": "390x844", "type": "image/png", "form_factor": "narrow" }
  ],
  "categories": ["business", "productivity"],
  "shortcuts": [
    {
      "name": "New Job",
      "url": "/jobs/create?source=shortcut",
      "icons": [{ "src": "/icons/shortcut-new-job.png", "sizes": "96x96" }]
    }
  ]
}

A few things worth noting:

start_url with a query param lets you segment PWA installs in your analytics without any extra instrumentation. Filter on source=pwa and you get a clean cohort.
Maskable icons are non-optional if you want the app to look correct on Android. Without a maskable variant, the OS applies its own shape and you get white-boxed icons.
Screenshots unlock the richer install dialog in Chrome on desktop and Android — the one that shows a preview instead of just a bare install button.
Shortcuts appear on long-press of the home screen icon. For task-oriented apps, this is a meaningful UX improvement with zero runtime cost.

Service Workers: The Lifecycle Is the Hard Part

The spec describes install, activate, and fetch as the three primary events. What it undersells is the waiting state — the source of most PWA update bugs in production.

When a new service worker is detected, it installs and waits. It won't activate until all tabs running the old SW are closed. This means users can run a stale version for days on a tab they never close. The typical fix is skipWaiting, but you need to coordinate with the client:

// sw.js
self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open('app-shell-v3').then((cache) => {
      return cache.addAll([
        '/',
        '/dashboard',
        '/offline.html',
        '/css/app.css',
        '/js/app.js',
      ]);
    })
  );
});

self.addEventListener('activate', (event) => {
  const allowedCaches = ['app-shell-v3', 'api-runtime-v1'];
  event.waitUntil(
    caches.keys().then((keys) =>
      Promise.all(
        keys
          .filter((key) => !allowedCaches.includes(key))
          .map((key) => caches.delete(key))
      )
    ).then(() => self.clients.claim())
  );
});

self.addEventListener('message', (event) => {
  if (event.data?.type === 'SKIP_WAITING') {
    self.skipWaiting();
  }
});

Then on the client side, prompt the user when a new version is ready:

// In your main app JS
let newWorker;

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js').then((reg) => {
    reg.addEventListener('updatefound', () => {
      newWorker = reg.installing;
      newWorker.addEventListener('statechange', () => {
        if (newWorker.state === 'installed' && navigator.serviceWorker.controller) {
          // New version available — show a non-blocking toast
          showUpdateBanner(() => {
            newWorker.postMessage({ type: 'SKIP_WAITING' });
            window.location.reload();
          });
        }
      });
    });
  });
}

This pattern — detect, inform, let the user choose to reload — is far better UX than silently forcing a reload or leaving users stranded on stale builds.

Caching Strategies: Match the Strategy to the Resource

Don't use one strategy for everything. Here's how to think about it:

Resource Type	Strategy	Rationale
App shell (HTML, CSS, JS)	Cache-first with versioned cache names	Changes are deploy-time events, not runtime
API responses (read-heavy)	Stale-while-revalidate	Show cached data instantly, refresh in background
API responses (write operations)	Network-first	Stale data on mutations is dangerous
Images / fonts	Cache-first with long TTL	These rarely change
Offline fallback page	Cache-only (pre-cached on install)	Must be available when network fails

For the network-first with offline fallback pattern on API calls:

self.addEventListener('fetch', (event) => {
  const url = new URL(event.request.url);

  if (url.pathname.startsWith('/api/')) {
    event.respondWith(
      fetch(event.request)
        .then((response) => {
          // Clone before consuming
          const clone = response.clone();
          caches.open('api-runtime-v1').then((cache) => {
            cache.put(event.request, clone);
          });
          return response;
        })
        .catch(() =>
          caches.match(event.request).then(
            (cached) => cached || caches.match('/offline.html')
          )
        )
    );
    return;
  }

  // Cache-first for everything else
  event.respondWith(
    caches.match(event.request).then(
      (cached) => cached || fetch(event.request)
    )
  );
});

Background Sync for Offline Write Operations

The scenario: a field technician submits a job update with no signal. The naive approach loses the data. Background Sync queues the request and replays it when connectivity returns:

// On form submission
async function submitJobUpdate(data) {
  try {
    await fetch('/api/jobs', { method: 'POST', body: JSON.stringify(data) });
  } catch {
    // Store in IndexedDB
    await saveToQueue('job-updates', data);
    const reg = await navigator.serviceWorker.ready;
    await reg.sync.register('sync-job-updates');
  }
}

// In sw.js
self.addEventListener('sync', (event) => {
  if (event.tag === 'sync-job-updates') {
    event.waitUntil(flushJobUpdateQueue());
  }
});

Browser support for Background Sync is still Chrome/Edge-only as of 2025. Safari supports the Periodic Background Sync spec differently. Plan your offline strategy accordingly and use it as progressive enhancement, not a hard dependency.

Safari: The Reality Check

Safari's PWA support has improved meaningfully since 2023, but gaps remain. Push notifications on iOS require the user to install the PWA first, and only work from the home screen — not the browser. The install prompt API (BeforeInstallPromptEvent) doesn't exist in Safari; you have to build your own "Add to Home Screen" instruction UI and detect the platform yourself:

const isIos = /iphone|ipad|ipod/i.test(navigator.userAgent);
const isInStandaloneMode = window.matchMedia('(display-mode: standalone)').matches;

if (isIos && !isInStandaloneMode) {
  showIosInstallInstructions(); // Your custom UI
}

This is the kind of implementation detail that separates a production PWA from a tutorial demo. Teams at hanzweb.ae working on cross-platform business apps spend a meaningful chunk of QA time on Safari edge cases alone — the spec says one thing, the browser does another, and the user experience depends on you catching the gap.

Testing Your Service Worker

Chrome DevTools → Application → Service Workers is your primary tool, but don't skip these:

Lighthouse PWA audit — catches manifest issues and SW registration failures
Simulate offline in DevTools → Network → Offline, then navigate around
Test the update flow explicitly — modify your SW, reload, confirm the waiting state appears, then trigger skip-waiting
Test on a real device — Android Chrome and iOS Safari behave differently than desktop DevTools emulation

Conclusion

PWAs earn their complexity when your users have intermittent connectivity, when you need app-store-like discoverability without the friction of a native submission process, or when a native app isn't justified by budget but installed-app UX is genuinely required. They're not a silver bullet — a poorly implemented service worker will make your app slower and harder to debug than a plain website.

The takeaway: invest time in the caching strategy and the update lifecycle. Get those two things right and everything else is configuration. Get them wrong and you're shipping a cache poisoning bug to every user who ever visited your site.

Build the manifest thoughtfully. Handle the waiting state. Match your cache strategy to the resource type. Test on real devices. That's the whole game.

Migrating Legacy Websites to Modern Laravel: A Practical, Battle-Tested Guide

Marcc Atayde — Tue, 08 Sep 2026 01:00:08 +0000

There's a particular kind of dread that hits when you open a legacy codebase for the first time. Global variables flying around, mysql_query() calls buried three functions deep, a functions.php that's 4,000 lines long, and zero tests. Yet the business depends on it. Customers are using it. And now you've been asked to modernise it.

Migrating a legacy site to Laravel isn't just a technical exercise — it's a translation job between two very different philosophies. This guide walks through a structured approach that lets you migrate incrementally, keep the existing system running, and avoid the classic trap of the never-ending rewrite.

Why Incremental Migration Beats the Big Bang Rewrite

The temptation is to freeze feature work, rewrite everything from scratch, and launch a brand-new system six months later. This almost never works. Requirements drift, the old system acquires patches the new one doesn't have, and teams lose momentum.

A strangler fig pattern — wrapping the new system around the old one, routing traffic piece by piece — is almost always the right call. Laravel is well-suited to this because its routing, middleware, and service container can coexist with legacy code running on the same server.

Step 1: Audit Before You Touch Anything

Before writing a single line of Laravel, map the existing system:

Entry points: Which files does the webserver actually serve? Often legacy PHP apps have dozens of index.php files in subdirectories.
Database schema: Export a full ERD. Tools like SchemaSpy or even just SHOW CREATE TABLE exports are your friends.
External dependencies: Payment gateways, SMTP config, third-party APIs — document every outbound connection.
Session and auth model: Is auth session-based? Cookie-based? Custom token table?

Document this ruthlessly. You'll refer back to it constantly.

Step 2: Stand Up Laravel Alongside the Legacy App

Install a fresh Laravel application in a sibling directory. Configure your web server (nginx is easiest here) to proxy requests to either the legacy app or Laravel based on URL prefix.

server {
    listen 80;
    server_name example.com;

    # New Laravel routes
    location /account {
        proxy_pass http://127.0.0.1:8001;
    }

    location /api {
        proxy_pass http://127.0.0.1:8001;
    }

    # Everything else goes to the legacy app
    location / {
        root /var/www/legacy;
        index index.php;
        fastcgi_pass unix:/run/php/php7.4-fpm.sock;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Laravel runs on PHP 8.x on port 8001 via a separate FPM pool. The legacy app continues to handle everything else untouched.

Step 3: Shared Session State

The single hardest problem in this migration pattern is auth. Users logged into the legacy system shouldn't be asked to log in again when Laravel handles a request.

The pragmatic solution: share the session backend. If the legacy app uses PHP file sessions, Laravel can read those too — but it's messy. Better to migrate the legacy app to use a database or Redis session store first, then configure Laravel to use the same store.

// config/session.php in Laravel
'driver' => 'redis',
'connection' => 'default',
'cookie' => 'legacy_session', // must match the legacy app's cookie name

On the legacy side, use a custom session handler that writes to Redis with the same key format. PhpRedis or Predis works fine here. This buys you true single-sign-on between the old and new systems without a full auth migration upfront.

Step 4: Wrap the Legacy Database in Eloquent Models

Don't rename tables. Don't normalise the schema yet. Just point Eloquent at what's already there.

class LegacyUser extends Model
{
    protected $table = 'tbl_users'; // old naming convention
    protected $primaryKey = 'user_id';
    public $timestamps = false; // no created_at/updated_at columns

    protected $casts = [
        'is_active' => 'boolean',
        'created' => 'datetime', // maps the legacy column name
    ];

    public function getCreatedAtAttribute()
    {
        return $this->attributes['created'] ?? null;
    }
}

This gives you the full power of Eloquent — relationships, scopes, query builder — without touching the database. Schema refactoring comes later, after you've proven the migration works.

Step 5: Migrate Routes Module by Module

Pick the least risky, most self-contained module first. Admin dashboards, reporting pages, or internal tools are ideal. Avoid payment flows and the core checkout until you've built confidence.

For each module:

Reproduce the functionality in a Laravel controller and Blade view (or Livewire component).
Write feature tests that cover the happy path and the edge cases you found in the audit.
Update the nginx config to proxy that URL prefix to Laravel.
Monitor error logs for 48–72 hours before moving to the next module.

// Example feature test to lock in behaviour before refactoring
public function test_order_history_displays_for_authenticated_user(): void
{
    $user = LegacyUser::factory()->create();
    $orders = LegacyOrder::factory()->count(3)->for($user)->create();

    $response = $this->actingAs($user)->get('/account/orders');

    $response->assertOk();
    $response->assertSee($orders->first()->order_ref);
}

Tests written against the legacy behaviour become the safety net for every subsequent refactor.

Step 6: Schema Migration — When You're Ready

Once a module is fully running on Laravel and tested, you can consider schema normalisation. Use Laravel migrations with Schema::table() to add columns, rename things, and introduce proper indexes — but do it additively at first. Keep the old column, write to both, verify data integrity, then drop the old column in a later migration.

Schema::table('tbl_users', function (Blueprint $table) {
    $table->string('email')->nullable()->after('user_email');
    $table->index('email');
});

// Backfill in a job, not in the migration itself
LegacyUser::whereNull('email')->eachById(function ($user) {
    $user->update(['email' => $user->user_email]);
});

Never backfill large datasets in a migration. It locks the table and causes downtime.

Step 7: The Final Cutover

When all routes are handled by Laravel and the legacy entry points are dead code, you're ready to cut over fully. At this point:

Rename or archive the legacy directory.
Update nginx to point the root location directly at Laravel's public/ folder.
Remove the legacy FPM pool.
Run php artisan route:cache, config:cache, and view:cache in production.

Keep the legacy codebase archived for at least 90 days. You will want to reference it.

Hard-Won Opinions From Production

A few things learned from doing this on real client projects — including migrations handled through work at hanzweb.ae — that don't get mentioned in tutorials:

Don't let perfect be the enemy of shipped. Ugly Eloquent models that mirror a messy schema are fine. Clean them up once the system is stable.
The legacy app will have undocumented business logic. Read the old code before deleting it. Every mysterious if statement has a story.
Logging is your best diagnostic tool. Add structured logging via Monolog from day one. You'll thank yourself when something breaks in production at 2am.
Communicate with stakeholders about the strangler fig timeline. Migrations of this kind take months, not weeks. Set that expectation early.

Conclusion

Legacy migrations succeed when they're treated as a series of small, verifiable steps rather than a single heroic rewrite. The strangler fig pattern, shared sessions, Eloquent wrappers over existing tables, and feature tests written against legacy behaviour — these aren't glamorous techniques, but they're the ones that actually ship.

The end state is worth the effort: a codebase you can reason about, test confidently, and hand off to another developer without writing a 40-page onboarding document.

Site Speed and Search Rankings: Real Benchmarks, Core Web Vitals, and the Code Changes That Actually Move the Needle

Marcc Atayde — Mon, 31 Aug 2026 01:00:09 +0000

Google has been saying speed matters since 2010. Most developers nodded along and moved on. Then Core Web Vitals landed as confirmed ranking signals in 2021, and suddenly the conversation got a lot more specific — and a lot more urgent.

The problem is that most speed advice on the internet is either too surface-level ("enable caching!") or too abstract ("improve your LCP!") to be actionable. This article is neither. We're going deep on what the benchmarks actually mean, where sites lose rankings in practice, and what code-level changes produce real improvements.

Why Speed Is a Ranking Signal Worth Taking Seriously

Google's Page Experience documentation is clear: Core Web Vitals are used as a tiebreaker when content quality is roughly equal between two competing pages. That sounds minor until you realise how competitive most SERPs actually are. In practice, a well-optimised page with a 90+ PageSpeed score can outrank a slightly better-written page that loads in 6 seconds — and the gap widens on mobile.

The three signals that matter right now:

LCP (Largest Contentful Paint): How long until the main content element is visible. Target: under 2.5 seconds.
INP (Interaction to Next Paint): Replaced FID in March 2024. Measures responsiveness across all interactions, not just the first. Target: under 200ms.
CLS (Cumulative Layout Shift): Visual stability. Target: under 0.1.

LCP is the one most sites fail on. It's usually an image, a hero block, or a server-rendered heading — and it's almost always fixable.

Diagnosing Real Problems: Beyond Lighthouse Scores

Lighthouse is a lab tool. It simulates a single page load under controlled conditions. Real users are on throttled connections, low-end Android devices, and cold caches. The gap between your Lighthouse 95 and your actual field data in Google Search Console can be humbling.

Always cross-reference:

CrUX data in Search Console — this is the field data Google actually uses for ranking.
WebPageTest with a real device profile — run a Moto G Power test from a geographically relevant server.
performance.getEntriesByType('navigation') — instrument your own users in production.

// Drop this in your app's JS to capture real navigation timing
window.addEventListener('load', () => {
  const [nav] = performance.getEntriesByType('navigation');
  console.table({
    ttfb: nav.responseStart - nav.requestStart,
    domInteractive: nav.domInteractive,
    domComplete: nav.domComplete,
    loadEvent: nav.loadEventEnd - nav.loadEventStart,
  });
});

Once you're looking at field data, the usual suspects for LCP failures become obvious: unoptimised hero images, render-blocking scripts, and slow TTFB from the origin server.

Fixing LCP: The Image Pipeline

The single highest-ROI fix for most sites is image delivery. Here's what production-ready image handling looks like in a Laravel application:

// config/image.php — using Spatie's Laravel Image Optimizer
// Composer: spatie/laravel-image-optimizer

// In your Blade component for hero images

<!-- Use native lazy loading for below-fold images, but NEVER on LCP elements -->
<img
  src="{{ $heroImage->getUrl('webp') }}"
  srcset="
    {{ $heroImage->getUrl('sm') }} 640w,
    {{ $heroImage->getUrl('md') }} 1024w,
    {{ $heroImage->getUrl('lg') }} 1920w
  "
  sizes="(max-width: 640px) 100vw, (max-width: 1024px) 100vw, 1920px"
  fetchpriority="high"
  decoding="async"
  alt="{{ $alt }}"
/>

The fetchpriority="high" attribute is often missed. It tells the browser to prioritise this resource in the preload scanner, which can shave 300–800ms off LCP on images that are in the initial viewport.

For WebP conversion at upload time with Livewire:

// In your Livewire component
public function save()
{
    $this->validate(['photo' => 'required|image|max:5120']);

    $path = $this->photo->store('uploads', 'public');

    // Convert to WebP immediately
    $image = Image::load(storage_path('app/public/' . $path))
        ->format(ImageFormat::Webp)
        ->quality(82)
        ->save();

    // Store the WebP path, not the original
    $this->model->update(['image_path' => $path]);
}

Quality 82 is a production-tested sweet spot. Below 75 and compression artifacts become noticeable; above 85 and file sizes bloat without perceptible quality gain.

TTFB: The Server-Side Problem Nobody Wants to Fix

Time to First Byte is the foundation everything else builds on. A 2-second TTFB means your LCP can never be under 2 seconds, no matter how optimised your frontend is.

For Laravel apps, TTFB problems are usually one of three things:

1. Uncached database queries on the critical path

// Bad: this runs on every page load
$categories = Category::with('children')->get();

// Better: cache it with a tagged key so you can invalidate precisely
$categories = Cache::tags(['categories'])->remember('nav-categories', 3600, function () {
    return Category::with('children')->get();
});

2. Missing opcode cache configuration

Check that opcache.validate_timestamps is 0 in production. On shared hosting, developers often forget this setting is controlled by the host and defaults to timestamp validation on every request.

3. No full-page caching for anonymous users

For marketing pages that don't change per-user, spatie/laravel-responsecache can drop your TTFB from 400ms to under 20ms:

// In your middleware, exclude authenticated routes
public function handle(Request $request, Closure $next)
{
    if (auth()->check()) {
        return $this->addDoNotCacheHeaders($next($request));
    }

    return $next($request);
}

Fixing INP: JavaScript Execution Budget

INP failures are almost always caused by long tasks blocking the main thread. The browser's task scheduler doesn't care about your business logic — if a task runs for more than 50ms, it's considered "long" and will delay the next interaction response.

The fix is yielding back to the browser between chunks of work:

// Instead of processing a large array synchronously
function processItems(items) {
  items.forEach(item => heavyOperation(item));
}

// Yield between chunks using scheduler.yield() (or setTimeout fallback)
async function processItemsYielded(items) {
  const CHUNK_SIZE = 50;

  for (let i = 0; i < items.length; i += CHUNK_SIZE) {
    const chunk = items.slice(i, i + CHUNK_SIZE);
    chunk.forEach(item => heavyOperation(item));

    // Yield to the browser — allows pending interactions to fire
    if (i + CHUNK_SIZE < items.length) {
      await new Promise(resolve => setTimeout(resolve, 0));
    }
  }
}

For Alpine.js-heavy interfaces, be careful with x-on:click handlers that trigger multiple reactive updates. Each update can trigger a repaint. Batch your state changes where possible.

CLS: The Invisible UX Killer

Layout shift is usually caused by images without explicit dimensions, late-loading fonts, or dynamically injected banners. The fix is almost always the same: reserve space before content loads.

<!-- Always declare width and height on images — browser uses aspect-ratio internally -->
<img src="product.webp" width="800" height="600" alt="Product" />

<!-- For dynamic content blocks, use min-height to reserve space -->
<div class="min-h-[120px]" x-data="{ loaded: false }">
  <div x-show="loaded" x-transition>
    <!-- Dynamic content -->
  </div>
</div>

For font-related CLS, font-display: optional is the nuclear option — it prevents the browser from swapping fonts after the page has painted. Combined with preloading your primary font, it eliminates font-related shift entirely.

Putting It Together: A Prioritisation Framework

Most teams have limited time. Here's the order of operations based on what moves CrUX scores fastest in practice:

Fix TTFB first. Everything downstream improves when the server responds faster.
Audit your LCP element. Use DevTools' Performance panel to identify it, then apply fetchpriority="high" and confirm it's not lazy-loaded.
Convert images to WebP and add explicit dimensions.
Defer non-critical scripts. Third-party analytics, chat widgets, and A/B testing libraries are often the worst offenders.
Profile for long tasks. Chrome's Performance Insights panel flags them directly.

Clients at our agency — including several that came to us after being burned by slow, off-the-shelf implementations — often find the most impactful work happens at steps 1 and 2. If you're looking to hand this off to a team that thinks about these tradeoffs daily, working with the best web development company in Dubai means getting a build that's performance-optimised from the architecture up, not patched after the fact.

Conclusion

Core Web Vitals aren't a checkbox — they're a reflection of how your application actually behaves for real users on real devices. The benchmarks are specific enough that you can measure precisely what's broken and fix it methodically. Start with TTFB, work forward through LCP, then close out INP and CLS. Each fix compounds.

The developers who win at this aren't the ones who chase Lighthouse scores in incognito mode. They're the ones who instrument their production traffic, read their CrUX data, and treat performance as a feature — not a finishing step.

Laravel Livewire Wire:Model Deep Dive: Reactivity, Debouncing, and Lazy Binding Explained

Marcc Atayde — Tue, 18 Aug 2026 01:00:09 +0000

If you've been using Livewire for a while, you've almost certainly typed wire:model without thinking too hard about it. It works — data flows between your component and the DOM, and life is good. But once your apps grow, you start noticing things: inputs that feel sluggish, forms triggering unnecessary server round-trips, and components re-rendering when they really shouldn't.

This article goes deeper than the basics. We'll dissect how wire:model actually works under the hood, explore the full suite of modifiers (lazy, debounce, defer, live), and look at when each one should be your weapon of choice. By the end, you'll write Livewire bindings that are both reactive and efficient.

How `wire:model` Actually Works

At its core, wire:model is a two-way data binding directive. When a user types into an input, Livewire intercepts the DOM event, serializes the component's state, sends it to the server, re-renders the relevant parts of the component, and patches the DOM. That's a full HTTP request for every keystroke — by default.

This is called live binding, and it's the default in Livewire 3:

<input type="text" wire:model="search" />

Every input event fires a network request. For a search field with no debouncing, this means a request per character. Fine for prototyping, painful at scale.

The Modifier Toolkit

`wire:model.live` — Explicit Real-Time Binding

In Livewire 3, wire:model alone no longer triggers live updates by default. You need .live to replicate the old behavior explicitly:

<input type="text" wire:model.live="search" />

This is intentional. The Livewire team made the default lazy to avoid unnecessary requests, pushing developers toward more deliberate binding choices.

`wire:model.lazy` — Update on Blur

Use .lazy when you don't need the server to react until the user leaves the field:

<input type="text" wire:model.lazy="email" />

This binds to the change event rather than input, so the server only gets updated when focus leaves the element. Perfect for form fields like email addresses, where you validate on completion, not on every keystroke.

`wire:model.debounce` — Throttle Live Updates

Debouncing is the sweet spot for search inputs. Instead of sending a request per keypress, you wait until the user pauses:

<input type="text" wire:model.live.debounce.500ms="search" />

This chains .live (to enable real-time updates) with .debounce.500ms (to wait 500 milliseconds after the last keystroke before firing). The result is a responsive search field that doesn't hammer your server.

Here's a practical live-search component that puts it together:

<?php

namespace App\Livewire;

use Livewire\Component;
use App\Models\Product;

class ProductSearch extends Component
{
    public string $search = '';

    public function render()
    {
        $products = Product::query()
            ->when($this->search, fn($q) =>
                $q->where('name', 'like', "%{$this->search}%")
            )
            ->limit(10)
            ->get();

        return view('livewire.product-search', compact('products'));
    }
}

<div>
    <input
        type="text"
        wire:model.live.debounce.400ms="search"
        placeholder="Search products..."
        class="w-full border rounded px-4 py-2"
    />

    <ul class="mt-4 space-y-2">
        @foreach ($products as $product)
            <li class="p-2 border rounded">{{ $product->name }}</li>
        @endforeach
    </ul>
</div>

Clean, efficient, and no WebSocket configuration required.

`wire:model.defer` — Batch Updates on Form Submit

.defer holds the updated value client-side and only syncs it to the server when an action is triggered — typically a form submission:

<form wire:submit="save">
    <input type="text" wire:model.defer="title" />
    <textarea wire:model.defer="body"></textarea>
    <button type="submit">Save Post</button>
</form>

This is the most network-efficient option. All deferred values are batched into the action request rather than each triggering its own round-trip. For long forms, this can reduce server calls from dozens to one.

Choosing the Right Modifier

Here's a quick decision guide:

Use Case	Recommended Modifier
Search input with live results	`wire:model.live.debounce.400ms`
Email / username with validation	`wire:model.lazy`
Multi-field form with submit	`wire:model.defer`
Toggle / checkbox reacting immediately	`wire:model.live`
Character counter updating in real-time	`wire:model.live.debounce.200ms`

Nested Object Binding

Livewire supports binding to nested arrays and objects, which is useful for form objects:

public array $form = [
    'name' => '',
    'email' => '',
];

<input type="text" wire:model.defer="form.name" />
<input type="email" wire:model.defer="form.email" />

Or better yet, use Livewire's Form object pattern (introduced in Livewire 3) for validation encapsulation:

namespace App\Livewire\Forms;

use Livewire\Attributes\Rule;
use Livewire\Form;

class ContactForm extends Form
{
    #[Rule('required|min:2')]
    public string $name = '';

    #[Rule('required|email')]
    public string $email = '';
}

// In your component
public ContactForm $form;

public function submit()
{
    $this->form->validate();
    // process...
}

This keeps validation rules co-located with the data, making complex forms much easier to manage.

Debugging Wire:Model Issues

When bindings behave unexpectedly, check these common causes:

1. Missing public property initialization
Livewire can't bind to a property that doesn't exist or isn't public. Always initialize:

public string $search = ''; // ✅
private string $search = ''; // ❌ won't bind

2. Modifier conflicts
Don't combine .lazy and .live — they're mutually exclusive binding strategies. Pick one.

3. Alpine.js conflicts
If you're also using Alpine x-model on the same element, the two can conflict. Use wire:model for server state and Alpine x-model for purely local UI state on separate elements.

Real-World Context: Why This Matters at Scale

The difference between a debounced search and a naive wire:model.live binding doesn't matter on localhost. It absolutely matters when you have hundreds of concurrent users. A simple 400ms debounce on a search field can cut server requests by 80% or more under real load.

This kind of deliberate, performance-aware Livewire development is something teams building production TALL stack applications — whether SaaS products, e-commerce platforms, or enterprise tools — need to get right from the start. At hanzweb.ae, working across a range of Laravel projects in the region, these optimizations consistently come up as the difference between a sluggish prototype and a smooth production app.

Conclusion

wire:model is deceptively simple on the surface but has a lot of nuance once you factor in network efficiency and user experience. The core takeaway: default to .defer for forms, .lazy for single-field validation, and .live.debounce for anything search-like. Reach for plain .live only when you genuinely need immediate server reactivity.

Understanding which binding strategy fits which context is what separates Livewire components that scale from ones that don't. Now go audit your existing components — there's a good chance a few of them are doing more round-trips than they need to.

Laravel API Security in Depth: Sanctum Tokens, Granular Rate Limiting, and Multi-Version Routing

Marcc Atayde — Tue, 11 Aug 2026 01:00:05 +0000

You've built the endpoints, wired up the controllers, and the happy path works. Then someone hammers your API with 10,000 requests in a minute, a client ships a breaking change to mobile users on v1, and a rogue token gives third-party access to everything it shouldn't. This is where most "RESTful API" tutorials stop — and where real API design begins.

This article goes beyond the basics. We'll cover Laravel Sanctum token scopes, building genuinely useful rate limiting that doesn't punish legitimate users, and a versioning strategy that scales without turning your routes file into spaghetti.

Authentication with Laravel Sanctum: Scopes and Token Abilities

Sanctum is the right tool for most Laravel APIs — it's lightweight, integrates with your existing users table, and supports both SPA cookie auth and token-based auth. But most implementations ignore token abilities entirely.

Creating Tokens with Abilities

// Issue a token with specific abilities
$token = $user->createToken('mobile-app', ['products:read', 'orders:create']);

return response()->json([
    'token' => $token->plainTextToken,
]);

Checking Abilities in Controllers

public function store(Request $request)
{
    if (!$request->user()->tokenCan('orders:create')) {
        abort(403, 'Token lacks required ability: orders:create');
    }

    // proceed with order creation
}

Or use a dedicated middleware approach with a reusable ability check:

// app/Http/Middleware/RequireTokenAbility.php
public function handle(Request $request, Closure $next, string $ability): Response
{
    if (!$request->user()?->tokenCan($ability)) {
        return response()->json(['message' => 'Insufficient token permissions.'], 403);
    }

    return $next($request);
}

->withMiddleware(function (Middleware $middleware) {
    $middleware->alias([
        'token.ability' => RequireTokenAbility::class,
    ]);
})

Now your routes self-document their permission requirements:

Route::post('/orders', [OrderController::class, 'store'])
    ->middleware('token.ability:orders:create');

Granular Rate Limiting That Actually Makes Sense

The default throttle:60,1 is a blunt instrument. A read-heavy dashboard client and a bulk import tool have very different legitimacy profiles. Laravel's RateLimiter facade lets you build context-aware limits.

Defining Named Limiters

In AppServiceProvider::boot() (or a dedicated RateLimitServiceProvider):

use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiter;

RateLimiter::for('api', function (Request $request) {
    return $request->user()
        ? Limit::perMinute(120)->by($request->user()->id)
        : Limit::perMinute(20)->by($request->ip());
});

RateLimiter::for('exports', function (Request $request) {
    return [
        Limit::perMinute(5)->by($request->user()->id),
        Limit::perDay(50)->by($request->user()->id),
    ];
});

RateLimiter::for('auth', function (Request $request) {
    return Limit::perMinute(10)->by($request->ip())
        ->response(function () {
            return response()->json([
                'message' => 'Too many login attempts. Try again in a moment.'
            ], 429);
        });
});

Applying Limiters to Route Groups

Route::middleware(['auth:sanctum', 'throttle:api'])->group(function () {
    Route::get('/products', [ProductController::class, 'index']);
    Route::get('/orders', [OrderController::class, 'index']);
});

Route::middleware(['auth:sanctum', 'throttle:exports'])->group(function () {
    Route::get('/orders/export', [ExportController::class, 'orders']);
});

Route::middleware('throttle:auth')->group(function () {
    Route::post('/login', [AuthController::class, 'login']);
});

The X-RateLimit-Limit, X-RateLimit-Remaining, and Retry-After headers are automatically injected by Laravel's throttle middleware — make sure your API clients are reading and respecting them.

API Versioning Without the Chaos

Versioning is one of those things that feels over-engineered until you ship a breaking change and break three client apps at once. There are two dominant patterns in Laravel: URL prefix versioning and header-based versioning. URL prefixing wins on debuggability — you can see the version in logs, browser tabs, and Postman without extra config.

Folder and Namespace Structure

app/Http/Controllers/
├── Api/
│   ├── V1/
│   │   ├── ProductController.php
│   │   └── OrderController.php
│   └── V2/
│       ├── ProductController.php
│       └── OrderController.php

Route Files

// routes/api.php
use App\Http\Controllers\Api;

Route::prefix('v1')->name('api.v1.')->group(function () {
    Route::apiResource('products', Api\V1\ProductController::class);
    Route::apiResource('orders', Api\V1\OrderController::class);
});

Route::prefix('v2')->name('api.v2.')->group(function () {
    Route::apiResource('products', Api\V2\ProductController::class);
    Route::apiResource('orders', Api\V2\OrderController::class);
});

Sharing Logic Between Versions with Base Controllers

Don't duplicate code — extend a versioned base from a shared abstract:

// app/Http/Controllers/Api/BaseProductController.php
abstract class BaseProductController extends Controller
{
    protected function formatProduct(Product $product): array
    {
        return [
            'id'    => $product->id,
            'name'  => $product->name,
            'price' => $product->price,
        ];
    }
}

// app/Http/Controllers/Api/V2/ProductController.php
class ProductController extends BaseProductController
{
    public function index()
    {
        return ProductResource::collection(
            Product::with('category')->paginate()
        );
    }
}

V2 adds category data and pagination; V1 keeps the original flat response. Both extend the same base — changes to shared logic propagate correctly.

API Resources: Your Contract with Consumers

Never return Eloquent models directly from an API. JsonResource classes act as a transformation and documentation layer:

// app/Http/Resources/V2/ProductResource.php
public function toArray(Request $request): array
{
    return [
        'id'         => $this->id,
        'name'       => $this->name,
        'price'      => number_format($this->price, 2),
        'currency'   => 'AED',
        'category'   => new CategoryResource($this->whenLoaded('category')),
        'created_at' => $this->created_at->toIso8601String(),
    ];
}

The whenLoaded() helper prevents N+1 and avoids over-fetching — the field only appears if the relationship was eager-loaded.

Practical Considerations for Production

Token rotation: Set token expiry and build a /auth/refresh endpoint. Long-lived tokens are a liability.

Structured error responses: Be consistent. Pick a shape and stick to it:

{
  "message": "Validation failed.",
  "errors": {
    "email": ["The email field is required."]
  }
}

Deprecation headers: When you ship v3, start sending Deprecation: true and Sunset: Sat, 01 Jan 2026 00:00:00 GMT headers on v1 responses. Clients that read headers will catch it early.

Logging: Attach the authenticated user ID and token ID to your log context inside a middleware so every log line is traceable:

Logger::withContext([
    'user_id'  => $request->user()?->id,
    'token_id' => $request->user()?->currentAccessToken()?->id,
]);

A colleague who works as a Dubai web developer once pointed out that the most expensive API bugs in client projects were never about logic — they were about missing authentication checks on a single route, a rate limiter that only applied to half the endpoints, and a versioning strategy that was never enforced. The infrastructure around your business logic matters as much as the logic itself.

Conclusion

Building a reliable Laravel API means thinking in layers: authentication that's granular enough to limit blast radius when a token leaks, rate limiting that's smart enough to distinguish users from bots, and versioning that lets you ship breaking changes without breaking anyone. Each of these is independently simple — the craft is in wiring them together consistently from day one rather than retrofitting them after your first incident.

Start with Sanctum abilities even if you don't need them yet. Define named rate limiters from day one. Create the V1 namespace before you have a V2. Future you will be grateful.

Building Intelligent Chatbots with RAG and Vector Databases: A Developer's Practical Guide

Marcc Atayde — Tue, 28 Jul 2026 01:00:07 +0000

Most chatbots are broken in a predictable way. You ask something slightly outside their training data, and they either hallucinate confidently or give you a useless "I don't know." The problem isn't the language model — it's the architecture. Retrieval-Augmented Generation (RAG) fixes this by grounding your chatbot in real, up-to-date knowledge rather than relying purely on what the model memorized during training.

In this guide, we'll build an intelligent chatbot using RAG, a vector database, and Laravel as the backend. By the end, you'll understand the full pipeline: from chunking documents and generating embeddings, to querying a vector store and feeding retrieved context into an LLM response.

What Is RAG and Why Does It Matter?

RAG stands for Retrieval-Augmented Generation. Instead of asking a language model to answer purely from memory, you first retrieve relevant documents from a knowledge base, then pass those documents as context to the model alongside the user's question.

The result: answers that are accurate, grounded in your own data, and far less likely to hallucinate.

The pipeline looks like this:

Ingest — Load documents, chunk them, generate embeddings, store in a vector database
Query — Embed the user's question, run a similarity search against your vector store
Generate — Feed retrieved chunks + question into an LLM, return the response

Setting Up the Stack

For this guide we'll use:

Laravel as the application backend
OpenAI for embeddings (text-embedding-3-small) and chat completions (gpt-4o)
Qdrant as the vector database (self-hosted or cloud)
openai-php/laravel client package

composer require openai-php/laravel
php artisan vendor:publish --provider="OpenAI\Laravel\ServiceProvider"

Add your key to .env:

OPENAI_API_KEY=sk-...
QDRANT_URL=http://localhost:6333
QDRANT_COLLECTION=knowledge_base

Step 1: Ingesting and Chunking Documents

The quality of your RAG system lives or dies by how well you chunk your documents. Chunks that are too large lose precision; too small and you lose context. A sliding window of ~500 tokens with ~50-token overlap tends to work well in practice.

// app/Services/DocumentIngestionService.php

namespace App\Services;

use OpenAI\Laravel\Facades\OpenAI;
use Illuminate\Support\Collection;

class DocumentIngestionService
{
    public function chunkText(string $text, int $chunkSize = 500, int $overlap = 50): array
    {
        $words = explode(' ', $text);
        $chunks = [];
        $start = 0;

        while ($start < count($words)) {
            $chunk = array_slice($words, $start, $chunkSize);
            $chunks[] = implode(' ', $chunk);
            $start += ($chunkSize - $overlap);
        }

        return $chunks;
    }

    public function embedChunks(array $chunks): Collection
    {
        return collect($chunks)->map(function (string $chunk) {
            $response = OpenAI::embeddings()->create([
                'model' => 'text-embedding-3-small',
                'input' => $chunk,
            ]);

            return [
                'text'      => $chunk,
                'embedding' => $response->embeddings[0]->embedding,
            ];
        });
    }
}

Step 2: Storing Embeddings in Qdrant

Qdrant is a purpose-built vector database with a clean REST API. We'll use Laravel's HTTP client to interact with it directly — no SDK needed.

// app/Services/VectorStoreService.php

namespace App\Services;

use Illuminate\Support\Facades\Http;
use Illuminate\Support\Str;

class VectorStoreService
{
    protected string $baseUrl;
    protected string $collection;

    public function __construct()
    {
        $this->baseUrl    = config('services.qdrant.url');
        $this->collection = config('services.qdrant.collection');
    }

    public function upsertPoints(array $points): void
    {
        $payload = collect($points)->map(fn($point) => [
            'id'      => (string) Str::uuid(),
            'vector'  => $point['embedding'],
            'payload' => ['text' => $point['text']],
        ])->values()->all();

        Http::put("{$this->baseUrl}/collections/{$this->collection}/points", [
            'points' => $payload,
        ]);
    }

    public function search(array $queryEmbedding, int $topK = 5): array
    {
        $response = Http::post("{$this->baseUrl}/collections/{$this->collection}/points/search", [
            'vector' => $queryEmbedding,
            'limit'  => $topK,
            'with_payload' => true,
        ]);

        return collect($response->json('result'))
            ->pluck('payload.text')
            ->all();
    }
}

Step 3: The RAG Query Pipeline

This is where it all comes together. We embed the user's question, retrieve the most relevant chunks, then construct a prompt that grounds the LLM in that context.

// app/Services/ChatbotService.php

namespace App\Services;

use OpenAI\Laravel\Facades\OpenAI;

class ChatbotService
{
    public function __construct(
        protected VectorStoreService $vectorStore
    ) {}

    public function answer(string $userQuestion): string
    {
        // 1. Embed the question
        $embeddingResponse = OpenAI::embeddings()->create([
            'model' => 'text-embedding-3-small',
            'input' => $userQuestion,
        ]);
        $queryVector = $embeddingResponse->embeddings[0]->embedding;

        // 2. Retrieve relevant context
        $contextChunks = $this->vectorStore->search($queryVector, topK: 5);
        $context = implode("\n\n", $contextChunks);

        // 3. Build grounded prompt
        $systemPrompt = <<<PROMPT
        You are a helpful assistant. Answer the user's question using ONLY the context provided below.
        If the answer is not in the context, say "I don't have enough information to answer that."

        Context:
        {$context}
        PROMPT;

        // 4. Generate response
        $completion = OpenAI::chat()->create([
            'model'    => 'gpt-4o',
            'messages' => [
                ['role' => 'system',  'content' => $systemPrompt],
                ['role' => 'user',    'content' => $userQuestion],
            ],
        ]);

        return $completion->choices[0]->message->content;
    }
}

Wiring It Up with a Livewire Component

For real-time UX, a Livewire component handles streaming the response without a full page reload:

// app/Livewire/Chatbot.php

namespace App\Livewire;

use App\Services\ChatbotService;
use Livewire\Component;

class Chatbot extends Component
{
    public string $question = '';
    public string $answer   = '';
    public bool   $loading  = false;

    public function ask(ChatbotService $chatbot): void
    {
        $this->validate(['question' => 'required|string|max:500']);

        $this->loading = true;
        $this->answer  = $chatbot->answer($this->question);
        $this->loading = false;
    }

    public function render()
    {
        return view('livewire.chatbot');
    }
}

Improving Retrieval Quality

Once the basic pipeline works, a few techniques can significantly improve answer quality:

Hybrid Search

Combine vector similarity search with keyword (BM25) search. Qdrant supports sparse + dense vector search natively. This prevents edge cases where exact keyword matches score poorly in pure embedding space.

Re-ranking

After your initial top-K retrieval, run a cross-encoder re-ranker (e.g., via Cohere's Rerank API) to re-order results by true relevance to the question before constructing the prompt.

Metadata Filtering

Tag your chunks with metadata — document type, date, category — and pre-filter before the vector search. This is especially useful for multi-tenant systems where users should only see their own data.

// Example: filter by tenant in Qdrant search
Http::post("{$this->baseUrl}/collections/{$this->collection}/points/search", [
    'vector' => $queryEmbedding,
    'limit'  => $topK,
    'filter' => [
        'must' => [
            ['key' => 'tenant_id', 'match' => ['value' => auth()->id()]],
        ],
    ],
    'with_payload' => true,
]);

Real-World Considerations

Building this in production surfaces a few gotchas worth knowing before you deploy:

Embedding costs: text-embedding-3-small is cheap, but large document libraries still add up. Cache embeddings aggressively and only re-embed on document change.
Chunk freshness: When source documents update, you need a strategy to re-ingest the affected chunks and delete stale vectors by document ID.
Latency: Two API calls (embed + generate) plus a vector search adds 1–3 seconds. Use Laravel queues and optimistic UI patterns to keep the experience snappy.
Evaluation: Build a test set of question/answer pairs and track retrieval recall + answer faithfulness. Without measurement, you're flying blind. Tools like RAGAS can automate this.

For teams exploring how these patterns integrate into client projects — whether it's document Q&A, internal knowledge bases, or customer support bots — there's genuinely useful material to check it out across different AI integration approaches.

Conclusion

RAG isn't a silver bullet, but it's the most practical architecture for building chatbots that actually know what they're talking about. The core pattern — embed, retrieve, generate — is straightforward in Laravel once you have the scaffolding in place. The real engineering work is in the details: chunk strategy, hybrid search, metadata filtering, and evaluation.

Start simple: get one document ingested and a basic similarity search working end-to-end. Then layer on the improvements. A working RAG pipeline you can iterate on beats a theoretically perfect one you never ship.

Why Dubai Businesses Need Custom Web Applications in 2026: A Developer's Honest Take

Marcc Atayde — Tue, 21 Jul 2026 01:00:04 +0000

The Off-the-Shelf Problem Nobody Talks About

Every week, a Dubai business owner walks into a meeting with a developer and asks the same question: "Can't we just use WordPress/Shopify/a SaaS tool for this?" Sometimes the answer is yes. But increasingly in 2026, the answer is a qualified no — and the reasons are more technical and economic than most developers bother to explain properly.

Dubai's digital economy is maturing fast. The UAE's Vision 2031 targets position the country as a global digital hub, and businesses competing here face a different set of demands than a startup in, say, a slower-moving market. Regulatory requirements (VAT compliance, UAE Pass integration, Arabic RTL support), multilingual customer bases, and the sheer speed of regional competition mean that generic platforms often become expensive constraints rather than helpful scaffolding.

This article isn't a sales pitch for custom development. It's an honest technical breakdown of where off-the-shelf solutions genuinely break down for Dubai-scale businesses — and what a well-architected custom application actually looks like under the hood.

Where Generic Platforms Hit the Wall

1. Arabic RTL + Bilingual Logic Is Not a Theme Switch

Every Arabic-capable SaaS product claims RTL support. In practice, you get a mirrored layout with a handful of translated UI strings. What you don't get is business logic that handles Arabic content gracefully — search that understands Arabic morphology, PDFs that render right-to-left correctly, or CMS workflows where editors can manage Arabic and English content with proper field parity.

In a custom Laravel application, you handle this with dedicated locale middleware and structured content models:

// App\Http\Middleware\SetLocale.php
public function handle(Request $request, Closure $next)
{
    $locale = $request->header('Accept-Language', 'en');
    $supported = ['en', 'ar'];

    $locale = in_array(substr($locale, 0, 2), $supported)
        ? substr($locale, 0, 2)
        : 'en';

    App::setLocale($locale);
    Carbon::setLocale($locale);

    return $next($request);
}

Your content models carry both fields natively:

Schema::create('products', function (Blueprint $table) {
    $table->id();
    $table->string('name_en');
    $table->string('name_ar');
    $table->text('description_en')->nullable();
    $table->text('description_ar')->nullable();
    $table->boolean('rtl_override')->default(false);
    $table->timestamps();
});

This is table-stakes for any serious UAE product. A SaaS plugin won't give you this cleanly.

2. UAE Government API Integrations

Dubai businesses increasingly need to integrate with UAE Pass (the national digital identity system), Dubai REST APIs for trade licensing, and FTA (Federal Tax Authority) systems for VAT e-invoicing. These integrations require OAuth 2.0 flows, specific certificate handling, and sometimes Arabic-encoded XML payloads.

Here's a simplified example of a UAE Pass OAuth token exchange:

class UAEPassService
{
    public function exchangeCodeForToken(string $code): array
    {
        $response = Http::withHeaders([
            'Authorization' => 'Basic ' . base64_encode(
                config('uaepass.client_id') . ':' . config('uaepass.client_secret')
            ),
        ])->asForm()->post(config('uaepass.token_endpoint'), [
            'grant_type'   => 'authorization_code',
            'code'         => $code,
            'redirect_uri' => config('uaepass.redirect_uri'),
        ]);

        throw_if($response->failed(), new UAEPassAuthException(
            'Token exchange failed: ' . $response->body()
        ));

        return $response->json();
    }
}

No Shopify app or WordPress plugin ships with this. You build it, or you don't have it.

3. Performance Under Regional Infrastructure Conditions

Dubai users are sophisticated and mobile-first, but regional CDN edge locations and ISP routing patterns differ from North America or Europe. Page speed benchmarks achieved in London don't always replicate in Dubai without specific optimization.

Custom applications let you tune infrastructure deliberately: choosing data centers in the UAE (Khazna, AWS me-south-1 in Bahrain, or Azure UAE North), configuring Redis for session and cache layers tuned to your traffic patterns, and implementing lazy loading strategies that account for the actual device profile of your user base.

// config/cache.php — UAE-tuned Redis config
'redis' => [
    'client' => env('REDIS_CLIENT', 'phpredis'),
    'default' => [
        'host'       => env('REDIS_HOST', '127.0.0.1'),
        'port'       => env('REDIS_PORT', 6379),
        'database'   => 0,
        'read_timeout' => 2, // Tighter timeout for regional latency
    ],
],

Small tuning decisions like this, made deliberately at build time, produce measurable differences in Core Web Vitals scores — which directly affect Google rankings in the .ae SERP.

The Real Cost Calculation

One of the most repeated objections to custom development is cost. "Shopify is $39/month, a custom app is $30,000." This comparison is almost always false economy at scale.

Consider a mid-size Dubai retailer:

Shopify Advanced: ~$400/month
Essential plugins (reviews, loyalty, Arabic support, VAT): ~$300/month combined
Transaction fees on payment gateway: 0.5–1% of revenue
Developer time fighting platform limitations: 5–10 hours/month

At $500K annual revenue, transaction fees alone run $2,500–$5,000/year. Plugin costs compound. And every major feature request hits a wall that requires workarounds, not solutions.

A well-built custom Laravel application on a $250/month VPS — with zero transaction fees and full ownership — often reaches TCO parity within 18–24 months for businesses at this scale. Beyond that, every month is cheaper.

What "Custom" Actually Means in Practice

Custom doesn't mean built from scratch unnecessarily. Modern teams building for Dubai clients use:

Laravel as the application backbone (routing, ORM, queues, auth)
Livewire + Alpine.js for reactive UI without the SPA complexity overhead
Tailwind CSS for design systems that adapt cleanly to RTL
Horizon + Redis for background job processing (order notifications, report generation)
Filament for internal admin panels that would otherwise take months to scaffold

This stack — sometimes called the TALL stack — gives Dubai development teams the velocity of a framework ecosystem with the flexibility of a fully owned codebase. It's the same approach teams building content-heavy, SEO-driven products use; an AI-powered SEO blog service Dubai running on this stack can automate localized content pipelines in ways no generic CMS plugin can match.

When Off-the-Shelf Is Still the Right Answer

Honesty matters here. If you're a solo founder validating a product idea, a Shopify store or a WordPress site with Elementor is absolutely the right call. Speed to market beats architectural purity at day zero.

Custom development earns its cost when:

Your business logic is complex enough that SaaS tools require constant workarounds
You need integrations that don't exist as off-the-shelf plugins
You're at a scale where platform fees compound into real money
Competitive differentiation depends on user experience that generic themes can't deliver
You need compliance guarantees (data residency, VAT, specific audit trails) that SaaS vendors can't contractually provide in the UAE market

Conclusion

The question for Dubai businesses in 2026 isn't "should we build custom?" — it's "at what point does custom become the rational economic and technical choice?" For many businesses operating in this market, that inflection point arrives earlier than expected, driven by the specific integration demands, bilingual complexity, and regulatory landscape of the UAE.

If you're a developer advising clients in this region, the most valuable thing you can do is help them run that honest TCO calculation before defaulting to either extreme. The right architecture isn't the cheapest upfront — it's the one that doesn't become a liability the moment the business needs to grow.

Laravel Queue Workers: Processing Background Jobs at Scale

Marcc Atayde — Tue, 07 Jul 2026 01:00:06 +0000

Laravel Queue Workers: Processing Background Jobs at Scale

You're three months post-launch and your app is gaining traction. Then the complaints start rolling in: "Why does sending an invoice take 8 seconds?" The culprit is almost always the same — synchronous execution of work that should be deferred. Laravel's queue system exists precisely to solve this, but running it in production at scale is a different beast from getting it working locally. This article digs into the real mechanics of queue workers, job design, scaling strategies, and the failure modes that will bite you if you're not prepared.

How Laravel Queues Actually Work

Before optimizing, it's worth understanding the pipeline. When you dispatch a job, Laravel serializes it and writes a record to your configured queue driver (database, Redis, SQS, etc.). A queue worker is a long-running PHP process that polls that driver, deserializes the job, executes it, and acknowledges completion — or handles failure.

php artisan queue:work redis --queue=high,default --tries=3 --timeout=60

The key insight: queue:work keeps the application bootstrapped in memory between jobs. This is fast, but it means code changes require a worker restart. This trips up nearly every developer the first time they deploy a fix and wonder why their jobs are still running old logic.

queue:listen, by contrast, re-bootstraps for each job — safe but slow. Use it in development; never in production.

Structuring Jobs for Reliability

A job that fails halfway through can cause real damage if it re-runs and repeats destructive side effects. Design jobs to be idempotent — running them twice should produce the same outcome as running them once.

class ProcessSubscriptionRenewal implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    public int $tries = 3;
    public int $backoff = 60; // seconds between retries

    public function __construct(private readonly Subscription $subscription) {}

    public function handle(BillingService $billing): void
    {
        // Guard against double-processing
        if ($this->subscription->renewed_at?->isToday()) {
            return;
        }

        $billing->renew($this->subscription);
    }

    public function failed(Throwable $exception): void
    {
        Log::error('Subscription renewal failed', [
            'subscription_id' => $this->subscription->id,
            'error' => $exception->getMessage(),
        ]);

        $this->subscription->owner->notify(new RenewalFailedNotification());
    }
}

The failed() method is your safety net. Always implement it for jobs with business consequences.

Choosing the Right Queue Driver

Database driver works fine for low-volume applications and requires zero additional infrastructure. The downside: polling creates database load, and high-frequency jobs can hammer your jobs table.

Redis is the sweet spot for most production applications. It's fast, supports atomic operations (eliminating race conditions), and Laravel Horizon gives you a beautiful dashboard on top of it.

Amazon SQS makes sense when you're already in the AWS ecosystem and want managed infrastructure with automatic scaling and dead-letter queues baked in.

For most Laravel shops, Redis + Horizon is the answer.

Laravel Horizon: The Missing Dashboard

If you're running Redis queues without Horizon, you're flying blind. Horizon gives you real-time throughput metrics, per-queue balancing, failed job management, and — critically — a configuration-as-code approach to worker pools.

// config/horizon.php
'environments' => [
    'production' => [
        'supervisor-1' => [
            'connection' => 'redis',
            'queue' => ['critical', 'high', 'default', 'low'],
            'balance' => 'auto',
            'minProcesses' => 2,
            'maxProcesses' => 20,
            'balanceMaxShift' => 5,
            'balanceCooldown' => 3,
            'tries' => 3,
            'timeout' => 90,
        ],
    ],
],

The auto balance strategy is powerful: Horizon monitors queue depth and dynamically scales worker count between minProcesses and maxProcesses. During a spike — say, a bulk email campaign fires — workers scale up automatically and wind back down once the queue clears.

Prioritizing Work with Multiple Queues

Not all jobs are equal. A password reset email and a low-priority analytics event shouldn't compete for the same worker. Define explicit queues and dispatch accordingly:

// Dispatch to named queues
PasswordResetEmail::dispatch($user)->onQueue('critical');
AnalyticsEvent::dispatch($data)->onQueue('low');

When starting a worker, list queues in priority order:

php artisan queue:work redis --queue=critical,high,default,low

The worker exhausts higher-priority queues before touching lower ones. Be careful with this pattern though — a flood of critical jobs can starve low indefinitely. Consider dedicated workers per tier in high-throughput environments.

Handling Timeouts and Memory Limits

Two flags that developers often ignore until they cause a production incident:

--timeout: Kills a job that runs longer than N seconds. Set it slightly below your job's expected maximum runtime. A PDF generation job might need --timeout=120; a simple notification should finish in under 5.
--memory: Restarts the worker when memory usage exceeds N megabytes. PHP processes leak memory over time, especially with ORM-heavy jobs. Setting --memory=256 is a reasonable baseline.

php artisan queue:work redis --timeout=60 --memory=256 --sleep=1

--sleep=1 controls how long the worker pauses (in seconds) when no jobs are available. Lower values reduce latency but increase polling overhead.

Keeping Workers Alive: Supervisor Configuration

Workers die — from memory limits, crashes, or deploys. Supervisor is the standard tool to keep them running.

[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/html/artisan queue:work redis --queue=critical,high,default --sleep=1 --tries=3 --timeout=90 --memory=256
autostart=true
autorestart=true
numprocs=4
stopasgroup=true
killasgroup=true
user=www-data
redirect_stderr=true
stdout_logfile=/var/log/worker.log

numprocs=4 spins up four parallel worker processes. Adjust this based on your server's CPU count and job characteristics — CPU-bound jobs benefit from more processes; I/O-bound jobs (API calls, email sends) can run many more per core.

Graceful Deploys with Zero Job Loss

This is where teams cut corners and pay for it. When you deploy new code, workers need to restart — but not mid-job.

php artisan queue:restart

This sets a flag in cache. Workers finish their current job, check the flag, and exit gracefully. Supervisor then respawns them with fresh code. Wire this into your deployment script (Envoyer, GitHub Actions, Forge deploy hooks — wherever your deploys live).

Pair this with ShouldBeUniqueUntilProcessing on jobs that should never queue duplicates:

class SyncUserProfile implements ShouldQueue, ShouldBeUniqueUntilProcessing
{
    public function uniqueId(): string
    {
        return $this->user->id;
    }
}

Monitoring in Production

Horizon's dashboard is great for development and internal monitoring, but for production alerting you need to go further. At https://hanzweb.ae, working across multiple high-traffic Laravel deployments, we wire Horizon metrics into Prometheus/Grafana and set alerts on failed job rates and queue depth thresholds — a queue depth spiking above 500 on the critical channel at 2AM is worth waking someone up.

Also implement regular pruning to prevent your failed_jobs table from becoming a graveyard:

# In your scheduler
$schedule->command('queue:prune-failed --hours=168')->daily();

Conclusion

Laravel's queue system is one of its most powerful features — but it rewards developers who understand the failure modes, not just the happy path. Design idempotent jobs, choose your driver deliberately, use Horizon for visibility, configure Supervisor for resilience, and always hook queue:restart into your deploy pipeline. These aren't advanced techniques — they're table stakes for any application where background jobs matter. Get this foundation right, and you can scale your worker fleet horizontally with confidence when the traffic comes.

Technical SEO Audit Checklist for Modern Web Applications: What Crawlers Actually See

Marcc Atayde — Tue, 30 Jun 2026 01:00:07 +0000

You shipped a beautiful web application. Clean code, smooth UX, fast on your machine. Then you check Google Search Console and realize your pages are barely indexed, your structured data is throwing errors, and half your canonical tags are pointing to the wrong URLs. Sound familiar?

Technical SEO is the unsexy foundation that either unlocks or blocks all the content work you do on top of it. This audit checklist is built for developers — not marketers — so we'll go deep on the implementation details, not just the theory.

1. Crawlability and Indexation

Before anything else, you need to verify that Googlebot can actually find and read your pages.

robots.txt

Your robots.txt lives at the root of your domain. A common mistake in Laravel apps is accidentally blocking crawlers in production because someone copied a staging config.

User-agent: *
Disallow: /admin/
Disallow: /api/
Allow: /

Sitemap: https://yourdomain.com/sitemap.xml

Verify it at https://yourdomain.com/robots.txt and test specific URLs using Google Search Console's URL Inspection tool.

XML Sitemap

Your sitemap should include all canonical, indexable URLs — nothing behind auth walls, nothing with noindex. In Laravel, the spatie/laravel-sitemap package makes this straightforward:

use Spatie\Sitemap\Sitemap;
use Spatie\Sitemap\Tags\Url;

Sitemap::create()
    ->add(
        Url::create('/blog')
            ->setLastModificationDate(now())
            ->setChangeFrequency(Url::CHANGE_FREQUENCY_DAILY)
            ->setPriority(0.8)
    )
    ->writeToFile(public_path('sitemap.xml'));

Don't just generate it once — hook it into your deployment pipeline or schedule it via php artisan schedule:run.

2. Canonical Tags and Duplicate Content

Duplicate content is one of the most common technical SEO issues, especially in e-commerce and CMS-driven apps. URL variations like ?ref=newsletter, ?sort=price, or trailing slash inconsistencies all create duplicate signals.

Every page needs a self-referencing canonical

<link rel="canonical" href="https://yourdomain.com/products/running-shoes" />

In Laravel Blade, centralise this:

<link rel="canonical" href="{{ $canonical ?? url()->current() }}" />

Then in your controllers or Livewire components, explicitly set the canonical when needed — especially for paginated pages, filtered product listings, or tag archives.

HTTP vs HTTPS, WWW vs non-WWW

Pick one and redirect everything else to it with a 301. Check your .htaccess or Nginx config. This should be handled at the server level, not just in Laravel's middleware.

3. Structured Data (Schema Markup)

Structured data doesn't guarantee rich results, but it does help Google understand your content. For a web app, the relevant schemas are usually Article, Product, FAQPage, BreadcrumbList, and LocalBusiness.

@push('head')
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "{{ $post->title }}",
  "datePublished": "{{ $post->published_at->toIso8601String() }}",
  "author": {
    "@type": "Person",
    "name": "{{ $post->author->name }}"
  },
  "image": "{{ $post->og_image_url }}"
}
</script>
@endpush

Validate everything using Google's Rich Results Test and the Schema Markup Validator.

4. Core Web Vitals and Page Experience Signals

Google's Page Experience signals include LCP, INP (replacing FID), and CLS. These are measurable, fixable, and directly tied to ranking.

LCP (Largest Contentful Paint): Should be under 2.5s. Preload your hero images with <link rel="preload" as="image">. Lazy-load everything below the fold.
INP (Interaction to Next Paint): Heavy JavaScript blocking the main thread is the usual culprit. Audit your JS bundle — Alpine.js stays lean, but watch for third-party scripts.
CLS (Cumulative Layout Shift): Always set explicit width and height on images and iframes. Reserve space for async-loaded UI elements.

Run npx lighthouse https://yourdomain.com --view locally for a quick diagnostic.

5. Metadata Completeness

Every page needs a unique, descriptive <title> and <meta name="description">. These won't directly boost rankings but they affect click-through rates, which does matter.

<title>{{ $page->seo_title ?? $page->title . ' | ' . config('app.name') }}</title>
<meta name="description" content="{{ $page->meta_description ?? $page->excerpt }}" />

Also audit your Open Graph and Twitter Card tags — these control how your pages look when shared:

<meta property="og:title" content="{{ $page->og_title ?? $page->title }}" />
<meta property="og:image" content="{{ $page->og_image ?? asset('images/default-og.jpg') }}" />
<meta property="og:type" content="website" />

Keep titles under 60 characters and descriptions under 155. Use a spreadsheet to audit them at scale — export your URLs and titles via a crawler like Screaming Frog.

6. Mobile and Internationalisation

Mobile-First Indexing

Google now indexes the mobile version of your site first. Test with Chrome DevTools in mobile emulation and verify your responsive breakpoints aren't hiding critical content behind JavaScript toggles.

hreflang for Multi-Language Apps

If you're running a multi-language Laravel app, hreflang tells Google which version to serve for which locale:

<link rel="alternate" hreflang="en" href="https://yourdomain.com/en/about" />
<link rel="alternate" hreflang="ar" href="https://yourdomain.com/ar/about" />
<link rel="alternate" hreflang="x-default" href="https://yourdomain.com/en/about" />

This is particularly relevant for businesses operating in multilingual markets — something the team at HanzWeb.ae encounters regularly when building regional web applications for clients across the UAE and MENA.

7. HTTPS, Security Headers, and URL Structure

Ensure all internal links use HTTPS. Mixed content warnings can affect crawl behaviour.
Use descriptive, hyphenated slugs: /blog/technical-seo-audit not /blog?id=87
Avoid deep URL nesting beyond three levels
Return proper HTTP status codes: 404 for missing pages, 410 for intentionally deleted content, 301 for permanent redirects

Check your redirect chains — a 301 that hits another 301 before reaching the destination wastes crawl budget and dilutes link equity.

8. Log File Analysis (Underused but Powerful)

Server logs tell you exactly what Googlebot is crawling and how often. Tools like Screaming Frog Log Analyzer or even a simple grep on your Nginx/Apache logs can reveal:

Pages being crawled but not indexed
Soft 404s (pages returning 200 but showing empty content)
Crawl budget being wasted on paginated parameter URLs

grep 'Googlebot' /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

This gives you the top 20 URLs Googlebot is spending time on. If it's hitting /api/ endpoints or admin routes, fix your robots.txt immediately.

Putting It All Together

Technical SEO isn't a one-time task — it's an ongoing audit practice. The checklist above covers the highest-impact areas, but the real discipline is building these checks into your development workflow rather than treating them as an afterthought post-launch.

Set up a quarterly crawl with Screaming Frog, monitor Search Console weekly for coverage errors, and make structured data and canonical logic part of your page templates from day one. The applications that rank consistently aren't the ones with the cleverest content strategy — they're the ones with a technically sound foundation that search engines can trust.

Livewire Polling, Events, and Lazy Loading: A Practical Guide to Real-Time UX Without WebSockets

Marcc Atayde — Tue, 16 Jun 2026 01:00:11 +0000

There's a common misconception that real-time features in Laravel require a WebSocket server, Redis pub/sub, and a tangle of JavaScript. For many use cases — live counters, notification badges, auto-refreshing tables, instant form feedback — Livewire gets you 90% of the way there with a fraction of the complexity. This article walks through three practical patterns: polling, browser and component events, and lazy loading, with working code you can drop into a real project today.

Why Livewire Before WebSockets?

WebSockets are powerful but carry real operational overhead: you need a persistent connection server (Laravel Reverb, Soketi, or Pusher), queue workers, broadcasting configuration, and frontend Echo setup. That's the right tool when you need true push from the server — think collaborative editing or live chat.

But a surprising number of "real-time" requirements are actually just near-real-time: a dashboard that refreshes every 5 seconds, a notification count that updates when the user navigates, a search box that queries as you type. Livewire handles all of these natively, and your stack stays simple.

Pattern 1: Polling for Live Data

Livewire's #[Poll] attribute (Livewire v3) is the quickest way to keep a component fresh. Here's a live order counter for an e-commerce admin panel:

<?php

namespace App\Livewire;

use App\Models\Order;
use Livewire\Attributes\Poll;
use Livewire\Component;

class PendingOrderCount extends Component
{
    #[Poll(5000)] // Poll every 5 seconds
    public int $count = 0;

    public function mount(): void
    {
        $this->count = Order::where('status', 'pending')->count();
    }

    public function render()
    {
        $this->count = Order::where('status', 'pending')->count();
        return view('livewire.pending-order-count');
    }
}

<!-- resources/views/livewire/pending-order-count.blade.php -->
<div class="flex items-center gap-2">
    <span class="text-sm text-gray-500">Pending Orders</span>
    <span class="rounded-full bg-red-500 px-2 py-0.5 text-xs font-bold text-white">
        {{ $count }}
    </span>
</div>

Polling fires an XHR request on the interval you define. For low-traffic admin tools this is perfectly fine. For high-traffic pages, push the interval to 30 seconds or cache the query result — avoid hammering your database on every tick.

Pausing Polls When the Tab Is Hidden

Livewire v3 respects the browser's Visibility API by default when you use keep-alive wisely, but you can make it explicit with Alpine:

<div
    x-data="{ visible: true }"
    x-on:visibilitychange.window="visible = !document.hidden"
    wire:poll.5000ms="refresh"
    x-bind:wire:poll.5000ms="visible ? 'refresh' : ''"
>
    <!-- content -->
</div>

This small change can meaningfully reduce server load when users have many tabs open.

Pattern 2: Component Events for Instant Feedback

Polling is pull-based. Events are push-based within the Livewire component tree — perfect for things like form submission confirmation, parent-child component communication, or triggering a toast notification.

Suppose you have a CreateTask form and a TaskList on the same page. When a task is saved, you want the list to refresh instantly without a page reload.

// App/Livewire/CreateTask.php
public function save(): void
{
    $this->validate([
        'title' => 'required|min:3',
    ]);

    Task::create(['title' => $this->title, 'user_id' => auth()->id()]);

    $this->reset('title');
    $this->dispatch('task-created'); // Fire the event
}

// App/Livewire/TaskList.php
use Livewire\Attributes\On;

class TaskList extends Component
{
    #[On('task-created')]
    public function refreshList(): void
    {
        // Livewire re-renders automatically; just declare the listener
    }

    public function render()
    {
        return view('livewire.task-list', [
            'tasks' => Task::where('user_id', auth()->id())
                          ->latest()
                          ->get(),
        ]);
    }
}

The #[On] attribute in Livewire v3 replaces the old $listeners array. Clean, declarative, and easy to trace. When CreateTask fires task-created, TaskList re-renders with fresh data — no JavaScript glue required.

Dispatching to the Browser (Alpine.js Integration)

Sometimes you want to trigger a JavaScript behaviour from a Livewire action — showing a toast, opening a modal, or triggering a CSS animation. Use dispatch with self scoped or dispatch a browser event:

// In your Livewire component
$this->dispatch('notify', message: 'Task created successfully!');

<!-- In your layout or a separate Alpine component -->
<div
    x-data="{ show: false, message: '' }"
    x-on:notify.window="message = $event.detail.message; show = true; setTimeout(() => show = false, 3000)"
>
    <div x-show="show" x-transition class="toast">
        <span x-text="message"></span>
    </div>
</div>

This is the TALL stack working as intended — Livewire handles server state, Alpine handles UI micro-interactions, no custom JavaScript files needed.

Pattern 3: Lazy Loading for Perceived Performance

Real-time UX isn't only about live data — it's also about making the page feel fast. Livewire's lazy attribute defers a component's first render until it enters the viewport, which is a significant win for dashboards with many expensive widgets.

<!-- In your Blade layout -->
<livewire:revenue-chart lazy />
<livewire:top-products lazy />
<livewire:recent-activity lazy />

While the component loads, you can show a placeholder using the placeholder method:

// App/Livewire/RevenueChart.php
public function placeholder()
{
    return <<<'HTML'
    <div class="h-64 animate-pulse rounded-xl bg-gray-100"></div>
    HTML;
}

This skeleton screen pattern dramatically improves First Contentful Paint scores and gives users immediate visual feedback that something is loading — which is itself a form of real-time UX.

Combining Patterns: A Live Dashboard Component

Here's how these three patterns fit together in practice. At HanzWeb, where we build a lot of client-facing dashboards, we typically structure admin pages like this:

Lazy load all heavy chart and stats components on mount
Poll lightweight counters every 10–30 seconds
Dispatch events from action components (approve, reject, create) to refresh adjacent list components instantly

This gives you a dashboard that loads fast, stays reasonably fresh without constant polling overhead, and responds instantly to user actions — without a single line of WebSocket configuration. If you're curious how this translates to real production interfaces, you can see our work for examples of Livewire-powered dashboards built for clients across different industries.

When to Move Beyond Livewire

Be honest about your requirements. Livewire polling is not the right tool when:

You need sub-second latency (live bidding, multiplayer, collaborative editing)
You need server-push without the user triggering any interaction
You have thousands of concurrent users all polling frequently

For those cases, reach for Laravel Reverb (the official first-party WebSocket server introduced in Laravel 11) with Laravel Echo on the frontend. But for most business applications — CRMs, admin panels, SaaS dashboards, booking systems — Livewire's built-in primitives are more than enough.

Conclusion

Real-time UX in Laravel doesn't have to mean infrastructure complexity. Livewire polling covers dashboard refresh scenarios, component events handle instant cross-component communication, and lazy loading makes your app feel fast before the data even arrives. Master these three patterns and you'll solve the majority of real-time requirements your clients will ever ask for — with code that's readable, testable, and maintainable by any Laravel developer on your team.

Database Optimization Techniques for High-Traffic Laravel Applications

Marcc Atayde — Tue, 09 Jun 2026 01:00:08 +0000

Your Laravel app works great in development. A few hundred users hit it in production and suddenly query times balloon, your server sweats, and you're staring at a Telescope dashboard wondering what went wrong. Database performance issues are rarely dramatic at first — they creep in quietly, then compound fast.

This article covers the practical database optimization techniques that actually move the needle for high-traffic Laravel applications: the ones you can implement today, measure immediately, and rely on in production.

1. Eliminate N+1 Queries Before They Kill You

The N+1 problem is the silent killer of Laravel performance. It happens when you load a collection and then trigger an additional query per item in a loop.

// ❌ N+1 Problem — fires 1 + N queries
$posts = Post::all();
foreach ($posts as $post) {
    echo $post->author->name; // separate query per post
}

// ✅ Eager Loading — fires 2 queries total
$posts = Post::with('author')->get();
foreach ($posts as $post) {
    echo $post->author->name;
}

For nested relationships, chain them:

$posts = Post::with(['author', 'comments.user', 'tags'])->paginate(20);

Enable query logging in development to catch these early:

\DB::enableQueryLog();
// ... run your code
dd(\DB::getQueryLog());

Or better yet, use Laravel Telescope or Debugbar on your local environment — both flag N+1 issues automatically.

2. Index Strategically, Not Blindly

Indexes speed up reads but slow down writes. The goal is to index columns you actually filter and sort by — not every column.

// In a migration
Schema::table('orders', function (Blueprint $table) {
    $table->index('user_id');                    // foreign key lookups
    $table->index('status');                     // frequent WHERE clause
    $table->index(['user_id', 'created_at']);    // composite index for user history queries
});

Composite Index Column Order Matters

MySQL uses indexes left-to-right. If you frequently query WHERE user_id = ? AND status = ?, put user_id first in the composite index — it has higher cardinality and will narrow the result set faster.

To confirm your indexes are being used, prefix any slow query with EXPLAIN:

EXPLAIN SELECT * FROM orders WHERE user_id = 42 AND status = 'pending';

If you see type: ALL in the output, MySQL is doing a full table scan — your index isn't being used.

3. Use Query Chunking and Lazy Collections for Bulk Operations

Processing thousands of rows at once will exhaust memory. Laravel gives you two elegant solutions.

// chunk() — processes records in batches
User::where('subscribed', true)->chunk(500, function ($users) {
    foreach ($users as $user) {
        // process each user
    }
});

// lazyById() — uses a cursor for memory-efficient streaming
User::where('subscribed', true)->lazyById()->each(function ($user) {
    // process one at a time, low memory footprint
});

For bulk inserts, avoid looping create() calls. Use insert() to send a single query:

// ❌ Fires 1000 separate INSERT queries
foreach ($records as $record) {
    Order::create($record);
}

// ✅ Single INSERT with multiple rows
Order::insert($records); // $records is an array of arrays

4. Cache Aggressively at the Right Layer

Not all data needs to hit the database on every request. Laravel's cache layer is your best friend here.

// Cache an expensive aggregation for 10 minutes
$stats = Cache::remember('dashboard:stats', 600, function () {
    return Order::selectRaw('
        COUNT(*) as total_orders,
        SUM(amount) as revenue,
        AVG(amount) as avg_order_value
    ')->whereMonth('created_at', now()->month)->first();
});

For per-user data, namespace your cache keys:

$key = "user:{$userId}:order_summary";
$summary = Cache::remember($key, 300, fn() => $this->buildSummary($userId));

Use Redis as your cache driver in production — it's orders of magnitude faster than the database or file cache, and it supports atomic operations, pub/sub, and TTL natively.

CACHE_DRIVER=redis
REDIS_HOST=127.0.0.1
REDIS_PORT=6379

5. Select Only What You Need

This one is simple but often ignored. SELECT * pulls every column, including large text fields, JSON blobs, and timestamps you don't need.

// ❌ Fetches every column, including bio, avatar_url, settings JSON...
$users = User::all();

// ✅ Only fetch what the view actually uses
$users = User::select('id', 'name', 'email')->get();

This reduces memory usage and network overhead between your database and PHP process — especially noticeable with large datasets.

6. Optimize Pagination for Large Tables

Standard paginate() uses a COUNT(*) query under the hood. On tables with millions of rows, this becomes expensive.

For infinite scroll or "load more" UIs, use cursorPaginate() instead:

// Standard pagination — expensive COUNT on large tables
$posts = Post::latest()->paginate(20);

// Cursor pagination — no COUNT, extremely efficient
$posts = Post::latest()->cursorPaginate(20);

Cursor pagination uses an encoded pointer to the last record rather than an OFFSET, which means performance stays consistent regardless of how deep you paginate.

7. Use Database Read Replicas for Read-Heavy Workloads

If your application is read-heavy (most are), routing read queries to a replica and writes to the primary can dramatically reduce load on your main database server.

Laravel supports this natively in config/database.php:

'mysql' => [
    'read' => [
        'host' => ['192.168.1.2', '192.168.1.3'], // replica IPs
    ],
    'write' => [
        'host' => ['192.168.1.1'], // primary
    ],
    'sticky' => true, // ensure writes are immediately readable
    'driver' => 'mysql',
    // ... other config
],

With sticky => true, any write during the current request will be read back from the primary — avoiding the replication lag gotcha.

8. Profile First, Optimize Second

Before touching anything in production, measure. Gut feelings about bottlenecks are often wrong.

Tools worth using:

Laravel Telescope — query time, slow queries, N+1 detection
Laravel Pulse — aggregated performance data across your app
Clockwork — browser devtools-style profiling for PHP
MySQL Slow Query Log — catches queries over a configurable threshold

Enable the slow query log in MySQL:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1; -- log queries taking over 1 second
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

Then use mysqldumpslow or pt-query-digest from Percona Toolkit to analyze the output.

This kind of profiling-first approach is something we apply consistently when auditing client applications at HanzWeb Agency — the slowest queries are rarely the ones developers suspect.

Conclusion

Database optimization isn't a one-time task — it's an ongoing discipline. The most impactful starting points are almost always the same: fix your N+1 queries, add the right indexes, and cache expensive reads with Redis. From there, cursor pagination, selective columns, and read replicas become your next levers as traffic scales.

Measure before you optimize, use Laravel's built-in tooling to surface the real bottlenecks, and build the habit of reviewing query logs as part of your deployment process. Your database will thank you — and so will your users.

Building Production-Ready RESTful APIs with Laravel: Authentication, Rate Limiting, and Versioning

Marcc Atayde — Tue, 26 May 2026 01:00:10 +0000

Building Production-Ready RESTful APIs with Laravel: Authentication, Rate Limiting, and Versioning

Most Laravel API tutorials stop at Route::get('/users', ...) and call it a day. But shipping an API to production is a different animal entirely. You need robust authentication, protection against abuse, and a versioning strategy that won't break your clients every time you iterate. This guide walks through all three — with real code, not hand-waving.

Authentication with Laravel Sanctum

For most APIs — especially SPAs and mobile apps — Laravel Sanctum is the right tool. It's lighter than Passport and covers 90% of real-world use cases.

composer require laravel/sanctum
php artisan vendor:publish --provider="Laravel\Sanctum\SanctumServiceProvider"
php artisan migrate

Add the HasApiTokens trait to your User model:

use Laravel\Sanctum\HasApiTokens;

class User extends Authenticatable
{
    use HasApiTokens, HasFactory, Notifiable;
}

Issuing Tokens on Login

// app/Http/Controllers/Api/AuthController.php

public function login(Request $request): JsonResponse
{
    $request->validate([
        'email'    => 'required|email',
        'password' => 'required',
    ]);

    $user = User::where('email', $request->email)->first();

    if (! $user || ! Hash::check($request->password, $user->password)) {
        return response()->json(['message' => 'Invalid credentials'], 401);
    }

    // Revoke old tokens for this device if needed
    $user->tokens()->where('name', $request->device_name)->delete();

    $token = $user->createToken($request->device_name, ['*'], now()->addDays(30));

    return response()->json([
        'token'      => $token->plainTextToken,
        'expires_at' => $token->accessToken->expires_at,
    ]);
}

Notice the token expiry — never issue non-expiring tokens in production. Also notice we delete any existing token for that device name before issuing a new one. This prevents token accumulation.

Protecting Routes

// routes/api.php

Route::middleware('auth:sanctum')->group(function () {
    Route::get('/user', [UserController::class, 'show']);
    Route::post('/logout', [AuthController::class, 'logout']);
});

For token abilities (scopes), check them in controllers:

if ($request->user()->tokenCan('orders:write')) {
    // ...
}

Rate Limiting

Without rate limiting, your API is one angry bot away from a bad day. Laravel's RateLimiter facade gives you precise control.

Defining Custom Limiters

In App\Providers\RouteServiceProvider (or a dedicated AppServiceProvider in Laravel 11+), define your limiters in the boot method:

use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiter;

public function boot(): void
{
    // Public endpoints — limit by IP
    RateLimiter::for('public-api', function (Request $request) {
        return Limit::perMinute(30)->by($request->ip());
    });

    // Authenticated endpoints — limit by user
    RateLimiter::for('authenticated-api', function (Request $request) {
        return $request->user()
            ? Limit::perMinute(120)->by($request->user()->id)
            : Limit::perMinute(20)->by($request->ip());
    });

    // Expensive operations (e.g., AI endpoints)
    RateLimiter::for('heavy-operations', function (Request $request) {
        return [
            Limit::perMinute(10)->by($request->user()?->id ?? $request->ip()),
            Limit::perDay(500)->by($request->user()?->id ?? $request->ip()),
        ];
    });
}

Apply them to routes:

Route::middleware(['auth:sanctum', 'throttle:authenticated-api'])->group(function () {
    Route::get('/products', [ProductController::class, 'index']);
});

Route::middleware(['auth:sanctum', 'throttle:heavy-operations'])->group(function () {
    Route::post('/ai/generate', [AiController::class, 'generate']);
});

Returning Useful Rate Limit Headers

Laravel automatically adds X-RateLimit-Limit and X-RateLimit-Remaining headers. When the limit is hit, it returns a 429 Too Many Requests with a Retry-After header. Make sure your API clients handle this gracefully.

If you want to expose remaining limits proactively, you can add them manually in a middleware or global response macro — but for most APIs, the defaults are sufficient.

API Versioning

This is where teams argue forever. URI versioning (/api/v1/) vs. header versioning (Accept: application/vnd.api+json;version=1). For most teams, URI versioning wins on practicality — it's visible, cacheable, and easy to test in a browser.

Route Structure

routes/
  api/
    v1.php
    v2.php
app/Http/Controllers/
  Api/
    V1/
      UserController.php
      ProductController.php
    V2/
      UserController.php

In routes/api.php:

Route::prefix('v1')->name('api.v1.')->group(base_path('routes/api/v1.php'));
Route::prefix('v2')->name('api.v2.')->group(base_path('routes/api/v2.php'));

Sharing Logic Between Versions

Don't duplicate business logic. Put it in services or actions, and call the same layer from both versioned controllers:

// app/Actions/GetUserProfileAction.php

class GetUserProfileAction
{
    public function execute(User $user): array
    {
        return [
            'id'    => $user->id,
            'name'  => $user->name,
            'email' => $user->email,
        ];
    }
}

V1 and V2 controllers both inject and use GetUserProfileAction. The V2 controller might transform the output differently, but the core query and business rules live in one place.

Versioned API Resources

Laravel's API Resources are ideal here:

// app/Http/Resources/V1/UserResource.php
class UserResource extends JsonResource
{
    public function toArray(Request $request): array
    {
        return [
            'id'   => $this->id,
            'name' => $this->name,
        ];
    }
}

// app/Http/Resources/V2/UserResource.php
class UserResource extends JsonResource
{
    public function toArray(Request $request): array
    {
        return [
            'id'        => $this->id,
            'full_name' => $this->name,   // renamed field in v2
            'avatar'    => $this->avatar_url,
        ];
    }
}

This keeps your transformations clean and isolated per version.

Consistent Error Responses

Nothing frustrates API consumers more than inconsistent error shapes. Standardise using Laravel's exception handler:

// app/Exceptions/Handler.php (or bootstrap/app.php in L11)

$exceptions->render(function (\Illuminate\Validation\ValidationException $e, Request $request) {
    if ($request->expectsJson()) {
        return response()->json([
            'message' => 'Validation failed',
            'errors'  => $e->errors(),
        ], 422);
    }
});

$exceptions->render(function (\Illuminate\Auth\AuthenticationException $e, Request $request) {
    if ($request->expectsJson()) {
        return response()->json(['message' => 'Unauthenticated'], 401);
    }
});

Every error, every time, returns the same JSON shape. Clients can rely on it.

A Note on Real-World API Projects

The patterns above aren't theoretical — they're pulled directly from production projects. When building APIs for clients in the region (the kind of multi-tenant SaaS and e-commerce platforms common in the UAE market), the combination of Sanctum for auth, granular rate limiters, and clean URI versioning consistently proves reliable and maintainable. If you're curious about how these patterns fit into larger Laravel architecture decisions, you can visit website to see how we approach these builds at HanzWeb.

Conclusion

Building a Laravel API that's actually production-ready means thinking beyond the happy path. Sanctum handles authentication cleanly without the overhead of OAuth when you don't need it. Custom rate limiters let you protect different endpoints differently — a blunt global throttle is rarely the right answer. And URI versioning, backed by shared action classes and versioned API Resources, gives you a clear upgrade path without breaking existing clients.

The three pillars — authentication, rate limiting, versioning — aren't optional extras. They're the floor, not the ceiling, of a professional API. Nail these, and you've got a solid foundation to build anything on top of.

DEV Community: Marcc Atayde

Progressive Web Apps in 2025: A Production-Focused Guide to Service Workers, Caching, and the Install Experience

What a PWA Actually Is (Past the Marketing)

The Manifest: More Than name and icons

Service Workers: The Lifecycle Is the Hard Part

Caching Strategies: Match the Strategy to the Resource

Background Sync for Offline Write Operations

Safari: The Reality Check

Testing Your Service Worker

Conclusion

Migrating Legacy Websites to Modern Laravel: A Practical, Battle-Tested Guide

Why Incremental Migration Beats the Big Bang Rewrite

Step 1: Audit Before You Touch Anything

Step 2: Stand Up Laravel Alongside the Legacy App

Step 3: Shared Session State

Step 4: Wrap the Legacy Database in Eloquent Models

Step 5: Migrate Routes Module by Module

Step 6: Schema Migration — When You're Ready

Step 7: The Final Cutover

Hard-Won Opinions From Production

Conclusion

Site Speed and Search Rankings: Real Benchmarks, Core Web Vitals, and the Code Changes That Actually Move the Needle

Why Speed Is a Ranking Signal Worth Taking Seriously

Diagnosing Real Problems: Beyond Lighthouse Scores

Fixing LCP: The Image Pipeline

TTFB: The Server-Side Problem Nobody Wants to Fix

Fixing INP: JavaScript Execution Budget

CLS: The Invisible UX Killer

Putting It Together: A Prioritisation Framework

Conclusion

Laravel Livewire Wire:Model Deep Dive: Reactivity, Debouncing, and Lazy Binding Explained

How wire:model Actually Works

The Modifier Toolkit

wire:model.live — Explicit Real-Time Binding

wire:model.lazy — Update on Blur

wire:model.debounce — Throttle Live Updates

wire:model.defer — Batch Updates on Form Submit

Choosing the Right Modifier

Nested Object Binding

Debugging Wire:Model Issues

Real-World Context: Why This Matters at Scale

Conclusion

Laravel API Security in Depth: Sanctum Tokens, Granular Rate Limiting, and Multi-Version Routing

Authentication with Laravel Sanctum: Scopes and Token Abilities

Creating Tokens with Abilities

Checking Abilities in Controllers

Granular Rate Limiting That Actually Makes Sense

Defining Named Limiters

Applying Limiters to Route Groups

API Versioning Without the Chaos

Folder and Namespace Structure

Route Files

Sharing Logic Between Versions with Base Controllers

API Resources: Your Contract with Consumers

Practical Considerations for Production

Conclusion

Building Intelligent Chatbots with RAG and Vector Databases: A Developer's Practical Guide

What Is RAG and Why Does It Matter?

Setting Up the Stack

Step 1: Ingesting and Chunking Documents

Step 2: Storing Embeddings in Qdrant

Step 3: The RAG Query Pipeline

Wiring It Up with a Livewire Component

Improving Retrieval Quality

Hybrid Search

Re-ranking

Metadata Filtering

Real-World Considerations

Conclusion

Why Dubai Businesses Need Custom Web Applications in 2026: A Developer's Honest Take

The Off-the-Shelf Problem Nobody Talks About

Where Generic Platforms Hit the Wall

1. Arabic RTL + Bilingual Logic Is Not a Theme Switch

2. UAE Government API Integrations

3. Performance Under Regional Infrastructure Conditions

The Real Cost Calculation

What "Custom" Actually Means in Practice

When Off-the-Shelf Is Still the Right Answer

Conclusion

Laravel Queue Workers: Processing Background Jobs at Scale

The Manifest: More Than `name` and `icons`

How `wire:model` Actually Works

`wire:model.live` — Explicit Real-Time Binding

`wire:model.lazy` — Update on Blur

`wire:model.debounce` — Throttle Live Updates

`wire:model.defer` — Batch Updates on Form Submit