DEV Community: Sepehr Mohseni

AI Changed the Industry, But Not Why I Loved Computers

Sepehr Mohseni — Tue, 17 Mar 2026 09:47:20 +0000

I wrote this because I was drunk and felt nostalgic and also scared for future of my career.

There was a time when computers felt magical in a very quiet way.

Not because they were smart.

Because they were mysterious.

Before feeds got loud. Before every skill became a market. Before every hobby got turned into content, a side hustle, or a career path, there was just the machine and your curiosity.

A lot of us did not start with code.

We started with wonder.

We started by clicking things we did not understand.

Opening folders we had no business opening.

Changing settings just to see what would happen.

Installing things we should not have installed.

Breaking something, panicking, then fixing it and feeling like a genius for the rest of the night.

We learned computers the way kids learn cities: by getting lost in them.

There were places inside a computer that felt almost sacred when you were young. Control Panel. BIOS. Device Manager. Registry Editor. Even the names sounded important. Dangerous, maybe. Which only made them more interesting.

Every mistake felt huge.

Every fix felt earned.

And somewhere in all of that, something happened to us.

We got attached.

Not to “the industry.”

Not to personal branding.

Not to productivity culture.

Not even to programming, at first.

We fell in love with computers.

With the feeling that there was always something underneath.

Another layer.

Another explanation.

Another hidden door.

It felt like the machine was not just a tool. It felt like a place.

And I think that is what many developers are actually nostalgic for when they talk about the old days.

Not just old games.

Not just old websites.

Not just old hardware, forums, or operating systems.

We miss the version of ourselves that met technology before the world told us what it was for.

Before it became a job.

Before it became a race.

Before it became comparison.

Before it became “keep up or get left behind.”

Now we are in the AI era, and the feeling around computers has changed again.

For the first time in a long time, a lot of people are not looking at computers as something to explore.

They are looking at them as something that might replace them.

And honestly, I understand that fear.

When every week brings a new model, a new demo, a new thread explaining why your job is about to disappear, it does something to your relationship with the thing you once loved.

It makes you defensive.

It makes you tired.

It makes you wonder whether the craft still matters.

Whether the hours you spent learning, debugging, building, and slowly understanding things will still mean anything in a world that can generate in seconds what used to take you all day.

That feeling is real.

But I do not think AI taking over the conversation means it takes over the reason we were here in the first place.

Because most of us did not fall in love with computers because they made us efficient.

We loved them because they made us curious.

We loved the process.

The late nights.

The strange bugs.

The tiny victories nobody else would understand.

The feeling of making something work and knowing why it worked.

That does not disappear just because a machine can autocomplete more than it used to.

If anything, this whole moment has revealed something important:

A lot of us were never here just to produce code.

We were here because we like thinking.

We like building.

We like understanding systems.

We like making invisible things real.

We like the feeling of being in conversation with a machine, even when that conversation is frustrating.

AI changes the tools.

It does not erase the instinct.

And maybe that is why, for all the noise, a lot of developers are still here. Still building. Still opening laptops late at night. Still caring more than they admit.

Because beneath the fear, beneath the hype, beneath the endless hot takes, there is still something older than all of this.

A kid in front of a screen.

Clicking around.

Trying to understand what this thing can do.

Feeling confused and amazed at the same time.

That feeling matters more than the headlines do.

Maybe AI will automate some parts of the work.

Maybe it will change the shape of the career.

Maybe it will force all of us to adapt in ways we did not ask for.

But it cannot retroactively take away the love.

It cannot erase the nights you spent figuring things out.

It cannot erase the part of your brain that lights up when a problem finally makes sense.

It cannot erase the joy of making something real from almost nothing.

And maybe that is what I keep coming back to lately:

Computers used to feel magical because they opened worlds.

Maybe the job now is not to panic over whether the world changed.

Maybe the job is to stay close to the part of yourself that wanted to enter it in the first place.

Not for status.

Not for content.

Not even for certainty.

Just for that old feeling.

Curiosity.

Wonder.

Possibility.

The machine may be different now.

But somewhere under all the noise, I think many of us are still here for the same reason we were as kids:

Because this stuff still feels alive.

Modern Laravel Mastery: Advanced Features, Clean Architecture, Testing & Blazing Performance in Laravel 12+

Sepehr Mohseni — Wed, 25 Feb 2026 06:30:01 +0000

Laravel has evolved dramatically in recent years. Laravel 11 and 12 deliver a slimmer skeleton, explicit bootstrapping, powerful query improvements, native modern starter kits, and first-party high-performance tools that let you write cleaner, more maintainable, and lightning-fast applications. This guide dives into very advanced, modern, and often lesser-known practices every serious Laravel developer should master in 2026.

Laravel 12+ Features You Should Use Right Now

`nestedWhere()` – Clean Complex Queries Without Closures (Laravel 12)

No more ugly nested closures for mixed AND/OR conditions.

<?php
// Laravel 12+
$products = DB::table('products')
    ->where('status', 'active')
    ->nestedWhere('price', '<', 1000, 'or', 'discount', '>', 30)
    ->where('stock', '>', 0)
    ->get();

// Equivalent to the old messy version:
$products = DB::table('products')
    ->where('status', 'active')
    ->where(function ($query) {
        $query->where('price', '<', 1000)
              ->orWhere('discount', '>', 30);
    })
    ->where('stock', '>', 0)
    ->get();

nestedWhere() dramatically improves readability for real-world filtering logic (price ranges + discounts + stock). Chain as many as you need.

UUID / ULID Primary Keys (Built-in Since Laravel 9, Perfected in 11+)

Stop using auto-increment IDs in distributed systems.

<?php
use Illuminate\Database\Eloquent\Concerns\HasUuids;
use Illuminate\Database\Eloquent\Concerns\HasUlids;

class Order extends Model
{
    use HasUuids; // or HasUlids for lexicographically sortable

    // Optional: ordered UUIDs
    public function newUniqueId(): string
    {
        return (string) Str::orderedUuid();
    }
}

ULIDs are perfect for sharded databases and time-based sorting without exposing sequential IDs.

Prunable & MassPrunable Models – Automatic Database Cleanup

<?php
use Illuminate\Database\Eloquent\Prunable;
use Illuminate\Database\Eloquent\MassPrunable;
use Illuminate\Database\Eloquent\Builder;

class TemporaryUpload extends Model
{
    use MassPrunable; // faster, no events fired

    public function prunable(): Builder
    {
        return static::where('created_at', '<=', now()->subDays(7));
    }
}

Schedule it:

// app/Console/Kernel.php or routes/console.php
Schedule::command('model:prune')->daily();

Attribute-Based Local Scopes (Laravel 10.20+ / 11+)

<?php
use Illuminate\Database\Eloquent\Attributes\Scope;
use Illuminate\Database\Eloquent\Builder;

class Post extends Model
{
    #[Scope]
    public function published(Builder $query): void
    {
        $query->where('published_at', '<=', now())
              ->where('is_draft', false);
    }
}

// Usage
Post::published()->get();

Model Replication (Lesser-Known Gem)

$order = Order::find(1);
$copy = $order->replicate(['total', 'paid_at']); // exclude sensitive fields
$copy->save();

Modern Architecture Patterns in Laravel 12+

Repository + Service Layer (Still King in 2026)

<?php
// app/Repositories/OrderRepository.php
interface OrderRepositoryInterface
{
    public function createWithItems(CreateOrderDTO $dto): Order;
}

// app/Services/OrderService.php
class OrderService
{
    public function __construct(
        private readonly OrderRepositoryInterface $repository,
        private readonly InventoryService $inventory,
    ) {}

    public function create(CreateOrderDTO $dto): Order
    {
        return DB::transaction(fn () => $this->repository->createWithItems($dto));
    }
}

Data Transfer Objects (DTOs) with Constructor Property Promotion + Readonly

<?php
namespace App\Data;

readonly class CreateOrderDTO
{
    public function __construct(
        public readonly int $userId,
        public readonly Collection $items, // collection of OrderItemDTO
        public readonly ?string $notes = null,
    ) {}

    public static function fromRequest(Request $request): self
    {
        return new self(
            userId: $request->user()->id,
            items: OrderItemDTO::collect($request->validated('items')),
            notes: $request->validated('notes'),
        );
    }
}

Combine with Spatie's laravel-data package for even more power (validation, casting, pagination) – the de-facto standard in 2026.

Testing Best Practices – Pest is Default in Laravel 11+

Pest Unit Tests (Clean & Expressive)

<?php
// tests/Unit/OrderServiceTest.php
it('creates order and decrements stock', function () {
    $user = User::factory()->create();
    $product = Product::factory()->create(['stock' => 10]);

    $dto = new CreateOrderDTO(
        userId: $user->id,
        items: collect([new OrderItemDTO($product->id, 2)])
    );

    $order = app(OrderService::class)->create($dto);

    expect($order)
        ->toBeInstanceOf(Order::class)
        ->and($product->fresh()->stock)->toBe(8);
});

it('throws when stock insufficient')->throws(InsufficientStockException::class, function () {
    // ...
});

Feature Tests with RefreshDatabase

<?php
// tests/Feature/OrdersApiTest.php
it('allows authenticated user to create order', function () {
    $user = User::factory()->create();
    $product = Product::factory()->create(['stock' => 5]);

    $response = $this->actingAs($user)
        ->postJson('/api/orders', [
            'items' => [['product_id' => $product->id, 'quantity' => 2]],
        ]);

    $response->assertCreated();
    expect($product->fresh()->stock)->toBe(3);
});

Performance Optimization – Octane Changes Everything

Laravel Octane (Swoole / RoadRunner / FrankenPHP)

composer require laravel/octane
php artisan octane:install
php artisan octane:start --server=frankenphp --watch

Concurrent Tasks (True Parallelism)

use Laravel\Octane\Facades\Octane;

[$users, $products, $orders] = Octane::concurrently([
    fn () => User::with('orders')->get(),
    fn () => Product::where('featured', true)->get(),
    fn () => Order::recent()->get(),
]);

Octane Cache & Tables (In-Memory, Shared Across Workers)

// config/octane.php
'tables' => [
    'leaderboard:5000' => ['user_id' => 'int', 'score' => 'int'],
],

// Usage
Octane::table('leaderboard')->set('user:123', ['user_id' => 123, 'score' => 9999]);

// Interval cache (auto-refreshes)
Cache::store('octane')->interval('daily-stats', fn () => calculateStats(), seconds: 86400);

Ticks for Background Work

Octane::tick('cleanup', fn () => TemporaryUpload::prune())
    ->seconds(60)
    ->immediate();

Octane + FrankenPHP is the 2026 gold standard – HTTP/3, zero-config HTTPS, and 10-100x throughput compared to traditional PHP-FPM.

Conclusion

Modern Laravel (v10–12) is no longer "just an MVC framework." It’s a full-stack powerhouse with explicit bootstrapping, first-party real-time (Reverb), page-based routing (Folio), functional components (Volt), and production-grade performance (Octane).

Key Takeaways:

Use nestedWhere(), UUID/ULID, Prunable models, and attribute scopes
Embrace DTOs + Service Layer + Repository for maintainable code
Write tests in Pest – it’s faster and more enjoyable
Deploy with Octane (FrankenPHP recommended) for production
Leverage new starter kits with Volt + Flux + shadcn/ui for rapid full-stack development

Start upgrading today. Laravel 12+ is the most developer-friendly version yet – and the performance gains with Octane will make you wonder how you ever lived without it.

Platform engineering internals: building an Internal Developer Platform (IDP) for your backend teams

Sepehr Mohseni — Wed, 11 Feb 2026 15:50:00 +0000

Eight months ago, our backend team of 10 engineers was drowning in tickets:

“I need a staging environment.”

“Can someone give me access to production logs?”

“How do I deploy my feature branch?”

Every request meant a Jira ticket, a wait for the platform team, and another context switch for everyone involved.

Today, those same engineers spin up preview environments from pull requests, deploy to staging with a single command, and access logs through a self-service portal. The platform team went from firefighting to building. We reduced environment provisioning time from 2–3 days to ~11 minutes.

This is what building an Internal Developer Platform (IDP) looks like in practice — not the vendor pitch version, but the messy reality of getting there.

Why IDPs Are Becoming More Essential

An Internal Developer Platform (IDP) is a self-service interface that abstracts the complexity of infrastructure, deployment, and environment management, giving developers a unified way to do their work without deep knowledge of low-level details.

It exists to reduce cognitive load and increase engineering velocity.

What a Good IDP Actually Looks Like

A well-designed IDP has five core capabilities that enable developer autonomy while enforcing consistency and governance.

1. Self-Service Environment Provisioning

Developers should be able to spin up feature and test environments without platform team tickets.

# Developer runs: idp env:create --name=feature-payments --from=staging
name: feature-payments
source_env: staging
owner: alice@company.com
ttl: 7d
resources:
  namespace: feature-payments-alice
  database: pg-feature-payments
  redis: redis-feature-payments
  secrets: copied from staging vault

The actual provisioning is handled by infrastructure tooling, but developers interact through a simple CLI or portal.

2. Deployment Pipelines as Code

Every service should deploy the same way using standardized pipelines.

# .idp/deploy.yaml in every repo
service:
  name: payments-api
  team: payments

deploy:
  strategy: canary
  canary:
    - weight: 10
      pause: 5m
    - weight: 50
      pause: 10m
    - weight: 100

  healthcheck:
    path: /health
    interval: 10s
    threshold: 3

  rollback:
    auto: true
    on_error_rate: ">1%"

Developers declare intent. The platform generates the CI/CD, rollout logic, and policies.

3. Secrets and RBAC Without Tickets

Access to production resources should follow role-based rules, not manual approvals.

class SecretAccessService
{
    public function requestAccess(string $userId, string $secretPath, string $reason, int $duration)
    {
        if ($this->isServiceOwner($userId, $secretPath) ||
            $this->belongsToUserTeam($userId, $secretPath)) {
            return $this->grantAccess($userId, $secretPath, $duration);
        }

        return $this->createApprovalWorkflow($userId, $secretPath, $reason, $duration);
    }
}

Most access requests can be auto-approved based on ownership and team metadata.

4. Observability Access

Developers need logs, metrics, and traces scoped to what they own.

teams:
  - name: payments
    members: [alice, bob, carol]
    views:
      dashboards:
        - payments-*
      logs:
        paths:
          - namespace=payments-*

If you own the service, you see its data. No tickets required.

5. Service Catalog With Ownership Metadata

Knowing who owns what and what depends on what is critical as systems scale.

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payments-api
spec:
  type: service
  owner: team-payments
  dependencies:
    - component: users-api
    - component: notifications-service

This powers on-call routing, impact analysis, and onboarding.

Build vs. Buy: An Honest Assessment

Build When

You have 500+ engineers
Your infrastructure is custom or legacy
You want full control over developer experience

Buy or Adopt Open Source When

You have 50–200 engineers
You are on standard cloud infrastructure
The 80% solution is sufficient
You need to move quickly

Common building blocks:

Backstage (portal and catalog)
Crossplane or Terraform (infrastructure)
Argo CD / Rollouts (deployments)
OPA (policy guardrails)

A Phased Approach to Building Your IDP

Phase 1: Discover (Weeks 1–4)

Interview developers
Audit ticket queues
Map provisioning and deployment flows

This reveals where the real pain is.

Phase 2: Self-Service Basics (Weeks 5–12)

Automate:

Environment provisioning
Deployment pipelines
Access to secrets and logs

Phase 3: Golden Paths (Weeks 13–20)

Create templates and scaffolding so developers start with best practices by default.

Phase 4: Observability & Cost (Weeks 21–32)

Provide visibility into:

Logs, metrics, traces
Deployment trends
Environment usage
Cost allocation

Common Failures and How to Avoid Them

❌ Building Portals First

UI without automation is useless. Build APIs and CLI first.

❌ Ignoring Adoption

Deprecate old workflows. Track who is still using them and help migrate.

❌ Security Holes in Self-Service

Enforce policies from day one. Self-service must include guardrails.

Measuring Success

Metric	Before	After
Environment provisioning time	2–3 days	~11 minutes
Deployment frequency	~2/week	~8/week
Infrastructure ticket volume	~120/mo	~18/mo
Time to first deploy (new hire)	~5 days	~4 hours

These improvements reflect real gains in developer productivity and system reliability.

Conclusion

An Internal Developer Platform is not a project — it’s an ongoing capability.

Focus on:

Real developer pain points
Automating high-toil workflows
Standardizing environments and deployments
Providing self-service interfaces
Treating the platform as a product for developers

Done right, an IDP turns infrastructure friction into engineering velocity.

Incident response & blameless post-mortems: writing better runbooks and SLO/SLI definitions

Sepehr Mohseni — Tue, 03 Feb 2026 17:02:00 +0000

Our checkout service went down at 2 AM on a Friday. By the time we got it back, we'd lost six hours of sales during a promotional weekend. The technical cause was a database connection pool exhaustion. The real cause was that we had no runbook for this failure mode, no clear escalation path, and our monitoring didn't alert until users were already seeing errors.

The postmortem was brutal. But it was also the turning point. We stopped treating incidents as fires to extinguish and started treating reliability as an engineering discipline.

This article covers what we learned: how to define SLOs that actually matter, write runbooks that get used, run incidents without chaos, and conduct postmortems that prevent recurrence.

SLOs, SLIs, and Error Budgets: Getting Them Right

Most teams either have no SLOs or have fake ones — numbers picked from the air that don’t connect to user experience or engineering decisions.

Good SLOs change how you prioritize work. If your error budget is healthy, ship features. If it's burning, focus on reliability.

SLIs: What You Actually Measure

A Service Level Indicator (SLI) reflects user experience, not server health.

Bad SLIs:

CPU utilization
Memory usage
Number of pods running

Good SLIs:

Request success rate (non-5xx / total)
Request latency at p99
Data freshness

Availability SLI:

sum(rate(http_requests_total{status!~"5.."}[5m])) 
/ 
sum(rate(http_requests_total[5m]))

Latency SLI:

sum(rate(http_request_duration_seconds_bucket{le="0.2"}[5m]))
/
sum(rate(http_request_duration_seconds_count[5m]))

SLOs: Your Target

SLO	Allowed Downtime/Month	Allowed Errors (1M requests)
99%	7.2 hours	10,000
99.5%	3.6 hours	5,000
99.9%	43.8 minutes	1,000
99.95%	21.9 minutes	500
99.99%	4.3 minutes	100

Our approach:

Checkout / Auth: 99.95%, p99 < 200ms
Internal APIs: 99.9%, p99 < 500ms
Batch systems: 99.5%

Start lower. Tighten later.

SLOs Based on User Journeys

Users care about journeys, not services.

journeys:
  - name: checkout
    slo:
      availability: 99.95%
      latency_p99: 3s
    components:
      - api-gateway
      - auth-service
      - cart-service
      - inventory-service
      - payments-service
      - order-service
    measurement:
      endpoint: /api/v1/checkout/health
      rum_event: checkout_completed

Error Budgets: Making SLOs Actionable

thresholds:
  - budget_remaining: 50%
    actions:
      - notify: slack
  - budget_remaining: 25%
    actions:
      - freeze: non_critical_deployments
  - budget_remaining: 10%
    actions:
      - freeze: all_deployments
      - meeting: reliability_review
  - budget_remaining: 0%
    actions:
      - focus: reliability_only

Implementing SLO Monitoring

slos:
  - name: requests-availability
    objective: 99.95
    sli:
      events:
        error_query: sum(rate(http_requests_total{status=~"5.."}[{{.window}}]))
        total_query: sum(rate(http_requests_total[{{.window}}]))

Writing Runbooks That Actually Get Used

Good runbooks are:

Scannable
Actionable
Tested

Runbook Structure

# Runbook: Payments API High Error Rate

## Detection
Alert: PaymentsAPIHighErrorRate

## Step 1: Check provider status
curl -s https://status.stripe.com/api/v2/summary.json

## Step 2: Check recent deploys
kubectl rollout history deployment/payments-api

## Step 3: Rollback if needed
kubectl rollout undo deployment/payments-api

## Step 4: Check DB pool
curl http://payments-api/debug/metrics | grep db_pool

Testing Runbooks (PHP / Laravel Example)

public function testDatabaseConnectionExhaustionRunbook(): void
{
    // Simulate connection exhaustion
    $this->simulateDbPoolExhaustion();

    // Verify alert condition
    $metrics = $this->fetchMetrics('/debug/metrics');
    $this->assertLessThan(5, $metrics['db_pool_available']);

    // Apply mitigation
    $this->scaleServiceReplicas(10);

    // Verify recovery
    $this->assertTrue($this->serviceRecovered());
}

Incident Response: A Structured Approach

Severity Levels

SEV1: Complete outage or data loss
SEV2: Major degradation
SEV3: Minor impact

Incident Roles

Incident Commander — coordinates
Tech Lead — debugs
Comms Lead — communicates

Incident Channel Template

🔴 INCIDENT: Checkout Errors

Severity: SEV2
Impact: Success rate 82%

Roles:
IC: @alice
Tech: @bob
Comms: @carol

Timeline:
14:32 Alert fired
14:40 Stripe returning 503s
14:45 Circuit breaker engaged
15:15 Resolved

Incident Automation (PHP)

class IncidentBot
{
    public function declareIncident(array $data): Incident
    {
        $incident = Incident::create([
            'title' => $data['title'],
            'severity' => $data['severity'],
            'status' => 'investigating',
        ]);

        $this->createSlackChannel($incident);
        $this->notifyPagerDuty($incident);

        return $incident;
    }

    public function resolveIncident(Incident $incident): void
    {
        $incident->update(['status' => 'resolved']);
        $this->schedulePostmortem($incident);
    }
}

Blameless Postmortems

Don’t ask: Who caused this?
Ask: What allowed this?

Postmortem Template

## Summary
Checkout degraded for 43 minutes.

## Root Cause
Circuit breaker threshold too high.

## Action Items
| Action | Owner | Deadline |
|--------|-------|----------|
| Lower threshold | @bob | Jan 22 |
| Add alert | @alice | Jan 23 |

Tracking Action Items (PHP)

class ActionItemTracker
{
    public function weeklyDigest(): void
    {
        $overdue = ActionItem::overdue()->get()->groupBy('owner');

        foreach ($overdue as $owner => $items) {
            $this->notifyOwner($owner, $items);
        }
    }
}

Measuring Reliability Improvement

Metric	Before	After
MTTR	4 hours	35 min
Repeat incidents	4/q	1/q
Error budget remaining	12%	58%

Conclusion

Reliability is a discipline:

SLOs tell you when things are wrong
Runbooks help you fix them
Incident roles prevent chaos
Postmortems prevent recurrence

Key takeaways:

Define SLOs around journeys
Use error budgets to guide decisions
Write actionable runbooks
Test runbooks regularly
Keep incidents structured
Keep postmortems blameless
Track action items relentlessly

Building AI-native backends – RAG pipelines, function calling, prompt versioning, LLM observability

Sepehr Mohseni — Wed, 28 Jan 2026 12:54:00 +0000

Two months ago, our internal knowledge base chatbot confidently told a support rep that our refund policy was “14 days, no questions asked.” Our real policy is 30 days with approval for larger amounts.

A $2,000 refund was processed based on that hallucination.

That was the moment we stopped treating LLM features like “smart text boxes” and started treating them like unreliable distributed systems that require real engineering.

This article is not about demos. It’s about what you have to build after the demo works.

The Reality of AI Backends

Traditional backends are deterministic.

Same input → same output.

AI backends are probabilistic.

Same input → slightly different output depending on context, model variance, and prompt structure.

This means:

You cannot trust outputs
You cannot trust retrieval
You cannot trust prompts
You cannot trust tool calls
You must observe everything

A production AI backend ends up looking like this:

API
│
AI Orchestrator
├─ Guardrails
├─ Router
├─ Rate limits
│
├─ RAG pipeline
├─ Function execution
└─ Direct generation
│
Observability + Evals

If you skip any of these layers, you will eventually ship a hallucination that costs money.

RAG Is Not “Chunk, Embed, Query”

The tutorial version of RAG is:

split text → embed → vector search → pass to LLM

That works in a notebook. It fails in production.

Real RAG needs:

Proper ingestion pipeline
Semantic chunking
Change detection
Hybrid retrieval (vector + keyword)
Reranking
Ongoing evaluation of retrieval quality

Ingestion in Laravel

Ingestion is a queued job, not a script.

You re see documents constantly. You re-embed only what changed.

class IngestDocuments
{
    public function handle(SourceInterface $source)
    {
        $documents = $source->fetch();

        foreach ($documents as $doc) {
            $hash = sha1($doc->content);

            if (Cache::get("doc_hash_{$doc->id}") === $hash) {
                continue;
            }

            $chunks = (new SemanticChunker())->chunk($doc->content);
            $embeddings = app(EmbeddingService::class)->embed($chunks);

            app(VectorStore::class)->upsert($doc->id, $chunks, $embeddings);

            Cache::put("doc_hash_{$doc->id}", $hash, now()->addDay());
        }
    }
}

The biggest quality improvement you will see is semantic chunking instead of fixed token splits.

Hybrid Retrieval Is Mandatory

Vector search misses exact matches like order IDs, SKUs, emails.

Keyword search misses meaning.

You need both.

class HybridRetriever
{
    public function search(string $query, int $limit = 8)
    {
        $vector = app(VectorStore::class)->search($query, $limit * 2);
        $keyword = app(KeywordSearch::class)->search($query, $limit * 2);

        return $this->mergeAndRank($vector, $keyword, $limit);
    }
}

Most hallucinations in RAG systems are actually retrieval failures, not model failures.

Generation With Grounded Context

What you pass to the model matters more than the model.

class RagResponder
{
    public function answer(string $question, array $chunks)
    {
        $context = collect($chunks)
            ->pluck('content')
            ->join("\n\n");

        $prompt = Prompt::load('rag-answer', 'v3');

        $response = app(LLM::class)->chat([
            ['role' => 'system', 'content' => $prompt->system],
            ['role' => 'user', 'content' => $prompt->fill([
                'context' => $context,
                'question' => $question,
            ])],
        ], temperature: 0.2, json: true);

        return $response;
    }
}

Low temperature. Structured output. Explicit context.

You are trying to reduce creativity, not increase it.

Function Calling Without Guardrails Will Burn You

Letting an LLM trigger backend actions without controls is equivalent to letting users hit internal APIs directly.

Every tool call must go through:

Authorization
Rate limiting
Audit logging
Optional approval

class ToolExecutor
{
    public function execute(string $tool, array $args, User $user)
    {
        $definition = ToolRegistry::get($tool);

        Gate::authorize($definition->ability, $user);

        if ($definition->needsApproval && !$user->isAdmin()) {
            throw new AuthorizationException();
        }

        RateLimiter::hit("tool:{$tool}", 60);

        $result = call_user_func($definition->handler, $args);

        AuditLog::create([
            'user_id' => $user->id,
            'tool' => $tool,
            'args' => $args,
            'result' => $result,
        ]);

        return $result;
    }
}

Refunds, account changes, billing operations — these must never be “just a function call.”

Prompts Are Code

Prompts change behavior more than code does.

They must be:

Versioned
Stored
Reviewed
Rolled out gradually

class Prompt extends Model
{
    protected $casts = ['variables' => 'array'];
}

class PromptManager
{
    public static function load(string $name, string $version): Prompt
    {
        return Prompt::where(compact('name', 'version'))->firstOrFail();
    }
}

Never hardcode prompts in PHP files.

You will want to change them without redeploying.

Observability Is Not Optional

You need to log, trace, and evaluate:

The user query
Retrieved chunks
Final prompt sent
Model output
Tokens and latency

Without this, you cannot debug hallucinations.

You also need automated evaluations that periodically ask:

“Is this answer actually grounded in the provided context?”

That’s how you catch issues before users do.

Caching and Cost Control

LLM calls are expensive and slow.

Cache deterministic calls by hashing inputs.

class CachedLLM
{
    public function chat(array $payload)
    {
        $key = hash('sha256', json_encode($payload));

        return Cache::remember($key, 3600, fn () =>
            app(LLM::class)->chat($payload)
        );
    }
}

Track cost daily and hard-stop if you exceed budget.

What Actually Prevents Incidents

After enough production incidents, you realize the real safeguards are:

Hybrid retrieval
Strict prompts
Guarded tool execution
Full tracing
Automated evals
Aggressive caching

Not model choice. Not fancy agents. Not frameworks.

Just engineering discipline applied to a probabilistic system.

Final Takeaway

A demo AI feature looks like magic.
A production AI system looks like a paranoid, over-engineered backend.

And that’s exactly what it needs to be.

From monolith to modular monolith to microservices: realistic migration patterns

Sepehr Mohseni — Wed, 21 Jan 2026 10:35:03 +0000

I’ve been part of three “microservices migrations” over the past decade. Two failed spectacularly. The third succeeded — but only because we stopped trying to build microservices and started trying to find real boundaries.

If you’re thinking the path is Monolith → Microservices and expecting it to be short and exciting, stop. The pragmatic path that works is:

Monolith → Modular Monolith → Selective Microservice Extraction

This article is a coherent, practical guide — written as a senior engineer would actually explain it — for teams who want the benefits of distribution without the debt. No buzzwords. No ideology. Just what to do, when to do it, how to test it, and when to stop.

TL;DR — The single sentence strategy

Refactor the codebase into honest modules, prove the boundaries at runtime inside one deployable (modular monolith), and only extract services where there is a clear operational, scaling, or organizational benefit. Use interfaces, contract tests, feature flags, shadow traffic and a strangler approach to reduce risk.

Why most migrations fail (and how to avoid each failure)

1. Over-decomposition too early.

Teams split because a class looks big, not because there’s a true bounded context. Result: a distributed monolith that is harder to change.

Avoid it by: draw boundaries with domain experts first, then refactor the monolith around those boundaries before extracting.

2. Distributed monolith hell.

Many small services calling each other synchronously create cascades and debugging nightmares.

Avoid it by: designing asynchronous communication patterns where possible, explicit APIs, and avoiding chatty sync RPC between services.

3. Team readiness gaps.

Microservices demand operational maturity (CI/CD, observability, SLOs, runbooks, service ownership). If you don’t have that, stay modular.

Avoid it by: improving platform and operational practices while still on a single deployable.

4. Shared database addiction.

“We’ll share the DB for now” becomes permanent coupling.

Avoid it by: extracting data ownership and contracts; require a migration plan and a dual-write strategy if you must split data.

Step 1 — Modularize the monolith first (the low-risk win)

The goal here is not perfection: it’s clarity. Make the boundaries explicit in your code and in runtime behavior.

What to do (practically):

Create bounded contexts inside the repo. Use namespaces and clear directory layout (example below).
Introduce repository interfaces (ports) and only allow other modules to depend on the interface, not concrete types.
Move infra code to the edges (persistence, HTTP, queues). Domain code should be pure.
Add module integration tests — prove the module API in process before you consider network extraction.

Example layout (Symfony):


src/
Catalog/
Domain/
Application/
Infrastructure/
UI/
Orders/
Domain/
Application/
Infrastructure/
UI/
Users/
Shared/

Why this matters: You learn the coupling cost up front. Fixes are cheap when everything’s in one repo and one process.

Interfaces and domain code — real examples (Symfony)

Keep domain logic independent and testable. Depend on interfaces.

// src/Catalog/Domain/ProductRepository.php
namespace App\Catalog\Domain;

interface ProductRepository
{
    public function findById(ProductId $id): ?Product;
    public function findByCategory(CategoryId $categoryId): array;
    public function save(Product $product): void;
}

// src/Catalog/Domain/Product.php
namespace App\Catalog\Domain;

class Product
{
    public function __construct(
        private ProductId $id,
        private string $name,
        private Money $price,
        private CategoryId $categoryId,
        private int $stock
    ) {}

    public function reserve(int $quantity): void
    {
        if ($this->stock < $quantity) {
            throw new \DomainException('Insufficient stock');
        }

        $this->stock -= $quantity;
    }
}

Practical rules:

One module’s Domain must never use another module’s Domain objects directly.
Use small, well-documented interfaces for cross-module calls.
Keep infrastructure implementations in Infrastructure and register them in the DI container (services.yaml) under interface types.

Step 2 — Strangler Fig pattern: extract incrementally and safely

Once the monolith is modular, you can start pulling functionality out behind a façade.

Key practices:

Put an API gateway / router in front (Traefik, Envoy, etc.) and route traffic per path.
Start by routing new or versioned paths to the new service.
Use feature flags to control who hits the new service.
Shadow traffic heavily to compare behavior before cutover.
Use an anti-corruption layer (ACL) to translate between old and new models.

Anti-corruption layer (Symfony example):

// src/Catalog/Infrastructure/LegacyProductAdapter.php
namespace App\Catalog\Infrastructure;

use Symfony\Contracts\HttpClient\HttpClientInterface;
use App\Catalog\Domain\Product;
use App\Catalog\Domain\ProductId;
use App\Catalog\Domain\CategoryId;
use App\Catalog\Domain\Money;

class LegacyProductAdapter
{
    public function __construct(
        private HttpClientInterface $client,
        private string $baseUrl
    ) {}

    public function getProduct(string $id): Product
    {
        $response = $this->client->request('GET', $this->baseUrl . '/legacy/products/' . $id);
        $data = $response->toArray();

        return new Product(
            new ProductId((string)$data['prod_id']),
            trim($data['prod_name']),
            new Money($data['price_cents'], 'USD'),
            new CategoryId((string)$data['cat_id']),
            $data['qty_on_hand']
        );
    }
}

Why ACLs matter: They prevent legacy shape from leaking into your new domain.

Feature flags and shadow traffic — the safety net

Use feature flags for progressive rollout and shadow traffic to validate responses without impacting users.

Feature flag example (LaunchDarkly client use is illustrative):

// src/Shared/FeatureFlags.php
namespace App\Shared;

class FeatureFlags
{
    public function __construct(private \LaunchDarkly\LDClient $client) {}

    public function useNewCatalogService(string $userId): bool
    {
        return $this->client->variation(
            'use-new-catalog-service',
            ['key' => $userId],
            false
        );
    }
}

Routing in controller (inject dependencies via DI):

// src/UI/Controller/ProductController.php
namespace App\UI\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\JsonResponse;

class ProductController extends AbstractController
{
    public function __construct(
        private \App\Shared\FeatureFlags $flags,
        private \App\Catalog\Infrastructure\LegacyProductAdapter $legacyService,
        private \App\Catalog\Client\CatalogClient $newCatalogClient
    ) {}

    public function getProduct(string $id): JsonResponse
    {
        $user = $this->getUser();
        $userId = $user ? $user->getId() : 'anon';

        if ($this->flags->useNewCatalogService($userId)) {
            $product = $this->newCatalogClient->getProduct($id);
        } else {
            $product = $this->legacyService->getProduct($id);
        }

        return $this->json($product);
    }
}

Shadow traffic: dispatch an async task to call the new service and diff results. Use Messenger to send the shadow request off the critical path.

$this->messageBus->dispatch(new ShadowProductCheckMessage($id, $product));

Data migrations: dual-write and the cutover plan

Principles:

Treat data as owned by a service. If you extract a service, its owned data should move with it (or be behind a stable API).
Dual-write during migration — write both old and new stores, but make legacy writes secondary (log and continue).
Consumers must be migrated one by one; avoid long periods of shared writes without a plan to remove them.

Dual-write example:

public function createOrder(CreateOrderRequest $request): Order
{
    $order = $this->orderRepository->save(Order::fromRequest($request));

    try {
        $this->legacySync->syncOrder($order); // best effort
    } catch (\Throwable $e) {
        $this->logger->warning('Failed to sync to legacy', ['orderId' => $order->getId(), 'err' => $e->getMessage()]);
    }

    return $order;
}

Cutover checklist:

Consumers migrated and passing contract tests
Shadow traffic shows parity
Feature flag at 100% for a sustained period
Legacy sync removed and monitored
Observability shows no regressions

Eventual consistency — design for it, don’t pretend otherwise

If you split data, you will get eventual consistency. Design for idempotency, retries, and clear user messaging (e.g., “price confirmed at checkout”).

Event-driven cache invalidation example:

class ProductPriceUpdatedEvent
{
    public function __construct(public string $productId, public int $newPrice) {}
}

class PriceUpdateHandler
{
    public function __invoke(ProductPriceUpdatedEvent $event)
    {
        $this->cache->delete($event->productId);
    }
}

Use durable event delivery (e.g., Kafka, RabbitMQ) between services; avoid fragile synchronous cross-service reads in hot paths.

Contract testing: catch integration errors early

Contract tests verify the consumer/provider contract without deploying both together. Pact PHP or a similar tool should be in CI for any boundary you extract.

Pact PHP (conceptual) test outline:

public function testCatalogContract()
{
    $pact = new PactBuilder();
    $pact->uponReceiving('a request for product 123')
         ->withRequest('GET', '/api/products/123')
         ->willRespondWith(200, ['id' => '123', 'name' => 'Widget', 'price' => 1999]);

    // verify consumer against mock provider
    $client = new CatalogClient($pact->getMockServerUrl());
    $product = $client->getProduct('123');

    $this->assertEquals('123', $product['id']);
}

Run consumer contract tests in the consumer repo CI; run provider verification in provider CI. This prevents many integration surprises.

Observability, SLOs and operational readiness

You cannot extract services you cannot observe.

Minimum production observability checklist:

Request traces (distributed tracing)
Per-service metrics: success rate, latency (p50/p95/p99), error rate
Alerting tied to SLOs, not arbitrary CPU thresholds
Dashboards for owners
Runbooks for common failures

SLO guidance: pick SLOs tied to user journeys (checkout end-to-end), not just per-service. That aligns incentives.

When to stop: the modular monolith is a valid destination

Not everything should be a microservice. Stay modular if:

Team < ~30 engineers and coordination is cheap
You don’t need different scaling profiles
You can deploy frequently and reliably
Compliance does not force isolation

Extraction is expensive: only do it where there is clear business value (scaling, compliance, independent ownership).

Migration timeline (practical, realistic)

A realistic, low-risk timeline for a medium codebase:

Months 0–2 — Discovery: map domains, interview product and engineers, identify high-velocity modules.
Months 2–6 — Modularization: reorganize code, add interfaces, write module tests, integrate CI for module boundaries.
Months 6–8 — First extraction: pick a small, well-bounded module (auth is common). Strangler Fig route, shadow traffic, canary, cutover.
Months 9–12 — More extractions: tackle modules where data and scale justify the work.
Month 13+ — Operate & evaluate: most modules often stay in the monolith; extract only when justified.

This is a marathon, not a sprint. The work you do while still in a monolith saves enormous refactor cost later.

Practical pitfalls and checks (operational checklist)

Before extracting a module, verify:

[ ] Clear domain boundaries agreed with product/SEs
[ ] Public interface documented and covered with tests
[ ] Metric coverage for consumer and provider
[ ] Contract tests in CI for both sides
[ ] Feature flags and shadow traffic in place
[ ] Runbooks and escalation paths for the new service
[ ] Data ownership plan (migration/dual-write/cutover)
[ ] Rollback and retry strategies defined

If any item is missing, postpone extraction and invest in the monolith refactor.

Final words — pragmatic, not dogmatic

Microservices are a tool, not a religion. The path that succeeds is slow, boring, and disciplined:

Stop rushing to network boundaries.
Modularize the monolith and learn the domain at code speed.
Extract only when the evidence (scaling, team ownership, compliance) is clear.
Use feature flags, shadow traffic, ACLs, and contract testing to reduce blast radius.
Invest heavily in observability and runbooks before you extract.

If you follow that, distribution becomes a tactical advantage rather than a long-term liability.

Advanced Tailwind CSS Techniques

Sepehr Mohseni — Tue, 20 Jan 2026 08:58:30 +0000

Tailwind CSS has transformed how we write CSS. Let's explore advanced techniques that will take your styling to the next level.

Custom Design System

Extend Tailwind with your own design tokens:

// tailwind.config.js
module.exports = {
  theme: {
    extend: {
      colors: {
        brand: {
          50: '#f0f9ff',
          100: '#e0f2fe',
          500: '#0ea5e9',
          900: '#0c4a6e',
        },
      },
      fontFamily: {
        display: ['Cal Sans', 'sans-serif'],
        body: ['Inter', 'sans-serif'],
      },
      spacing: {
        '18': '4.5rem',
        '88': '22rem',
      },
      animation: {
        'fade-in': 'fadeIn 0.5s ease-out',
        'slide-up': 'slideUp 0.5s ease-out',
      },
      keyframes: {
        fadeIn: {
          '0%': { opacity: '0' },
          '100%': { opacity: '1' },
        },
        slideUp: {
          '0%': { transform: 'translateY(20px)', opacity: '0' },
          '100%': { transform: 'translateY(0)', opacity: '1' },
        },
      },
    },
  },
};

A well-defined design system ensures consistency across your application and makes maintenance easier.

Component Patterns

Glass Morphism

<div class="rounded-2xl border border-white/10 bg-white/5 p-6 backdrop-blur-xl">
  <h3 class="text-xl font-semibold text-white">Glass Card</h3>
  <p class="mt-2 text-zinc-400">Beautiful frosted glass effect</p>
</div>

Gradient Borders

<div class="relative rounded-xl bg-gradient-to-r from-indigo-500 to-purple-500 p-[1px]">
  <div class="rounded-xl bg-zinc-900 p-6">
    <p class="text-white">Content with gradient border</p>
  </div>
</div>

Animated Gradient Background

<div class="animate-gradient bg-gradient-to-r from-indigo-500 via-purple-500 to-pink-500 bg-[length:200%_200%]">
  <span class="bg-clip-text text-transparent">Animated Gradient Text</span>
</div>

Group and Peer Modifiers

Style children based on parent state:

<div class="group rounded-xl border border-white/10 p-6 transition-all hover:border-indigo-500/50">
  <h3 class="text-white transition-colors group-hover:text-indigo-400">
    Hover the card
  </h3>
  <p class="text-zinc-400 transition-colors group-hover:text-zinc-300">
    Child elements respond to parent hover
  </p>
  <span class="opacity-0 transition-opacity group-hover:opacity-100">
    I appear on hover!
  </span>
</div>

Use group-hover, group-focus, and group-active to create complex interactive components without JavaScript.

Container Queries

Style based on container size, not viewport:

<div class="@container">
  <div class="flex flex-col @md:flex-row @lg:gap-8">
    <div class="@md:w-1/2">Responsive to container</div>
    <div class="@md:w-1/2">Not viewport</div>
  </div>
</div>

Dark Mode Strategies

Class-based (Recommended)

// tailwind.config.js
module.exports = {
  darkMode: 'class',
};

<div class="bg-white text-zinc-900 dark:bg-zinc-900 dark:text-white">
  Adapts to dark mode
</div>

System Preference

// tailwind.config.js
module.exports = {
  darkMode: 'media',
};

Performance Optimizations

Purge Unused Styles

// tailwind.config.js
module.exports = {
  content: [
    './app/**/*.{js,ts,jsx,tsx}',
    './components/**/*.{js,ts,jsx,tsx}',
  ],
};

Use Arbitrary Values Sparingly

<!-- ❌ Creates unique classes -->
<div class="w-[137px] h-[42px] mt-[13px]">

<!-- ✅ Use design system values -->
<div class="w-36 h-10 mt-3">

Custom Plugins

Create reusable utilities:

// tailwind.config.js
const plugin = require('tailwindcss/plugin');

module.exports = {
  plugins: [
    plugin(function({ addUtilities }) {
      addUtilities({
        '.text-gradient': {
          'background': 'linear-gradient(135deg, #6366f1, #a855f7)',
          '-webkit-background-clip': 'text',
          '-webkit-text-fill-color': 'transparent',
        },
        '.glass': {
          'background': 'rgba(255, 255, 255, 0.05)',
          'backdrop-filter': 'blur(10px)',
          'border': '1px solid rgba(255, 255, 255, 0.1)',
        },
      });
    }),
  ],
};

Responsive Design Patterns

Mobile-First Approach

<!-- Base styles for mobile, then scale up -->
<div class="p-4 md:p-6 lg:p-8 xl:p-10">
  <h1 class="text-2xl md:text-3xl lg:text-4xl xl:text-5xl">
    Responsive Typography
  </h1>
</div>

Responsive Grid

<div class="grid grid-cols-1 gap-6 sm:grid-cols-2 lg:grid-cols-3 xl:grid-cols-4">
  <!-- Cards automatically reflow -->
</div>

Typography Plugin

For beautiful prose styling:

<article class="prose prose-invert prose-lg max-w-none prose-headings:font-bold prose-a:text-indigo-400 prose-code:text-pink-400">
  <!-- Markdown content renders beautifully -->
</article>

Conclusion

Tailwind CSS is incredibly powerful when you understand its advanced features. These techniques will help you build more sophisticated, maintainable, and performant user interfaces.

React Performance Optimization: Advanced Techniques for Lightning-Fast Apps

Sepehr Mohseni — Sat, 17 Jan 2026 08:28:49 +0000

Performance is crucial for user experience and SEO. A slow React application can lead to higher bounce rates and lower conversion. This guide covers advanced techniques to optimize your React applications for maximum performance.

Understanding React's Rendering Behavior

Before optimizing, understand how React decides to re-render components:

// Every state change triggers a re-render of this component
// AND all its children
function ParentComponent() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <button onClick={() => setCount(c => c + 1)}>
        Count: {count}
      </button>
      <ExpensiveChild /> {/* Re-renders even though it doesn't use count! */}
    </div>
  );
}

React re-renders all child components when a parent re-renders, regardless of whether their props changed. This is the primary source of performance issues.

Memoization Techniques

React.memo for Component Memoization

Prevent unnecessary re-renders with React.memo:

import { memo } from 'react';

// Without memo - re-renders on every parent render
function ProductCard({ product, onAddToCart }) {
  console.log('ProductCard rendered');
  return (
    <div className="product-card">
      <img src={product.image} alt={product.name} />
      <h3>{product.name}</h3>
      <p>${product.price}</p>
      <button onClick={() => onAddToCart(product.id)}>
        Add to Cart
      </button>
    </div>
  );
}

// With memo - only re-renders when props change
const MemoizedProductCard = memo(ProductCard);

// Custom comparison function for complex props
const MemoizedProductCardCustom = memo(ProductCard, (prevProps, nextProps) => {
  return prevProps.product.id === nextProps.product.id &&
         prevProps.product.price === nextProps.product.price;
});

useMemo for Expensive Calculations

import { useMemo } from 'react';

function ProductList({ products, filters }) {
  // Without useMemo - recalculates on every render
  // const filteredProducts = products.filter(p => 
  //   p.category === filters.category && p.price <= filters.maxPrice
  // );

  // With useMemo - only recalculates when dependencies change
  const filteredProducts = useMemo(() => {
    console.log('Filtering products...');
    return products.filter(p => 
      p.category === filters.category && 
      p.price <= filters.maxPrice
    );
  }, [products, filters.category, filters.maxPrice]);

  // Expensive sorting operation
  const sortedProducts = useMemo(() => {
    return [...filteredProducts].sort((a, b) => {
      if (filters.sortBy === 'price') return a.price - b.price;
      if (filters.sortBy === 'name') return a.name.localeCompare(b.name);
      return 0;
    });
  }, [filteredProducts, filters.sortBy]);

  return (
    <div className="product-grid">
      {sortedProducts.map(product => (
        <ProductCard key={product.id} product={product} />
      ))}
    </div>
  );
}

useCallback for Stable Function References

import { useCallback, useState } from 'react';

function ShoppingCart() {
  const [items, setItems] = useState([]);

  // Without useCallback - new function on every render
  // const handleRemove = (id) => {
  //   setItems(items => items.filter(item => item.id !== id));
  // };

  // With useCallback - stable reference
  const handleRemove = useCallback((id) => {
    setItems(items => items.filter(item => item.id !== id));
  }, []); // Empty deps - function never changes

  const handleUpdateQuantity = useCallback((id, quantity) => {
    setItems(items => items.map(item => 
      item.id === id ? { ...item, quantity } : item
    ));
  }, []);

  return (
    <div>
      {items.map(item => (
        <CartItem
          key={item.id}
          item={item}
          onRemove={handleRemove}
          onUpdateQuantity={handleUpdateQuantity}
        />
      ))}
    </div>
  );
}

// CartItem can now be memoized effectively
const CartItem = memo(function CartItem({ item, onRemove, onUpdateQuantity }) {
  return (
    <div className="cart-item">
      <span>{item.name}</span>
      <input
        type="number"
        value={item.quantity}
        onChange={(e) => onUpdateQuantity(item.id, parseInt(e.target.value))}
      />
      <button onClick={() => onRemove(item.id)}>Remove</button>
    </div>
  );
});

Only use useMemo and useCallback when you have measured a performance problem. Premature optimization can make code harder to read without meaningful benefits.

Code Splitting and Lazy Loading

Route-Based Code Splitting

import { lazy, Suspense } from 'react';
import { BrowserRouter, Routes, Route } from 'react-router-dom';

// Lazy load route components
const Home = lazy(() => import('./pages/Home'));
const Products = lazy(() => import('./pages/Products'));
const ProductDetail = lazy(() => import('./pages/ProductDetail'));
const Checkout = lazy(() => import('./pages/Checkout'));
const Admin = lazy(() => import('./pages/Admin'));

function App() {
  return (
    <BrowserRouter>
      <Suspense fallback={<PageLoader />}>
        <Routes>
          <Route path="/" element={<Home />} />
          <Route path="/products" element={<Products />} />
          <Route path="/products/:id" element={<ProductDetail />} />
          <Route path="/checkout" element={<Checkout />} />
          <Route path="/admin/*" element={<Admin />} />
        </Routes>
      </Suspense>
    </BrowserRouter>
  );
}

function PageLoader() {
  return (
    <div className="flex items-center justify-center min-h-screen">
      <div className="animate-spin rounded-full h-12 w-12 border-b-2 border-indigo-500" />
    </div>
  );
}

Component-Level Code Splitting

import { lazy, Suspense, useState } from 'react';

// Heavy components loaded on demand
const RichTextEditor = lazy(() => import('./components/RichTextEditor'));
const ChartDashboard = lazy(() => import('./components/ChartDashboard'));
const ImageGallery = lazy(() => import('./components/ImageGallery'));

function ProductEditor({ product }) {
  const [showCharts, setShowCharts] = useState(false);

  return (
    <div>
      <h1>Edit Product</h1>

      {/* Editor loads when component mounts */}
      <Suspense fallback={<div>Loading editor...</div>}>
        <RichTextEditor 
          content={product.description}
          onChange={handleDescriptionChange}
        />
      </Suspense>

      {/* Charts only load when user clicks */}
      <button onClick={() => setShowCharts(true)}>
        Show Analytics
      </button>

      {showCharts && (
        <Suspense fallback={<div>Loading charts...</div>}>
          <ChartDashboard productId={product.id} />
        </Suspense>
      )}
    </div>
  );
}

Virtualization for Large Lists

Using react-window for Efficient Rendering

import { FixedSizeList as List } from 'react-window';
import AutoSizer from 'react-virtualized-auto-sizer';

function VirtualizedProductList({ products }) {
  const Row = ({ index, style }) => {
    const product = products[index];
    return (
      <div style={style} className="flex items-center p-4 border-b">
        <img 
          src={product.thumbnail} 
          alt={product.name}
          className="w-16 h-16 object-cover rounded"
        />
        <div className="ml-4">
          <h3 className="font-semibold">{product.name}</h3>
          <p className="text-gray-600">${product.price}</p>
        </div>
      </div>
    );
  };

  return (
    <div className="h-[600px] w-full">
      <AutoSizer>
        {({ height, width }) => (
          <List
            height={height}
            width={width}
            itemCount={products.length}
            itemSize={80}
          >
            {Row}
          </List>
        )}
      </AutoSizer>
    </div>
  );
}

Variable Size List for Dynamic Content

import { VariableSizeList as List } from 'react-window';
import { useRef, useCallback } from 'react';

function ChatMessages({ messages }) {
  const listRef = useRef();
  const rowHeights = useRef({});

  const getRowHeight = useCallback((index) => {
    return rowHeights.current[index] || 60;
  }, []);

  const setRowHeight = useCallback((index, size) => {
    rowHeights.current[index] = size;
    listRef.current?.resetAfterIndex(index);
  }, []);

  const Row = ({ index, style }) => {
    const rowRef = useRef();
    const message = messages[index];

    useEffect(() => {
      if (rowRef.current) {
        setRowHeight(index, rowRef.current.getBoundingClientRect().height);
      }
    }, [index, setRowHeight]);

    return (
      <div style={style}>
        <div ref={rowRef} className="p-4">
          <p className="font-semibold">{message.sender}</p>
          <p>{message.content}</p>
          <span className="text-xs text-gray-500">{message.timestamp}</span>
        </div>
      </div>
    );
  };

  return (
    <List
      ref={listRef}
      height={500}
      width="100%"
      itemCount={messages.length}
      itemSize={getRowHeight}
      estimatedItemSize={60}
    >
      {Row}
    </List>
  );
}

State Management Optimization

Avoiding Unnecessary Context Re-renders

import { createContext, useContext, useState, useMemo } from 'react';

// Split context by update frequency
const UserContext = createContext();
const UserActionsContext = createContext();

function UserProvider({ children }) {
  const [user, setUser] = useState(null);

  // Memoize actions to prevent re-renders
  const actions = useMemo(() => ({
    login: async (credentials) => {
      const user = await authService.login(credentials);
      setUser(user);
    },
    logout: () => {
      authService.logout();
      setUser(null);
    },
    updateProfile: async (data) => {
      const updated = await userService.update(data);
      setUser(updated);
    },
  }), []);

  return (
    <UserContext.Provider value={user}>
      <UserActionsContext.Provider value={actions}>
        {children}
      </UserActionsContext.Provider>
    </UserContext.Provider>
  );
}

// Components only subscribe to what they need
function UserAvatar() {
  const user = useContext(UserContext); // Only re-renders when user changes
  return <img src={user?.avatar} alt={user?.name} />;
}

function LogoutButton() {
  const { logout } = useContext(UserActionsContext); // Never re-renders!
  return <button onClick={logout}>Logout</button>;
}

Using Zustand for Efficient State

import { create } from 'zustand';
import { shallow } from 'zustand/shallow';

const useStore = create((set, get) => ({
  products: [],
  cart: [],
  filters: { category: 'all', maxPrice: 1000 },

  setProducts: (products) => set({ products }),

  addToCart: (product) => set((state) => ({
    cart: [...state.cart, { ...product, quantity: 1 }]
  })),

  updateFilters: (filters) => set((state) => ({
    filters: { ...state.filters, ...filters }
  })),

  // Computed values
  get cartTotal() {
    return get().cart.reduce((sum, item) => sum + item.price * item.quantity, 0);
  },
}));

// Select only needed state to prevent unnecessary re-renders
function CartIcon() {
  const itemCount = useStore((state) => state.cart.length);
  return <span className="badge">{itemCount}</span>;
}

function ProductFilters() {
  // Use shallow comparison for object selections
  const { filters, updateFilters } = useStore(
    (state) => ({ filters: state.filters, updateFilters: state.updateFilters }),
    shallow
  );

  return (
    <div>
      <select 
        value={filters.category}
        onChange={(e) => updateFilters({ category: e.target.value })}
      >
        <option value="all">All Categories</option>
        <option value="electronics">Electronics</option>
        <option value="clothing">Clothing</option>
      </select>
    </div>
  );
}

Image Optimization

Lazy Loading Images

function OptimizedImage({ src, alt, className }) {
  const [isLoaded, setIsLoaded] = useState(false);
  const [isInView, setIsInView] = useState(false);
  const imgRef = useRef();

  useEffect(() => {
    const observer = new IntersectionObserver(
      ([entry]) => {
        if (entry.isIntersecting) {
          setIsInView(true);
          observer.disconnect();
        }
      },
      { rootMargin: '100px' }
    );

    if (imgRef.current) {
      observer.observe(imgRef.current);
    }

    return () => observer.disconnect();
  }, []);

  return (
    <div ref={imgRef} className={`relative ${className}`}>
      {/* Placeholder */}
      {!isLoaded && (
        <div className="absolute inset-0 bg-gray-200 animate-pulse" />
      )}

      {/* Actual image */}
      {isInView && (
        <img
          src={src}
          alt={alt}
          className={`transition-opacity duration-300 ${
            isLoaded ? 'opacity-100' : 'opacity-0'
          }`}
          onLoad={() => setIsLoaded(true)}
          loading="lazy"
        />
      )}
    </div>
  );
}

Profiling and Measuring Performance

Using React DevTools Profiler

import { Profiler } from 'react';

function onRenderCallback(
  id,
  phase,
  actualDuration,
  baseDuration,
  startTime,
  commitTime
) {
  // Log slow renders
  if (actualDuration > 16) { // More than one frame (60fps)
    console.warn(`Slow render in ${id}:`, {
      phase,
      actualDuration: `${actualDuration.toFixed(2)}ms`,
      baseDuration: `${baseDuration.toFixed(2)}ms`,
    });
  }
}

function App() {
  return (
    <Profiler id="App" onRender={onRenderCallback}>
      <Header />
      <Profiler id="ProductList" onRender={onRenderCallback}>
        <ProductList />
      </Profiler>
      <Footer />
    </Profiler>
  );
}

Custom Performance Hooks

function useRenderCount(componentName) {
  const renderCount = useRef(0);

  useEffect(() => {
    renderCount.current += 1;
    console.log(`${componentName} rendered ${renderCount.current} times`);
  });
}

function useWhyDidYouUpdate(name, props) {
  const previousProps = useRef();

  useEffect(() => {
    if (previousProps.current) {
      const allKeys = Object.keys({ ...previousProps.current, ...props });
      const changedProps = {};

      allKeys.forEach(key => {
        if (previousProps.current[key] !== props[key]) {
          changedProps[key] = {
            from: previousProps.current[key],
            to: props[key],
          };
        }
      });

      if (Object.keys(changedProps).length) {
        console.log(`[${name}] Changed props:`, changedProps);
      }
    }

    previousProps.current = props;
  });
}

Conclusion

React performance optimization is about understanding the rendering lifecycle and applying the right techniques at the right time. Start by measuring with React DevTools Profiler, identify bottlenecks, and apply targeted optimizations.

Key takeaways:

Use React.memo, useMemo, and useCallback strategically
Implement code splitting for large applications
Virtualize long lists
Optimize state management to minimize re-renders
Always measure before and after optimization

Next.js SEO Optimization: Complete Guide to Ranking Higher

Sepehr Mohseni — Sat, 17 Jan 2026 08:26:58 +0000

SEO is crucial for any website's success. Next.js provides powerful tools for building SEO-friendly applications. This guide covers everything from basic metadata to advanced optimization techniques.

Metadata API in Next.js 15

Static Metadata

// app/page.tsx
import type { Metadata } from 'next';

export const metadata: Metadata = {
  title: 'Home | My Website',
  description: 'Welcome to my website. We offer the best products and services.',
  keywords: ['products', 'services', 'quality'],
  authors: [{ name: 'John Doe', url: 'https://johndoe.com' }],
  creator: 'John Doe',
  publisher: 'My Company',
  robots: {
    index: true,
    follow: true,
    googleBot: {
      index: true,
      follow: true,
      'max-video-preview': -1,
      'max-image-preview': 'large',
      'max-snippet': -1,
    },
  },
  openGraph: {
    type: 'website',
    locale: 'en_US',
    url: 'https://mywebsite.com',
    siteName: 'My Website',
    title: 'Home | My Website',
    description: 'Welcome to my website',
    images: [
      {
        url: 'https://mywebsite.com/og-image.jpg',
        width: 1200,
        height: 630,
        alt: 'My Website',
      },
    ],
  },
  twitter: {
    card: 'summary_large_image',
    title: 'Home | My Website',
    description: 'Welcome to my website',
    creator: '@johndoe',
    images: ['https://mywebsite.com/twitter-image.jpg'],
  },
  alternates: {
    canonical: 'https://mywebsite.com',
    languages: {
      'en-US': 'https://mywebsite.com/en',
      'fa-IR': 'https://mywebsite.com/fa',
    },
  },
};

export default function HomePage() {
  return <main>...</main>;
}

Always include Open Graph and Twitter Card metadata for better social media sharing previews.

Dynamic Metadata

// app/blog/[slug]/page.tsx
import type { Metadata } from 'next';
import { getPostBySlug } from '@/lib/posts';

interface Props {
  params: { slug: string };
}

export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const post = await getPostBySlug(params.slug);

  if (!post) {
    return {
      title: 'Post Not Found',
    };
  }

  return {
    title: `${post.title} | My Blog`,
    description: post.excerpt,
    authors: [{ name: post.author.name }],
    openGraph: {
      type: 'article',
      title: post.title,
      description: post.excerpt,
      url: `https://mywebsite.com/blog/${params.slug}`,
      publishedTime: post.publishedAt,
      modifiedTime: post.updatedAt,
      authors: [post.author.name],
      images: [
        {
          url: post.coverImage,
          width: 1200,
          height: 630,
          alt: post.title,
        },
      ],
      tags: post.tags,
    },
    twitter: {
      card: 'summary_large_image',
      title: post.title,
      description: post.excerpt,
      images: [post.coverImage],
    },
  };
}

Metadata Template

// app/layout.tsx
import type { Metadata } from 'next';

export const metadata: Metadata = {
  metadataBase: new URL('https://mywebsite.com'),
  title: {
    default: 'My Website',
    template: '%s | My Website', // Dynamic pages will use this template
  },
  description: 'Default description for my website',
  openGraph: {
    type: 'website',
    siteName: 'My Website',
  },
};

Structured Data (JSON-LD)

Organization Schema

// components/StructuredData.tsx
export function OrganizationSchema() {
  const schema = {
    '@context': 'https://schema.org',
    '@type': 'Organization',
    name: 'My Company',
    url: 'https://mywebsite.com',
    logo: 'https://mywebsite.com/logo.png',
    sameAs: [
      'https://twitter.com/mycompany',
      'https://linkedin.com/company/mycompany',
      'https://github.com/mycompany',
    ],
    contactPoint: {
      '@type': 'ContactPoint',
      telephone: '+1-555-555-5555',
      contactType: 'customer service',
      availableLanguage: ['English', 'Persian'],
    },
  };

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
    />
  );
}

Article Schema

// components/ArticleSchema.tsx
interface ArticleSchemaProps {
  title: string;
  description: string;
  image: string;
  datePublished: string;
  dateModified: string;
  author: {
    name: string;
    url: string;
  };
  url: string;
}

export function ArticleSchema({
  title,
  description,
  image,
  datePublished,
  dateModified,
  author,
  url,
}: ArticleSchemaProps) {
  const schema = {
    '@context': 'https://schema.org',
    '@type': 'Article',
    headline: title,
    description: description,
    image: image,
    datePublished: datePublished,
    dateModified: dateModified,
    author: {
      '@type': 'Person',
      name: author.name,
      url: author.url,
    },
    publisher: {
      '@type': 'Organization',
      name: 'My Website',
      logo: {
        '@type': 'ImageObject',
        url: 'https://mywebsite.com/logo.png',
      },
    },
    mainEntityOfPage: {
      '@type': 'WebPage',
      '@id': url,
    },
  };

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
    />
  );
}

Use Google's Rich Results Test to validate your structured data: https://search.google.com/test/rich-results

Product Schema for E-commerce

export function ProductSchema({ product }) {
  const schema = {
    '@context': 'https://schema.org',
    '@type': 'Product',
    name: product.name,
    description: product.description,
    image: product.images,
    sku: product.sku,
    brand: {
      '@type': 'Brand',
      name: product.brand,
    },
    offers: {
      '@type': 'Offer',
      url: `https://mywebsite.com/products/${product.slug}`,
      priceCurrency: 'USD',
      price: product.price,
      availability: product.inStock
        ? 'https://schema.org/InStock'
        : 'https://schema.org/OutOfStock',
      seller: {
        '@type': 'Organization',
        name: 'My Store',
      },
    },
    aggregateRating: product.reviews.length > 0 ? {
      '@type': 'AggregateRating',
      ratingValue: product.averageRating,
      reviewCount: product.reviews.length,
    } : undefined,
  };

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
    />
  );
}

Sitemap Generation

Dynamic Sitemap

// app/sitemap.ts
import { MetadataRoute } from 'next';
import { getAllPosts } from '@/lib/posts';
import { getAllProducts } from '@/lib/products';

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const baseUrl = 'https://mywebsite.com';

  // Static pages
  const staticPages = [
    {
      url: baseUrl,
      lastModified: new Date(),
      changeFrequency: 'daily' as const,
      priority: 1,
    },
    {
      url: `${baseUrl}/about`,
      lastModified: new Date(),
      changeFrequency: 'monthly' as const,
      priority: 0.8,
    },
    {
      url: `${baseUrl}/contact`,
      lastModified: new Date(),
      changeFrequency: 'monthly' as const,
      priority: 0.8,
    },
  ];

  // Blog posts
  const posts = await getAllPosts();
  const blogPages = posts.map((post) => ({
    url: `${baseUrl}/blog/${post.slug}`,
    lastModified: new Date(post.updatedAt),
    changeFrequency: 'weekly' as const,
    priority: 0.7,
  }));

  // Products
  const products = await getAllProducts();
  const productPages = products.map((product) => ({
    url: `${baseUrl}/products/${product.slug}`,
    lastModified: new Date(product.updatedAt),
    changeFrequency: 'daily' as const,
    priority: 0.9,
  }));

  return [...staticPages, ...blogPages, ...productPages];
}

Robots.txt

// app/robots.ts
import { MetadataRoute } from 'next';

export default function robots(): MetadataRoute.Robots {
  return {
    rules: [
      {
        userAgent: '*',
        allow: '/',
        disallow: ['/api/', '/admin/', '/private/'],
      },
      {
        userAgent: 'Googlebot',
        allow: '/',
        disallow: '/api/',
      },
    ],
    sitemap: 'https://mywebsite.com/sitemap.xml',
  };
}

Core Web Vitals Optimization

Image Optimization

import Image from 'next/image';

// Optimized image component
export function OptimizedImage({ src, alt, priority = false }) {
  return (
    <Image
      src={src}
      alt={alt}
      width={800}
      height={600}
      priority={priority} // Set true for above-the-fold images
      placeholder="blur"
      blurDataURL="data:image/jpeg;base64,/9j/4AAQSkZJRg..."
      sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
      className="object-cover"
    />
  );
}

// Hero image with priority loading
export function HeroSection() {
  return (
    <section>
      <Image
        src="/hero.jpg"
        alt="Hero image"
        fill
        priority // Critical for LCP
        sizes="100vw"
        className="object-cover"
      />
    </section>
  );
}

Font Optimization

// app/layout.tsx
import { Inter, Vazirmatn } from 'next/font/google';

const inter = Inter({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-inter',
});

const vazirmatn = Vazirmatn({
  subsets: ['arabic'],
  display: 'swap',
  variable: '--font-vazirmatn',
});

export default function RootLayout({ children }) {
  return (
    <html className={`${inter.variable} ${vazirmatn.variable}`}>
      <body>{children}</body>
    </html>
  );
}

Script Optimization

import Script from 'next/script';

export function Analytics() {
  return (
    <>
      {/* Load after page is interactive */}
      <Script
        src="https://www.googletagmanager.com/gtag/js?id=GA_ID"
        strategy="afterInteractive"
      />
      <Script id="google-analytics" strategy="afterInteractive">
        {`
          window.dataLayer = window.dataLayer || [];
          function gtag(){dataLayer.push(arguments);}
          gtag('js', new Date());
          gtag('config', 'GA_ID');
        `}
      </Script>

      {/* Load when browser is idle */}
      <Script
        src="https://third-party-script.js"
        strategy="lazyOnload"
      />
    </>
  );
}

Internationalization SEO

Hreflang Tags

// app/[locale]/layout.tsx
import type { Metadata } from 'next';

export async function generateMetadata({ params }): Promise<Metadata> {
  const { locale } = params;

  return {
    alternates: {
      canonical: `https://mywebsite.com/${locale}`,
      languages: {
        'en': 'https://mywebsite.com/en',
        'fa': 'https://mywebsite.com/fa',
        'x-default': 'https://mywebsite.com/en',
      },
    },
  };
}

Localized Sitemap

// app/sitemap.ts
export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const locales = ['en', 'fa'];
  const baseUrl = 'https://mywebsite.com';

  const pages = ['', '/about', '/contact', '/blog'];

  return pages.flatMap((page) =>
    locales.map((locale) => ({
      url: `${baseUrl}/${locale}${page}`,
      lastModified: new Date(),
      alternates: {
        languages: Object.fromEntries(
          locales.map((l) => [l, `${baseUrl}/${l}${page}`])
        ),
      },
    }))
  );
}

Performance Monitoring

Web Vitals Tracking

// app/components/WebVitals.tsx
'use client';

import { useReportWebVitals } from 'next/web-vitals';

export function WebVitals() {
  useReportWebVitals((metric) => {
    // Send to analytics
    const body = JSON.stringify({
      name: metric.name,
      value: metric.value,
      rating: metric.rating,
      delta: metric.delta,
      id: metric.id,
    });

    // Use sendBeacon for reliability
    if (navigator.sendBeacon) {
      navigator.sendBeacon('/api/analytics/vitals', body);
    } else {
      fetch('/api/analytics/vitals', {
        body,
        method: 'POST',
        keepalive: true,
      });
    }
  });

  return null;
}

Conclusion

SEO in Next.js is about combining technical optimization with great content. By implementing proper metadata, structured data, sitemaps, and Core Web Vitals optimization, you can significantly improve your search engine rankings.

Key takeaways:

Use the Metadata API for comprehensive meta tags
Implement structured data for rich search results
Generate dynamic sitemaps for all content
Optimize images, fonts, and scripts for Core Web Vitals
Handle internationalization with proper hreflang tags

Distributed Laravel: High-Performance Event-Driven Architectures

Sepehr Mohseni — Wed, 07 Jan 2026 14:09:22 +0000

In distributed environments, "Fire and Forget" is a recipe for data corruption. Advanced Laravel architecture requires solving the Atomic Commitment Problem: ensuring your database and your message broker agree on the state of the world without compromising performance or consistency.

1. Defining the Contract: The Envelope Pattern

A "raw array" payload is an architectural liability. Sophisticated systems utilize a Message Envelope that encapsulates metadata for distributed tracing (OpenTelemetry), schema versioning, and idempotency.

<?php

namespace App\Core\Messaging;

use JsonSerializable;
use Illuminate\Support\Str;

readonly class MessageEnvelope implements JsonSerializable
{
    public function __construct(
        public string $id,
        public string $topic,
        public array $payload,
        public string $version = '1.0',
        public array $metadata = [],
        public float $occurredAt = 0.0,
    ) {
        $this->occurredAt = $this->occurredAt ?: microtime(true);
    }

    public static function create(string $topic, array $payload): self
    {
        return new self(
            id: Str::uuid()->toString(),
            topic: $topic,
            payload: $payload,
            metadata: [
                'correlation_id' => request()->header('X-Correlation-ID') ?? Str::uuid()->toString(),
            ]
        );
    }

    public function jsonSerialize(): array
    {
        return get_object_vars($this);
    }
}

2. Low-Level Driver Implementation

To achieve 100% accuracy, we move beyond Laravel's default Queue abstraction and interact with the protocol-level features of our brokers.

Redis Streams (The High-Throughput Path)

Instead of standard Redis lists, we utilize Redis Streams (XADD). This provides native message persistence and consumer groups, allowing Laravel to handle massive event spikes without data loss.

namespace App\Infrastructure\Messaging\Drivers;

use App\Core\Messaging\MessageEnvelope;
use Illuminate\Support\Facades\Redis;

class RedisStreamDriver
{
    public function publish(MessageEnvelope $envelope): void
    {
        // Use MAXLEN ~ 10000 to implement an eviction policy
        Redis::connection('messaging')->xadd(
            $envelope->topic, 
            'MAXLEN', '~', 10000, 
            '*', 
            ['data' => json_encode($envelope)]
        );
    }
}

RabbitMQ (The Reliable Path)

For RabbitMQ, we implement Publisher Confirms. Unlike Redis, this implementation forces the PHP process to wait for an acknowledgment from the RabbitMQ broker before marking the message as sent.

namespace App\Infrastructure\Messaging\Drivers;

use PhpAmqpLib\Message\AMQPMessage;
use PhpAmqpLib\Exchange\AMQPExchangeType;

class RabbitMQDriver
{
    public function publish(MessageEnvelope $envelope): void
    {
        $channel = app('amqp.connection')->channel();

        $channel->exchange_declare($envelope->topic, AMQPExchangeType::TOPIC, false, true, false);

        $msg = new AMQPMessage(json_encode($envelope), [
            'delivery_mode' => AMQPMessage::DELIVERY_MODE_PERSISTENT,
            'content_type' => 'application/json',
        ]);

        $channel->confirm_select(); 
        $channel->basic_publish($msg, $envelope->topic);

        // Wait for ACK with a 5s timeout
        $channel->wait_for_pending_acks(5.0); 

        $channel->close();
    }
}

3. The Transactional Outbox: Zero-Leak Dispatching

The most common failure point is dispatching an event inside a database transaction. If the transaction rolls back but the event was already sent, your system enters an inconsistent state. We solve this by writing to an Outbox within the same ACID transaction.

High-Performance Relay Worker

A naive relay spikes CPU. We use Row-Level Locking (lockForUpdate) to allow multiple relay instances to scale horizontally without duplicate processing.

namespace App\Console\Commands;

use App\Models\OutboxMessage;
use App\Infrastructure\Messaging\MessagingMapper;
use Illuminate\Console\Command;

class OutboxRelay extends Command
{
    protected $signature = 'messaging:relay {--driver=redis}';

    public function handle(): void
    {
        while (true) {
            $processed = OutboxMessage::whereNull('dispatched_at')
                ->where('retry_count', '<', 5)
                ->orderBy('created_at', 'asc')
                ->limit(100)
                ->lockForUpdate() 
                ->get()
                ->each(function ($msg) {
                    try {
                        $driver = MessagingMapper::get($this->option('driver'));
                        $driver->publish($msg->toEnvelope());

                        $msg->update(['dispatched_at' => now()]);
                    } catch (\Throwable $e) {
                        $msg->increment('retry_count');
                        report($e);
                    }
                });

            $processed->isEmpty() ? sleep(1) : usleep(100000);
        }
    }
}

4. Consumer Idempotency: The "Exactly Once" Illusion

In distributed systems, you cannot guarantee a message is sent only once, but you can guarantee it is processed only once.

namespace App\Core\Messaging;

use Illuminate\Support\Facades\DB;

trait InteractsWithIdempotency
{
    public function executeOnce(string $messageId, callable $action): void
    {
        try {
            DB::table('processed_events')->insert([
                'id' => $messageId,
                'processed_at' => now(),
            ]);

            $action();
        } catch (\Illuminate\Database\QueryException $e) {
            if ($e->getCode() === '23000') {
                return;
            }
            throw $e;
        }
    }
}

Final Comparison

Feature	Redis Streams	RabbitMQ (AMQP)
Throughput	~150k msg/s	~40k msg/s
Acknowledge	Consumer level	Broker & Consumer level
Persistence	In-memory / AOF	Disk-backed
Best For	Real-time Feeds, Metrics	Financial Transactions, Orders

Advanced TypeScript Patterns: Type-Safe Code That Scales

Sepehr Mohseni — Tue, 06 Jan 2026 18:34:03 +0000

TypeScript's type system is incredibly powerful. This guide explores advanced patterns that will help you write safer, more maintainable code while leveraging TypeScript's full potential.

Generic Constraints and Inference

Basic Generics with Constraints

// Constrain generic to objects with an id property
interface HasId {
  id: string | number;
}

function findById<T extends HasId>(items: T[], id: T['id']): T | undefined {
  return items.find(item => item.id === id);
}

// Usage
interface User {
  id: number;
  name: string;
  email: string;
}

const users: User[] = [
  { id: 1, name: 'John', email: 'john@example.com' },
  { id: 2, name: 'Jane', email: 'jane@example.com' },
];

const user = findById(users, 1); // Type: User | undefined

Generic Factory Functions

// Factory function with proper type inference
function createStore<T>(initialState: T) {
  let state = initialState;
  const listeners = new Set<(state: T) => void>();

  return {
    getState: () => state,
    setState: (newState: Partial<T>) => {
      state = { ...state, ...newState };
      listeners.forEach(listener => listener(state));
    },
    subscribe: (listener: (state: T) => void) => {
      listeners.add(listener);
      return () => listeners.delete(listener);
    },
  };
}

// Type is inferred from initial state
const userStore = createStore({
  user: null as User | null,
  isLoading: false,
  error: null as string | null,
});

userStore.setState({ isLoading: true }); // Type-safe!

TypeScript can infer complex types from usage. Let the compiler do the work when possible, but add explicit types for public APIs.

Conditional Types

Basic Conditional Types

// Extract return type based on input
type ApiResponse<T> = T extends 'user' 
  ? User 
  : T extends 'product' 
    ? Product 
    : never;

// Usage
type UserResponse = ApiResponse<'user'>; // User
type ProductResponse = ApiResponse<'product'>; // Product

// Practical example: Unwrap Promise types
type Awaited<T> = T extends Promise<infer U> ? Awaited<U> : T;

type Result = Awaited<Promise<Promise<string>>>; // string

Distributive Conditional Types

// Conditional types distribute over unions
type NonNullable<T> = T extends null | undefined ? never : T;

type Example = NonNullable<string | null | undefined>; // string

// Extract specific types from union
type ExtractStrings<T> = T extends string ? T : never;

type Mixed = string | number | boolean | 'hello' | 'world';
type OnlyStrings = ExtractStrings<Mixed>; // string | 'hello' | 'world'

Infer Keyword for Type Extraction

// Extract function parameter types
type Parameters<T> = T extends (...args: infer P) => any ? P : never;

// Extract return type
type ReturnType<T> = T extends (...args: any[]) => infer R ? R : never;

// Extract array element type
type ArrayElement<T> = T extends (infer E)[] ? E : never;

// Practical example: Extract props from React component
type ComponentProps<T> = T extends React.ComponentType<infer P> ? P : never;

// Usage
function fetchUser(id: number): Promise<User> { /* ... */ }

type FetchUserParams = Parameters<typeof fetchUser>; // [number]
type FetchUserReturn = ReturnType<typeof fetchUser>; // Promise<User>

Mapped Types

Transform Object Types

// Make all properties optional
type Partial<T> = {
  [P in keyof T]?: T[P];
};

// Make all properties required
type Required<T> = {
  [P in keyof T]-?: T[P];
};

// Make all properties readonly
type Readonly<T> = {
  readonly [P in keyof T]: T[P];
};

// Pick specific properties
type Pick<T, K extends keyof T> = {
  [P in K]: T[P];
};

Advanced Mapped Types

// Create getters for all properties
type Getters<T> = {
  [K in keyof T as `get${Capitalize<string & K>}`]: () => T[K];
};

interface Person {
  name: string;
  age: number;
}

type PersonGetters = Getters<Person>;
// { getName: () => string; getAge: () => number; }

// Filter properties by type
type FilterByType<T, U> = {
  [K in keyof T as T[K] extends U ? K : never]: T[K];
};

interface Mixed {
  id: number;
  name: string;
  active: boolean;
  count: number;
}

type NumberProps = FilterByType<Mixed, number>;
// { id: number; count: number; }

Use template literal types with mapped types to create powerful type transformations for API clients, form builders, and more.

Type Guards and Narrowing

Custom Type Guards

// Type predicate function
function isUser(value: unknown): value is User {
  return (
    typeof value === 'object' &&
    value !== null &&
    'id' in value &&
    'email' in value &&
    typeof (value as User).id === 'number' &&
    typeof (value as User).email === 'string'
  );
}

// Usage
function processData(data: unknown) {
  if (isUser(data)) {
    // TypeScript knows data is User here
    console.log(data.email);
  }
}

// Discriminated unions with type guards
interface SuccessResponse {
  status: 'success';
  data: User;
}

interface ErrorResponse {
  status: 'error';
  message: string;
}

type ApiResponse = SuccessResponse | ErrorResponse;

function handleResponse(response: ApiResponse) {
  if (response.status === 'success') {
    // TypeScript narrows to SuccessResponse
    console.log(response.data.name);
  } else {
    // TypeScript narrows to ErrorResponse
    console.log(response.message);
  }
}

Assertion Functions

// Assert function that throws if condition is false
function assertIsUser(value: unknown): asserts value is User {
  if (!isUser(value)) {
    throw new Error('Value is not a User');
  }
}

// Usage
function processUserData(data: unknown) {
  assertIsUser(data);
  // After assertion, TypeScript knows data is User
  console.log(data.email);
}

// Assert non-null
function assertDefined<T>(
  value: T | null | undefined,
  message?: string
): asserts value is T {
  if (value === null || value === undefined) {
    throw new Error(message ?? 'Value is not defined');
  }
}

Template Literal Types

Building Type-Safe APIs

// Event handler types
type EventName = 'click' | 'focus' | 'blur';
type EventHandler = `on${Capitalize<EventName>}`;
// 'onClick' | 'onFocus' | 'onBlur'

// Route parameters
type Route = '/users/:id' | '/posts/:postId/comments/:commentId';

type ExtractParams<T extends string> = 
  T extends `${infer _Start}:${infer Param}/${infer Rest}`
    ? Param | ExtractParams<`/${Rest}`>
    : T extends `${infer _Start}:${infer Param}`
      ? Param
      : never;

type UserRouteParams = ExtractParams<'/users/:id'>; // 'id'
type CommentRouteParams = ExtractParams<'/posts/:postId/comments/:commentId'>;
// 'postId' | 'commentId'

Type-Safe CSS Properties

type CSSUnit = 'px' | 'em' | 'rem' | '%' | 'vh' | 'vw';
type CSSValue = `${number}${CSSUnit}`;

interface Spacing {
  margin: CSSValue;
  padding: CSSValue;
}

const spacing: Spacing = {
  margin: '16px',    // Valid
  padding: '1.5rem', // Valid
  // margin: '16',   // Error: not a valid CSSValue
};

Utility Types in Practice

Building a Form Library

// Form field configuration
type FieldConfig<T> = {
  [K in keyof T]: {
    type: T[K] extends string 
      ? 'text' | 'email' | 'password'
      : T[K] extends number 
        ? 'number'
        : T[K] extends boolean 
          ? 'checkbox'
          : 'text';
    label: string;
    required?: boolean;
    validate?: (value: T[K]) => string | undefined;
  };
};

interface UserForm {
  name: string;
  email: string;
  age: number;
  newsletter: boolean;
}

const userFormConfig: FieldConfig<UserForm> = {
  name: {
    type: 'text',
    label: 'Full Name',
    required: true,
    validate: (value) => value.length < 2 ? 'Name too short' : undefined,
  },
  email: {
    type: 'email',
    label: 'Email Address',
    required: true,
  },
  age: {
    type: 'number',
    label: 'Age',
  },
  newsletter: {
    type: 'checkbox',
    label: 'Subscribe to newsletter',
  },
};

Type-Safe API Client

// Define API endpoints
interface ApiEndpoints {
  '/users': {
    GET: { response: User[] };
    POST: { body: CreateUserDTO; response: User };
  };
  '/users/:id': {
    GET: { response: User };
    PUT: { body: UpdateUserDTO; response: User };
    DELETE: { response: void };
  };
}

type HttpMethod = 'GET' | 'POST' | 'PUT' | 'DELETE';

// Extract response type for endpoint and method
type ApiResponse<
  E extends keyof ApiEndpoints,
  M extends keyof ApiEndpoints[E]
> = ApiEndpoints[E][M] extends { response: infer R } ? R : never;

// Type-safe fetch wrapper
async function apiClient<
  E extends keyof ApiEndpoints,
  M extends keyof ApiEndpoints[E] & HttpMethod
>(
  endpoint: E,
  method: M,
  options?: ApiEndpoints[E][M] extends { body: infer B } ? { body: B } : never
): Promise<ApiResponse<E, M>> {
  const response = await fetch(endpoint as string, {
    method,
    body: options?.body ? JSON.stringify(options.body) : undefined,
  });
  return response.json();
}

// Usage - fully type-safe!
const users = await apiClient('/users', 'GET');
// Type: User[]

const newUser = await apiClient('/users', 'POST', {
  body: { name: 'John', email: 'john@example.com' },
});
// Type: User

Conclusion

Advanced TypeScript patterns enable you to build type-safe applications that catch errors at compile time rather than runtime. By mastering generics, conditional types, mapped types, and type guards, you can create APIs that are both flexible and bulletproof.

Key takeaways:

Use generics with constraints for reusable, type-safe functions
Leverage conditional types for complex type transformations
Create mapped types for systematic type modifications
Implement type guards for runtime type checking
Combine patterns for powerful, type-safe APIs

Modern PHP Development: Best Practices for Today

Sepehr Mohseni — Sun, 04 Jan 2026 13:51:44 +0000

PHP has evolved dramatically in recent years. PHP 8.x brings powerful features that enable cleaner, more performant code. This guide covers modern PHP practices that every developer should know.

PHP 8.3, 8.4, and 8.5 Features You Should Use

Property Hooks (PHP 8.4)

<?php
class User
{
    public string $name {
        // Custom getter logic
        get => trim($this->name ?? '');
        // Custom setter logic
        set {
            if (strlen(value) < 3) {
                throw new InvalidArgumentException('Name too short');
            }
            $this->name = value;
        }
    }
}

$user = new User();
$user->name = '  John  '; // Setter trims and validates
echo $user->name; // 'John'

Asymmetric Visibility (PHP 8.4)

<?php
class Product
{
    public readonly string $id; // Public read, private set

    public function __construct(string $id)
    {
        $this->id = $id; // Allowed in class scope
    }
}

$product = new Product('abc123');
echo $product->id; // 'abc123'
// $product->id = 'xyz'; // Error: Cannot modify readonly property

Pipe Operator (PHP 8.5)

<?php
$result = $input
    |> trim(?)
    |> strtolower(?)
    |> ucwords(?)
    |> str_replace(' ', '-', ?);

// Equivalent to:
// $result = str_replace(' ', '-', ucwords(strtolower(trim($input))));

Constructor Property Promotion

<?php
// Before PHP 8.0
class Product
{
    private string $name;
    private float $price;
    private int $stock;
    public function __construct(string $name, float $price, int $stock)
    {
        $this->name = $name;
        $this->price = $price;
        $this->stock = $stock;
    }
}
// PHP 8.0+ - Much cleaner!
class Product
{
    public function __construct(
        private string $name,
        private float $price,
        private int $stock = 0,
    ) {}
}

Constructor property promotion reduces boilerplate significantly. Combine with readonly for immutable value objects.

Named Arguments

<?php
function createUser(
    string $name,
    string $email,
    ?string $phone = null,
    bool $newsletter = false,
    string $role = 'user',
): User {
    // ...
}
// Clear and self-documenting
$user = createUser(
    name: 'John Doe',
    email: 'john@example.com',
    newsletter: true,
    // Skip phone, use default role
);

Match Expression

<?php
// Before: switch statement
function getStatusLabel(string $status): string
{
    switch ($status) {
        case 'pending':
            return 'Awaiting Review';
        case 'approved':
            return 'Approved';
        case 'rejected':
            return 'Rejected';
        default:
            return 'Unknown';
    }
}
// PHP 8.0+: match expression
function getStatusLabel(string $status): string
{
    return match ($status) {
        'pending' => 'Awaiting Review',
        'approved' => 'Approved',
        'rejected' => 'Rejected',
        default => 'Unknown',
    };
}
// Match with multiple conditions
function getDiscount(string $customerType): float
{
    return match ($customerType) {
        'vip', 'premium' => 0.20,
        'regular' => 0.10,
        'new' => 0.05,
        default => 0.0,
    };
}

Enums

<?php
// Basic enum
enum Status: string
{
    case Pending = 'pending';
    case Approved = 'approved';
    case Rejected = 'rejected';
    public function label(): string
    {
        return match ($this) {
            self::Pending => 'Awaiting Review',
            self::Approved => 'Approved',
            self::Rejected => 'Rejected',
        };
    }
    public function color(): string
    {
        return match ($this) {
            self::Pending => 'yellow',
            self::Approved => 'green',
            self::Rejected => 'red',
        };
    }
}
// Usage
$status = Status::Pending;
echo $status->value; // 'pending'
echo $status->label(); // 'Awaiting Review'
// Type-safe function parameters
function updateOrderStatus(Order $order, Status $status): void
{
    $order->status = $status;
    $order->save();
}

Use backed enums (with string or int values) when you need to store values in a database or serialize to JSON.

Design Patterns in Modern PHP

Repository Pattern

<?php
namespace App\Repositories;
use App\Models\User;
use Illuminate\Support\Collection;
interface UserRepositoryInterface
{
    public function find(int $id): ?User;
    public function findByEmail(string $email): ?User;
    public function all(): Collection;
    public function create(array $data): User;
    public function update(User $user, array $data): User;
    public function delete(User $user): bool;
}
class EloquentUserRepository implements UserRepositoryInterface
{
    public function __construct(
        private readonly User $model,
    ) {}
    public function find(int $id): ?User
    {
        return $this->model->find($id);
    }
    public function findByEmail(string $email): ?User
    {
        return $this->model->where('email', $email)->first();
    }
    public function all(): Collection
    {
        return $this->model->all();
    }
    public function create(array $data): User
    {
        return $this->model->create($data);
    }
    public function update(User $user, array $data): User
    {
        $user->update($data);
        return $user->fresh();
    }
    public function delete(User $user): bool
    {
        return $user->delete();
    }
}

Service Layer Pattern

<?php
namespace App\Services;
use App\DTOs\CreateOrderDTO;
use App\Events\OrderCreated;
use App\Models\Order;
use App\Repositories\OrderRepositoryInterface;
use App\Repositories\ProductRepositoryInterface;
use Illuminate\Support\Facades\DB;
class OrderService
{
    public function __construct(
        private readonly OrderRepositoryInterface $orderRepository,
        private readonly ProductRepositoryInterface $productRepository,
        private readonly PaymentService $paymentService,
    ) {}
    public function createOrder(CreateOrderDTO $dto): Order
    {
        return DB::transaction(function () use ($dto) {
            // Validate stock availability
            foreach ($dto->items as $item) {
                $product = $this->productRepository->find($item->productId);

                if ($product->stock < $item->quantity) {
                    throw new InsufficientStockException($product);
                }
            }
            // Create order
            $order = $this->orderRepository->create([
                'user_id' => $dto->userId,
                'status' => OrderStatus::Pending,
                'total' => $this->calculateTotal($dto->items),
            ]);
            // Add items and update stock
            foreach ($dto->items as $item) {
                $order->items()->create([
                    'product_id' => $item->productId,
                    'quantity' => $item->quantity,
                    'price' => $item->price,
                ]);
                $this->productRepository->decrementStock(
                    $item->productId,
                    $item->quantity
                );
            }
            event(new OrderCreated($order));
            return $order;
        });
    }
}

Data Transfer Objects (DTOs)

<?php
namespace App\DTOs;
use Illuminate\Http\Request;
readonly class CreateUserDTO
{
    public function __construct(
        public string $name,
        public string $email,
        public string $password,
        public ?string $phone = null,
        public bool $newsletter = false,
    ) {}
    public static function fromRequest(Request $request): self
    {
        return new self(
            name: $request->validated('name'),
            email: $request->validated('email'),
            password: $request->validated('password'),
            phone: $request->validated('phone'),
            newsletter: $request->boolean('newsletter'),
        );
    }
    public static function fromArray(array $data): self
    {
        return new self(
            name: $data['name'],
            email: $data['email'],
            password: $data['password'],
            phone: $data['phone'] ?? null,
            newsletter: $data['newsletter'] ?? false,
        );
    }
}

Testing Best Practices

Unit Testing with PHPUnit

<?php
namespace Tests\Unit\Services;
use App\DTOs\CreateOrderDTO;
use App\Models\Order;
use App\Models\Product;
use App\Repositories\OrderRepositoryInterface;
use App\Repositories\ProductRepositoryInterface;
use App\Services\OrderService;
use App\Services\PaymentService;
use PHPUnit\Framework\TestCase;
use Mockery;
class OrderServiceTest extends TestCase
{
    private OrderService $service;
    private $orderRepository;
    private $productRepository;
    private $paymentService;
    protected function setUp(): void
    {
        parent::setUp();
        $this->orderRepository = Mockery::mock(OrderRepositoryInterface::class);
        $this->productRepository = Mockery::mock(ProductRepositoryInterface::class);
        $this->paymentService = Mockery::mock(PaymentService::class);
        $this->service = new OrderService(
            $this->orderRepository,
            $this->productRepository,
            $this->paymentService,
        );
    }
    public function test_creates_order_successfully(): void
    {
        // Arrange
        $product = new Product(['id' => 1, 'stock' => 10, 'price' => 99.99]);
        $order = new Order(['id' => 1, 'status' => 'pending']);
        $this->productRepository
            ->shouldReceive('find')
            ->with(1)
            ->andReturn($product);
        $this->orderRepository
            ->shouldReceive('create')
            ->once()
            ->andReturn($order);
        $dto = new CreateOrderDTO(
            userId: 1,
            items: [new OrderItemDTO(productId: 1, quantity: 2, price: 99.99)],
        );
        // Act
        $result = $this->service->createOrder($dto);
        // Assert
        $this->assertInstanceOf(Order::class, $result);
        $this->assertEquals('pending', $result->status);
    }
    public function test_throws_exception_when_insufficient_stock(): void
    {
        // Arrange
        $product = new Product(['id' => 1, 'stock' => 1]);
        $this->productRepository
            ->shouldReceive('find')
            ->andReturn($product);
        $dto = new CreateOrderDTO(
            userId: 1,
            items: [new OrderItemDTO(productId: 1, quantity: 5, price: 99.99)],
        );
        // Assert & Act
        $this->expectException(InsufficientStockException::class);
        $this->service->createOrder($dto);
    }
    protected function tearDown(): void
    {
        Mockery::close();
        parent::tearDown();
    }
}

Feature Testing

<?php
namespace Tests\Feature\Api;
use App\Models\User;
use App\Models\Product;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;
class OrderApiTest extends TestCase
{
    use RefreshDatabase;
    public function test_authenticated_user_can_create_order(): void
    {
        // Arrange
        $user = User::factory()->create();
        $product = Product::factory()->create(['stock' => 10, 'price' => 49.99]);
        // Act
        $response = $this->actingAs($user)
            ->postJson('/api/orders', [
                'items' => [
                    ['product_id' => $product->id, 'quantity' => 2],
                ],
            ]);
        // Assert
        $response->assertCreated()
            ->assertJsonStructure([
                'data' => ['id', 'status', 'total', 'items'],
            ]);
        $this->assertDatabaseHas('orders', [
            'user_id' => $user->id,
            'status' => 'pending',
        ]);
        $this->assertDatabaseHas('products', [
            'id' => $product->id,
            'stock' => 8, // 10 - 2
        ]);
    }
    public function test_unauthenticated_user_cannot_create_order(): void
    {
        $response = $this->postJson('/api/orders', [
            'items' => [],
        ]);
        $response->assertUnauthorized();
    }
}

Performance Optimization

OPcache Configuration

; php.ini production settings
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.save_comments=1
opcache.jit_buffer_size=256M
opcache.jit=1255

Preloading

<?php
// preload.php
require __DIR__ . '/vendor/autoload.php';
// Preload frequently used classes
$classesToPreload = [
    \App\Models\User::class,
    \App\Models\Product::class,
    \App\Models\Order::class,
    \App\Services\OrderService::class,
    \App\Repositories\EloquentUserRepository::class,
];
foreach ($classesToPreload as $class) {
    class_exists($class);
}

; php.ini
opcache.preload=/var/www/app/preload.php
opcache.preload_user=www-data

Conclusion

Modern PHP is a powerful, elegant language when used correctly. By leveraging PHP 8.x features, following design patterns, writing comprehensive tests, and optimizing performance, you can build applications that are maintainable, scalable, and fast.

Key takeaways:

Use PHP 8.x features like property hooks, asymmetric visibility, pipe operator, enums, and match expressions
Implement design patterns for clean architecture
Write comprehensive unit and feature tests
Configure OPcache and JIT for production performance
Use DTOs for type-safe data transfer

DEV Community: Sepehr Mohseni

AI Changed the Industry, But Not Why I Loved Computers

Modern Laravel Mastery: Advanced Features, Clean Architecture, Testing & Blazing Performance in Laravel 12+

Laravel 12+ Features You Should Use Right Now

nestedWhere() – Clean Complex Queries Without Closures (Laravel 12)

UUID / ULID Primary Keys (Built-in Since Laravel 9, Perfected in 11+)

Prunable & MassPrunable Models – Automatic Database Cleanup

Attribute-Based Local Scopes (Laravel 10.20+ / 11+)

Model Replication (Lesser-Known Gem)

Modern Architecture Patterns in Laravel 12+

Repository + Service Layer (Still King in 2026)

Data Transfer Objects (DTOs) with Constructor Property Promotion + Readonly

Testing Best Practices – Pest is Default in Laravel 11+

Pest Unit Tests (Clean & Expressive)

Feature Tests with RefreshDatabase

Performance Optimization – Octane Changes Everything

Laravel Octane (Swoole / RoadRunner / FrankenPHP)

Concurrent Tasks (True Parallelism)

Octane Cache & Tables (In-Memory, Shared Across Workers)

Ticks for Background Work

Conclusion

Platform engineering internals: building an Internal Developer Platform (IDP) for your backend teams

Why IDPs Are Becoming More Essential

What a Good IDP Actually Looks Like

1. Self-Service Environment Provisioning

2. Deployment Pipelines as Code

3. Secrets and RBAC Without Tickets

4. Observability Access

5. Service Catalog With Ownership Metadata

Build vs. Buy: An Honest Assessment

Build When

Buy or Adopt Open Source When

A Phased Approach to Building Your IDP

Phase 1: Discover (Weeks 1–4)

Phase 2: Self-Service Basics (Weeks 5–12)

Phase 3: Golden Paths (Weeks 13–20)

Phase 4: Observability & Cost (Weeks 21–32)

Common Failures and How to Avoid Them

❌ Building Portals First

❌ Ignoring Adoption

❌ Security Holes in Self-Service

Measuring Success

Conclusion

Incident response & blameless post-mortems: writing better runbooks and SLO/SLI definitions

SLOs, SLIs, and Error Budgets: Getting Them Right

SLIs: What You Actually Measure

SLOs: Your Target

SLOs Based on User Journeys

Error Budgets: Making SLOs Actionable

Implementing SLO Monitoring

Writing Runbooks That Actually Get Used

Runbook Structure

Testing Runbooks (PHP / Laravel Example)

Incident Response: A Structured Approach

Severity Levels

Incident Roles

Incident Channel Template

Incident Automation (PHP)

Blameless Postmortems

Postmortem Template

Tracking Action Items (PHP)

Measuring Reliability Improvement

Conclusion

Building AI-native backends – RAG pipelines, function calling, prompt versioning, LLM observability

The Reality of AI Backends

RAG Is Not “Chunk, Embed, Query”

Ingestion in Laravel

Hybrid Retrieval Is Mandatory

Generation With Grounded Context

Function Calling Without Guardrails Will Burn You

Prompts Are Code

Observability Is Not Optional

Caching and Cost Control

What Actually Prevents Incidents

Final Takeaway

From monolith to modular monolith to microservices: realistic migration patterns

TL;DR — The single sentence strategy

Why most migrations fail (and how to avoid each failure)

Step 1 — Modularize the monolith first (the low-risk win)

Interfaces and domain code — real examples (Symfony)

`nestedWhere()` – Clean Complex Queries Without Closures (Laravel 12)