DEV Community: Francisco Navarro

Doppar Introduces Frozen Services, Missing in Laravel, Symfony?

Francisco Navarro — Mon, 02 Mar 2026 09:59:24 +0000

We just shipped something we have not seen in any PHP framework before.

Starting today, Doppar services can be marked #[Immutable]. When they are, the framework configures them freely during application boot — from your config files, environment variables, databases, whatever you need — and then permanently freezes them before the first request is handled. After that point, any attempt to mutate a property on that service throws an exception immediately, no matter where in the application the mutation is attempted.

We call this Frozen Services.

The Bug Every PHP Developer Has Shipped

Here is a scenario you have probably encountered, or will encounter.

You register a PaymentService as a singleton. It stores the payment gateway, the tax rate, whether you are in live mode. Standard setup. The service is shared across the request lifecycle — that is the point of singletons.

Three months later, a junior developer writes a middleware. They need to temporarily switch the gateway for a specific route. They find the service in the container, assign the property, and move on. The code review misses it. The tests pass — they do not cover this path.

// Somewhere in CheckoutMiddleware.php, 4 files from anywhere relevant
$payment = app(PaymentService::class);
$payment->gateway = 'sandbox'; // just for testing, I'll remove this later

They do not remove it. Now every request that passes through that middleware — in production, with real customers — uses the sandbox gateway. No exception. No log entry. No stack trace pointing to CheckoutMiddleware.php. Just wrong behaviour that is almost impossible to trace back to a property assignment three files away.

This is not a contrived example. This is a real, common, catastrophic class of bug that every major PHP framework silently allows today.

What Every Framework Gets Wrong

Let us be direct about the state of the ecosystem.

Laravel — singleton services are mutable objects forever. The container has no concept of a service lifecycle beyond "resolved" or "not resolved". Nothing in the framework prevents mutation of shared service state at any point during the request.

Symfony — the compiled container can be frozen, but that freezes the container's bindings and metadata, not the service objects themselves. The actual PaymentService instance sitting inside the frozen Symfony container is a plain mutable PHP object. You can write to it freely.

Slim, Laminas, Yii, CodeIgniter, CakePHP — none of these frameworks have a runtime immutability mechanism for services. The concept does not exist in any of them.

The ecosystem's answer to this problem has always been: code review and convention. Do not mutate singletons. Put it in the team wiki. Add it to the style guide.

We think frameworks should enforce architecture, not document it.

PHP 8.2 Has `readonly` — Is That Not Enough?

This is the first question we get when we describe Frozen Services. It is a fair question and deserves a direct answer.

PHP 8.2's readonly class freezes properties immediately on construction. There is no window between new and frozen — the moment the object exists, it is immutable.

That sounds ideal, but it creates a problem that is fundamental to how PHP applications are structured.

Your services are not configured at new time. They are configured from config(), from env(), from values that only exist after the framework boots. The standard ServiceProvider pattern — the backbone of Laravel, Doppar, and most modern PHP frameworks — requires that you configure services after constructing them.

// This is how every framework works — and readonly breaks it

readonly class PaymentService
{
    public string $gateway;
    public float  $taxRate;
}

// In your ServiceProvider:
$payment = new PaymentService();
$payment->gateway = config('payment.gateway'); // Fatal error: readonly property
$payment->taxRate = config('payment.tax_rate'); // Fatal error: readonly property

You cannot use readonly with a ServiceProvider configuration pattern. You are forced to either pass all values through the constructor (which means knowing them at new time, which is often impossible) or abandon readonly entirely.

Doppar's Frozen Services solves exactly this gap. The service is mutable during boot — your providers configure it freely — and then frozen before any request code runs.

// Doppar's approach — configure then lock

use Phaseolies\DI\Attributes\Immutable;
use Phaseolies\DI\Concerns\EnforcesImmutability;

#[Immutable]
class PaymentService
{
    use EnforcesImmutability;

    public string $gateway = 'stripe';
    public float  $taxRate = 0.08;
    public bool   $liveMode = false;
}

// In your ServiceProvider:
$payment           = new PaymentService();
$payment->gateway  = config('payment.gateway');        // ✓ writable during boot
$payment->taxRate  = config('payment.tax_rate');       // ✓ writable during boot
$payment->liveMode = env('APP_ENV') === 'production';  // ✓ writable during boot

$this->app->singleton(PaymentService::class, fn() => $payment);
// freeze() called → permanently locked for the entire request lifecycle

This is the boot window. Configure freely. Then the framework locks it. readonly cannot do this. No other framework does this.

The Developer Experience

We worked hard to make this as close to zero boilerplate as possible.

What You Write on the Service

use Phaseolies\DI\Attributes\Immutable;
use Phaseolies\DI\Concerns\EnforcesImmutability;

#[Immutable]
class PaymentService
{
    use EnforcesImmutability;

    public string $gateway  = 'stripe';
    public float  $taxRate  = 0.08;
    public bool   $liveMode = false;

    public function charge(float $amount): array
    {
        return [
            'gateway' => $this->gateway,
            'total'   => round($amount * (1 + $this->taxRate), 2),
            'status'  => 'charged',
        ];
    }
}

Two things added from a normal service class: the #[Immutable] attribute and use EnforcesImmutability. Properties stay public. No visibility changes. No constructor boilerplate. No interface to implement.

What You Write in a Controller

class PaymentController extends Controller
{
    public function __construct(
        private readonly PaymentService $payment
    ) {}

    public function process(Request $request): array
    {
        return $this->payment->charge($request->amount); // Works exactly as before
    }
}

Nothing changes for controllers or any other consumer. Inject it exactly as you did before. Read properties exactly as you did before. The frozen service is indistinguishable from a regular service except that writing to it throws.

What Mutation Looks Like Now

public function charge(Request $request, PaymentService $payment): array
{
    try {
        $payment->taxRate = 0.0; // Attempted mutation
    } catch (ImmutableViolationException $e) {
        return [
            'success'     => false,
            'error'       => $e->getMessage(),
            'currentRate' => $payment->taxRate, // Still 0.08 — unchanged
        ];
    }

    return ['success' => true];
}

Response:

{
    "success": false,
    "error": "Cannot mutate property $taxRate on immutable service [App\\Services\\PaymentService]. Services marked #[Immutable] are frozen after instantiation.",
    "currentRate": 0.08
}

The exception is typed. The message names the class and the property. The value is unchanged. The bug that used to succeed silently now fails loudly, immediately, with a stack trace.

The Lifecycle in Full

┌─────────────────────────────────────────────────────────┐
│                    BOOT PHASE                           │
│                                                         │
│  $payment = new PaymentService();                       │
│  $payment->gateway  = config('payment.gateway');  ✓    │
│  $payment->taxRate  = config('payment.tax_rate'); ✓    │
│  $payment->liveMode = env('APP_ENV') === 'prod';  ✓    │
│                                                         │
│  $this->app->singleton(PaymentService::class, ...);     │
│                        │                                │
│                        ▼                                │
│              Container calls freeze()                   │
└─────────────────────────┬───────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│                   RUNTIME PHASE                         │
│                                                         │
│  $payment->gateway         // ✓ 'stripe'                │
│  $payment->taxRate         // ✓ 0.08                    │
│  $payment->charge(100.00)  // ✓ method calls work       │
│                                                         │
│  $payment->gateway = 'pp'  // ✗ ImmutableViolation      │
│  $payment->taxRate = 0.0   // ✗ ImmutableViolation      │
│  unset($payment->gateway)  // ✗ ImmutableViolation      │
│  clone $payment            // ✗ ImmutableViolation      │
└─────────────────────────────────────────────────────────┘

Side-by-Side Comparison

	Mutable Singleton	`readonly class`	Doppar `#[Immutable]`
Configurable from `config()` / `env()`	✓	✗	✓
Protected from runtime mutation	✗	✓	✓
Works with ServiceProvider pattern	✓	✗	✓
Clear typed exception on violation	✗	✗ (generic `Error`)	✓
Boot window	—	✗	✓
Reads work transparently	✓	✓	✓
Method calls work transparently	✓	✓	✓
Framework enforced	✗	Engine enforced	Container enforced
Works with injection (type hints)	✓	✓	✓

The Bigger Picture

Frozen Services is not just a convenience feature. It represents a different way of thinking about application architecture in PHP.

Most frameworks treat services as objects — they can be created, configured, injected, and modified at any time by any code with a reference to them. The developer is responsible for ensuring that shared services are not inadvertently mutated. The framework has no opinion.

Doppar now has an opinion.

Services that are configured and shared should be immutable after configuration. The boot phase is for setup. The runtime phase is for use. This boundary should be enforced by the framework — not by a comment in a style guide, not by code review, not by hoping that no one makes a mistake.

This is the same principle that makes readonly properties and immutable value objects valuable in domain-driven design — applied at the service layer, where the risk of mutation is highest and the consequences of a silent mutation are most severe.

We believe this is how PHP application services should work. We believe other frameworks will implement something similar. And we are shipping it today in Doppar.

Learn More

Full documentation Frozen Services

Database Transactions Made Simple in Doppar

Francisco Navarro — Fri, 23 Jan 2026 05:55:49 +0000

When building real-world applications, database transactions are not optional — they’re essential. Whether you’re creating orders, updating records, or syncing data across services, you need consistency, safety, and retries.

If you’re coming from Laravel, you already know how valuable transaction handling is. The good news? Doppar supports transactions just as cleanly — and sometimes even more elegantly.

Let’s take a look.

Declarative Transactions with Attributes

Doppar embraces PHP attributes to keep your code expressive and readable. Instead of wrapping logic inside transaction blocks manually, you declare your intent right where it matters — above your controller method.

Creating an Order (PostgreSQL)

#[Transaction(connection: 'pgsql', attempts: 3)]
#[Route(uri: 'orders', methods: ['POST'])]
public function store()
{
    // pgsql connection + 3 retry attempts
}

What’s happening here?

A database transaction is automatically started
Uses the PostgreSQL connection
Retries the transaction up to 3 times if it fails
Commits on success, rolls back on failure
Your business logic stays clean and focused

No boilerplate. No manual beginTransaction() or commit() calls.

Updating an Order (MySQL)

#[Transaction(connection: 'mysql', attempts: 3)]
#[Route(uri: 'orders/{id}', methods: ['PUT'])]
public function update()
{
    // mysql connection + 3 retry attempts
}

Why this is powerful

You can switch database connections per endpoint
Transactions are automatically scoped to the request
Failures are retried without extra code
Works perfectly for distributed or multi-DB systems

Doppar’s transaction handling gives you enterprise-grade safety without sacrificing developer experience. If you love Laravel’s simplicity but want a lighter, more declarative framework, Doppar delivers — especially when it comes to transactions.

Understanding Doppar Queue: A Deep Dive into Job Lifecycle and Why It Matters

Francisco Navarro — Mon, 15 Dec 2025 06:17:47 +0000

Queue systems are the unsung heroes of modern web applications. They handle everything from sending emails to processing videos, generating reports to dispatching notifications—all without making your users wait. But have you ever wondered what actually happens to a job from the moment you dispatch it until it completes (or fails)?

Today, I'm taking you on a journey through Doppar's queue system. We'll explore how jobs move through their lifecycle, what happens when things go wrong, and why Doppar's approach makes building reliable background processing systems surprisingly straightforward.

Why Background Jobs Matter (And Why You Should Care)

Before we dive into the technical details, let's talk about why queues exist in the first place.

Imagine you're building an e-commerce platform. When a customer completes a purchase, your application needs to:

Send a confirmation email
Generate an invoice PDF
Update inventory counts
Notify the warehouse
Record analytics data
Possibly trigger third-party integrations

If you tried to do all of this synchronously—making the customer wait while each task completes—you'd have a terrible user experience. A simple "thank you" page that should load instantly might take 5-10 seconds. Even worse, if any single task fails (like the email service being down), the entire request could fail.

This is where queues shine. You dispatch these tasks to run in the background, respond to the user immediately, and let workers handle the heavy lifting asynchronously.

The Doppar Queue System: Built for Reliability

Doppar's queue system isn't just another job processor—it's designed with real-world production scenarios in mind. Here's what makes it special:

Multiple Queue Support: Organize jobs by priority (urgent vs. standard) or by type (emails, reports, uploads). This lets you allocate resources intelligently.

Automatic Retry Logic: Jobs fail sometimes. Network hiccups, temporary service outages, rate limits—Doppar handles these gracefully with configurable retry attempts and delays.

Job Chaining: Execute multi-step workflows where each job runs only after the previous one succeeds. Perfect for complex operations like "download → process → upload → notify."

Failed Job Tracking: When jobs fail permanently, Doppar stores them with full context for debugging. You're never left wondering what went wrong.

Graceful Shutdown: Workers respond to termination signals properly, finishing their current job before shutting down. No more corrupted data from killed processes.

Memory Management: Workers automatically restart when memory limits are hit, preventing memory leaks from bringing down your entire queue system.

Now let's see how it all works under the hood.

The Job Lifecycle: From Dispatch to Completion

The journey of a queued job in Doppar follows a well-defined path. Understanding this lifecycle helps you write better jobs and debug issues when they arise.

Step 1: Job Dispatch

Everything starts when you dispatch a job. In Doppar, this is beautifully simple:

(new SendWelcomeEmailJob($user))->dispatch();

At this moment, several things happen:

Job Serialization: Doppar serializes your job object, including all its dependencies (like that $user object), into a storable format.
Queue Assignment: The job is assigned to a specific queue. By default, it goes to the "default" queue, but you can customize this.
Database Storage: The serialized job gets stored in the queue_jobs table with metadata like:
- queue: Which queue it belongs to
- payload: The serialized job data
- attempts: Initially 0
- available_at: When it should become available for processing
- created_at: Timestamp of creation

If you've specified a delay, the available_at timestamp is set to the future:

(new ProcessVideo($path))
    ->delayFor(300)  // 5 minutes
    ->dispatch();

This job won't be picked up by workers until 5 minutes have passed.

Step 2: Worker Picks Up the Job

Now a worker process is running:

php pool queue:run --queue=default

The worker continuously polls the database looking for jobs that are:

Available (current time >= available_at)
Not reserved by another worker
In the queue it's watching

When it finds a job, it:

Reserves the Job: Updates reserved_at to mark it as being processed. This prevents other workers from grabbing the same job.
Increments Attempts: The attempts counter goes up by 1.
Checks Configuration: The worker reads job-specific settings like timeout, max attempts, and retry delays.
Deserializes: The serialized job payload is unserialized back into a proper PHP object.

Step 3: Job Execution

Here's where your actual job logic runs. Doppar provides timeout protection:

#[Queueable(timeout: 60)]
class SendEmailJob extends Job
{
    public function handle(): void
    {
        // Your logic here
        // This will timeout after 60 seconds
    }
}

The worker executes your handle() method within the specified timeout. If the job takes longer than allowed, it's automatically terminated and treated as a failure.

Step 4: Success or Failure - The Fork in the Road

After execution, the job can go one of two ways:

The Happy Path: Success

When a job completes successfully:

Job Deleted: The job is removed from the queue_jobs table.
Chain Check: If this job is part of a chain, Doppar checks if there are more jobs to execute:

Drain::conduct([
    new DownloadJob($url),      // Just completed successfully
    new ProcessJob($path),      // This gets dispatched next
    new UploadJob($file),       // Waiting
    new NotifyJob($userId),     // Waiting
])->dispatch();

The next job in the chain is automatically dispatched to the queue.

Completion Callbacks: If you've defined a then() callback for the chain and this was the final job, it gets executed:

Drain::conduct([...])
    ->then(fn() => Log::info("All jobs completed!"))
    ->dispatch();

The Failure Path: When Things Go Wrong

When a job throws an exception or times out:

Retry Logic Evaluation: Doppar checks: attempts < tries?

Let's say your job is configured with:

#[Queueable(tries: 3, retryAfter: 60)]
class SendEmailJob extends Job { }

If this is attempt #1 or #2, the job gets released back to the queue:

Release with Delay: The job is marked as available again, but with available_at set to 60 seconds in the future. This prevents immediate repeated failures and gives temporary issues time to resolve.
Final Failure: If this was the final attempt (attempt #3 in our example), the job is permanently failed:
- Moved to the failed_jobs table with full exception details
- Removed from queue_jobs
- The failed() callback is invoked if you've defined one:

public function failed(\Throwable $exception): void
{
    Log::error("Email failed for user {$this->user->id}", [
        'exception' => $exception->getMessage()
    ]);

    // Maybe notify an admin or trigger a fallback
}

Chain Termination: If this was part of a chain, the entire chain stops immediately. Remaining jobs are never executed. If you've defined a catch() handler, it gets called:

Drain::conduct([...])
    ->catch(function($job, $exception, $index) {
        Log::error("Chain failed at job {$index}", [
            'job' => get_class($job),
            'error' => $exception->getMessage()
        ]);
    })
    ->dispatch();

Job Chaining: The Power of Sequential Workflows

Job chaining is where Doppar really shines. It lets you build complex, multi-step workflows with elegant error handling.

How Chaining Works Internally

When you create a chain:

Drain::conduct([
    new Job1(),
    new Job2(),
    new Job3(),
])->dispatch();

Doppar doesn't queue all three jobs immediately. Instead:

Only Job1 is queued with metadata indicating it's part of a chain.
When Job1 completes successfully, Doppar automatically dispatches Job2.
When Job2 completes successfully, Doppar dispatches Job3.
When Job3 completes, the chain is done and then() callbacks fire.

This approach is brilliant because:

No partial states: If Job2 fails, Job3 never runs. You don't have to worry about cleaning up partial work.
Memory efficient: Only one job is in memory/queue at a time.
Clear dependencies: The execution order is explicit in your code.

Real-World Example: Video Processing Pipeline

Let's build something real—a video processing pipeline:

Drain::conduct([
    new DownloadVideoJob($videoUrl),
    new ConvertVideoJob($tempPath),
    new GenerateThumbnailJob($convertedPath),
    new UploadToS3Job($finalPath, $thumbnailPath),
    new NotifyUserJob($userId, $videoId),
    new CleanupTempFilesJob($tempPath)
])
->onQueue('video-processing')
->then(function() use ($videoId) {
    Log::info("Video {$videoId} processed successfully");
    Cache::forget("video_{$videoId}_processing");
})
->catch(function($job, $exception, $index) use ($videoId) {
    Log::error("Video processing failed at step {$index}", [
        'video_id' => $videoId,
        'failed_job' => get_class($job),
        'error' => $exception->getMessage()
    ]);

    // Notify user of failure
    $user->notify(new SendVideoFailureNotification($videoId))
         ->via(['discord', 'slack'])
         ->send();
})
->dispatch();

This chain:

Downloads the video from a URL
Converts it to the desired format
Generates a thumbnail
Uploads both to S3
Notifies the user
Cleans up temporary files

If any step fails—say, the S3 upload hits a quota limit—the chain stops. You don't end up in a weird state where the user is notified but the video isn't actually uploaded.

Advanced Configuration: Fine-Tuning Your Jobs

Doppar gives you granular control over how jobs behave using the #[Queueable] attribute:

#[Queueable(
    tries: 5,           // Try up to 5 times
    retryAfter: 120,    // Wait 2 minutes between retries
    timeout: 300,       // Kill if running longer than 5 minutes
    onQueue: 'reports'  // Use the 'reports' queue
)]
class GenerateAnalyticsReport extends Job
{
    public function handle(): void
    {
        // Generate complex report
    }
}

Why These Settings Matter

tries & retryAfter: External APIs are flaky. Rate limits, temporary outages, and network blips happen. With 5 tries and 2-minute delays, you're giving the external service plenty of time to recover before giving up.

timeout: Reports can be large. But you don't want a runaway process consuming resources forever. A 5-minute timeout is generous but bounded.

onQueue: Separate heavy reports from lightweight tasks. This lets you allocate more workers to time-sensitive queues and fewer to background analytics.

Running Workers in Production

In development, you might run:

php pool queue:run

But in production, you need something more robust. Doppar integrates beautifully with Supervisor:

[program:queue-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/html/pool queue:run --sleep=3 --memory=256
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
user=www-data
numprocs=4
redirect_stderr=true
stdout_logfile=/var/www/html/storage/logs/worker.log
stopwaitsecs=3600

This configuration:

Runs 4 worker processes in parallel
Automatically restarts workers if they crash
Restarts workers when they exceed 256MB memory
Handles graceful shutdown with SIGTERM/SIGINT
Logs all output for debugging

Multi-Queue Setup

In production, you often want dedicated workers for different queues:

# High priority - 4 workers
php pool queue:run --queue=urgent --memory=512 &

# Normal priority - 2 workers  
php pool queue:run --queue=default --memory=256 &

# Low priority - 1 worker
php pool queue:run --queue=background --memory=128 &

This ensures urgent tasks get processed quickly even when background jobs are backlogged.

Monitoring and Debugging

Doppar provides excellent visibility into your queue system.

View Queue Statistics

php pool queue:monitor

This shows:

Pending jobs per queue
Failed jobs count
Active workers
Processing rates

Inspect Failed Jobs

php pool queue:failed

Lists all failed jobs with:

Job class name
Exception message and stack trace
Original payload (so you can see what data caused the failure)
Timestamp of failure

Retry Failed Jobs

Fixed the bug? Retry the failed jobs:

# Retry all failed jobs
php pool queue:retry

# Retry specific job by ID
php pool queue:retry 42

Flush Failed Jobs

Clean up the failed jobs table:

# Delete all failed jobs
php pool queue:flush

# Delete specific failed job
php pool queue:flush 42

Design Patterns and Best Practices

After working with Doppar queues extensively, here are patterns that work well:

1. Keep Jobs Focused

Each job should do one thing well:

// Good: Focused jobs
new SendEmailJob($user, $emailType);
new GeneratePDFJob($invoiceId);

// Bad: God job
new ProcessOrderJob($order); // Does everything

2. Make Jobs Idempotent

Jobs should be safe to run multiple times:

public function handle(): void
{
    // Check if already processed
    if (Cache::has("invoice_sent_{$this->invoiceId}")) {
        return;
    }

    $this->sendInvoice();

    Cache::set("invoice_sent_{$this->invoiceId}", true, 3600);
}

3. Use Appropriate Timeouts

Don't let jobs run forever, but give them enough time:

// API call: 30 seconds is plenty
#[Queueable(timeout: 30)]
class FetchExternalDataJob extends Job { }

// Video processing: need more time
#[Queueable(timeout: 600)]
class ProcessVideoJob extends Job { }

4. Log Generously

Future you will thank present you:

public function handle(): void
{
    Log::info("Starting report generation", ['report_id' => $this->reportId]);

    try {
        $data = $this->fetchData();
        Log::info("Data fetched", ['rows' => count($data)]);

        $report = $this->generateReport($data);
        Log::info("Report generated", ['size' => strlen($report)]);

    } catch (\Exception $e) {
        Log::error("Report generation failed", [
            'report_id' => $this->reportId,
            'error' => $e->getMessage()
        ]);
        throw $e;
    }
}

5. Use Chains for Dependent Workflows

When operations must happen in sequence:

Drain::conduct([
    new CreateUserAccountJob($userData),
    new SendWelcomeEmailJob($userId),
    new SetupUserPreferencesJob($userId),
    new NotifyAdminJob($userId)
])->dispatch();

This guarantees order and prevents partial states.

Job Lifecycle

When using the Doppar queue system, every job follows a structured lifecycle from dispatch to completion. Understanding this lifecycle helps you manage retries, failures, and queue processing more effectively.

The following diagram illustrates how Doppar handles single jobs and job chains, from dispatch to completion or failure:

┌─────────────────────────────────────────────────────────────────┐
│                    JOB DISPATCH LAYER                           │
└─────────────────────────────────────────────────────────────────┘
                             │
                 ┌───────────┴───────────┐
                 │                       │
                 ▼                       ▼
        ┌────────────────┐      ┌────────────────┐
        │  Single Job    │      │   Job Chain    │
        │   Dispatch     │      │     Drain      │
        └────────┬───────┘      └────────┬───────┘
                 │                       │
                 │                       │
                 └───────────┬───────────┘
                             │
                             ▼
┌─────────────────────────────────────────────────────────────────┐
│                   QUEUE STORAGE - Database                      │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │ queue_jobs:                                              │   │
│  │ • id, queue, payload, attempts, reserved_at,             │   │
│  │   available_at, created_at                               │   │
│  └──────────────────────────────────────────────────────────┘   │
└────────────────────────────┬────────────────────────────────────┘
                             │
                             ▼
┌─────────────────────────────────────────────────────────────────┐
│                     WORKER PROCESSING                           │
│  ┌────────────────────────────────────────────────────────┐     │
│  │ • Pop job from queue                                   │     │
│  │ • Reserve job - mark as processing                     │     │
│  │ • Increment attempts counter                           │     │
│  │ • Check others configuration like delayFor             │     │
│  │ • Execute with timeout protection                      │     │
│  └────────────────────────────────────────────────────────┘     │
└────────────────────────────┬────────────────────────────────────┘
                             │
                   ┌─────────┴─────────┐
                   │                   │
                SUCCESS             FAILURE
                   │                   │
                   ▼                   ▼
         ┌──────────────────┐  ┌──────────────────┐
         │ Job Completed    │  │ Job Failed       │
         │ Successfully     │  │ with Exception   │
         └────────┬─────────┘  └────────┬─────────┘
                  │                     │
                  ▼                     ▼
         ┌──────────────────┐  ┌──────────────────┐
         │ 1. Delete from   │  │ Check Retry      │
         │    queue_jobs    │  │ Logic            │
         │ 2. Check if      │  └────────┬─────────┘
         │    chained       │           │
         └────────┬─────────┘  ┌────────┴────────┐
                  │            │                 │
                  │         attempts < tries?    │
                  │            │                 │
                  │      ┌─────┘                 └─────┐
                  │      │ YES                      NO │
                  │      ▼                             ▼
                  │ ┌──────────────┐      ┌──────────────────┐
                  │ │ Release Job  │      │ Mark as Failed   │
                  │ │ Back to      │      │ • Move to        │
                  │ │ Queue with   │      │   failed_jobs    │
                  │ │ Delay        │      │ • Delete from    │
                  │ └──────────────┘      │   queue_jobs     │
                  │                       │ • Call failed()  │
                  │                       │   callback       │
                  │                       └──────────────────┘
                  │
        ┌─────────┴─────────┐
        │ Is job chained?   │
        └─────────┬─────────┘
                  │
          ┌───────┴───────┐
          │ YES           │ NO
          ▼               ▼
    ┌──────────────┐  ┌──────────────┐
    │ Check Chain  │  │ Job Complete │
    │ Status       │  │     End      │
    └──────┬───────┘  └──────────────┘
           │
    ┌──────┴──────┐
    │ More jobs   │
    │ in chain?   │
    └──────┬──────┘
           │
    ┌──────┴──────┐
    │ YES         │ NO
    ▼             ▼
┌──────────┐  ┌──────────────────┐
│ Dispatch │  │ Chain Complete   │
│ Next Job │  │ • Call then()    │
│  →chainA │  │   callback       │
│  →chainB │  │ • End            │
└──────────┘  └──────────────────┘

The Bottom Line

Doppar's queue system strikes an excellent balance between power and simplicity. The lifecycle is transparent, debugging is straightforward, and the code reads naturally.

Whether you're sending a few emails or orchestrating complex multi-step workflows with job chaining, Doppar gives you the tools to build reliable background processing systems that scale with your application.

The attribute-based configuration keeps everything explicit and close to your code. The robust retry logic and failure handling mean you can confidently dispatch jobs knowing they'll either succeed or fail gracefully with full visibility.

And when something does go wrong—because it always will eventually—the excellent monitoring and debugging tools help you understand and fix issues quickly.

If you're building a PHP application that needs background job processing, Doppar queues deserve a serious look. The lifecycle diagram we explored shows a system designed by developers who understand real-world production requirements, not just academic examples.

Give it a try. Your future self, debugging a failed job at 2 AM, will thank you for choosing a queue system that actually helps you understand what's happening.

Have you built anything interesting with Doppar queues? I'd love to hear about your use cases and experiences in the comments!

Doppar vs Laravel: Why Modern Attribute-Based DI is Winning Over Traditional Service Containers

Francisco Navarro — Mon, 15 Dec 2025 05:29:59 +0000

Dependency Injection containers are the backbone of modern PHP frameworks. They determine how clean your code looks, how testable it becomes, and ultimately, how much you'll enjoy working with the framework day-to-day. Laravel has long been the gold standard with its elegant container implementation, but Doppar is challenging that position with a fresh, attribute-driven approach that feels more aligned with modern PHP development.

Let me walk you through why Doppar's service container might just be the evolution we've been waiting for.

The Laravel Approach: Powerful but Verbose

Laravel's service container is genuinely excellent. It's mature, battle-tested, and incredibly powerful. When you need to bind an interface to a concrete implementation, you typically head to a service provider:

class AppServiceProvider extends ServiceProvider
{
    public function register()
    {
        $this->app->bind(
            UserRepositoryInterface::class,
            UserRepository::class
        );
    }
}

This works beautifully and has served millions of applications well. But here's where things get interesting—and where Doppar starts to shine.

Doppar also support this style

The Problem with Centralized Binding

In Laravel, your bindings live in service providers, separated from where they're actually used. This creates a mental overhead. When you're looking at a controller method, you can't immediately see which concrete class is being injected. You have to:

Open your service provider files
Search through potentially dozens of bindings
Hope the binding is where you expect it to be
Remember this context when you return to your controller

For small projects, this is manageable. But as your application grows to hundreds of classes and interfaces, this centralized approach becomes a game of hide-and-seek with your own code.

Enter Doppar: Context is King

Doppar takes a radically different approach. Instead of hiding your bindings away in service providers, it brings them right to where you need them—using PHP 8 attributes.

Parameter-Level Binding with #[Bind]

Here's where Doppar gets really interesting. You can bind dependencies exactly where you use them:

#[Route(uri: 'user/store', methods: ['POST'])]
public function store(
    #[Bind(UserRepository::class)] UserRepositoryInterface $userRepository
) {
    // The binding is right here, crystal clear
    $userRepository->save($data);
}

Look at how explicit this is. Anyone reading this code knows exactly which concrete class is being injected. No hunting through service providers. No mental gymnastics. The dependency and its resolution are in the same place.

Method-Level Binding with #[Resolver]

Sometimes you want a binding that applies to an entire method but might vary between methods:

class UserController extends Controller
{
    #[Resolver(abstract: UserRepositoryInterface::class, concrete: UserRepository::class)]
    public function index(UserRepositoryInterface $userRepository): Response
    {
        return $userRepository->getUsers();
    }

    #[Resolver(abstract: UserRepositoryInterface::class, concrete: CachedUserRepository::class)]
    public function dashboard(UserRepositoryInterface $userRepository): Response
    {
        // Same interface, different implementation
        return $userRepository->getDashboardData();
    }
}

This is impossible to achieve cleanly in Laravel without creating separate bindings and manually resolving them. Doppar makes contextual binding trivial.

Class-Level Binding

When you want consistent behavior across an entire controller, Doppar has you covered:

#[Resolver(UserRepositoryInterface::class, UserRepository::class)]
class UserController extends Controller
{
    public function index(UserRepositoryInterface $user): Response 
    {
        return $user->getUsers();
    }

    public function show(int $id, UserRepositoryInterface $user): Response
    {
        return $user->find($id);
    }
}

Every method in this controller automatically gets the same binding. It's visible, it's explicit, and it requires zero configuration elsewhere.

The Real-World Difference

Let's compare how both frameworks handle a realistic scenario: building an API that needs different repository implementations based on context.

Laravel Way

AppServiceProvider.php

public function register()
{
    // Base binding
    $this->app->bind(
        UserRepositoryInterface::class,
        UserRepository::class
    );

    // Need cached version? Create another binding
    $this->app->singleton(
        CachedUserRepositoryInterface::class,
        CachedUserRepository::class
    );
}

UserController.php

public function index(UserRepositoryInterface $repository)
{
    // Using the base repository
}

public function dashboard(CachedUserRepositoryInterface $repository)
{
    // Had to create a new interface just for caching
    // Not ideal
}

Doppar Way

UserController.php

#[Route('/users')]
public function index(
    #[Bind(UserRepository::class)] UserRepositoryInterface $repository
) {
    // Base repository, clearly defined
}

#[Route('/dashboard')]
public function dashboard(
    #[Bind(CachedUserRepository::class)] UserRepositoryInterface $repository
) {
    // Cached repository, same interface, zero extra interfaces needed
}

Everything you need to know is right there in the controller. No context switching. No extra interfaces. Just clean, explicit dependency injection.

Singleton Support: Both Win Here

Both frameworks handle singletons elegantly, but Doppar brings it closer to usage:

Laravel:

$this->app->singleton(PaymentService::class);

Doppar:

#[Bind(PaymentService::class, singleton: true)] PaymentServiceInterface $service

Doppar's approach makes the singleton nature visible at the injection point. You're not left wondering if something is a singleton—it's right there in the attribute.

Constructor Injection: Doppar's Hidden Gem

Here's something really elegant. Doppar lets you use attributes in constructors:

class PostController extends Controller
{
    public function __construct(
        #[Bind(PostRepository::class)] private PostRepositoryInterface $postRepository,
        #[Bind(CacheService::class, true)] private CacheInterface $cache
    ) {}

    #[Route('/posts')]
    public function index()
    {
        // $this->postRepository is ready to go
        // $this->cache is a singleton
    }
}

This is dependency injection that truly stays out of your way. The bindings are declarative, visible, and require zero setup in service providers.

When Would You Choose Laravel?

Let's be fair—Laravel isn't losing here, it's just different. There are scenarios where Laravel's approach makes more sense:

1. Global Application-Wide Bindings
If you need the same binding everywhere in your application, Laravel's centralized service providers are cleaner:

// One place, affects everything
$this->app->singleton(LoggerInterface::class, FileLogger::class);

2. Complex Binding Logic
When your binding needs conditional logic or multiple dependencies:

$this->app->bind(PaymentProcessor::class, function ($app) {
    $config = $app->make('config');

    if ($config->get('payment.provider') === 'stripe') {
        return new StripeProcessor($app->make(StripeClient::class));
    }

    return new PayPalProcessor($app->make(PayPalClient::class));
});

This kind of complex conditional binding is harder to express in attributes.

3. Package Development
If you're building packages that provide services to other applications, Laravel's service provider approach is more conventional and expected.

When Doppar Dominates

Doppar shines in scenarios that represent most of modern application development:

1. Rapid Feature Development
When you're building features quickly and need to see exactly what's being injected:

#[Route('/reports/generate')]
public function generate(
    #[Bind(PDFGenerator::class)] ReportGenerator $generator,
    #[Bind(S3Storage::class)] StorageInterface $storage
) {
    // Everything needed is visible right here
}

2. Contextual Variations
When different endpoints need different implementations:

#[Route('/api/v1/users')]
#[Resolver(UserRepositoryInterface::class, RestUserRepository::class)]
public function v1() { }

#[Route('/api/v2/users')]
#[Resolver(UserRepositoryInterface::class, GraphQLUserRepository::class)]
public function v2() { }

3. Team Collaboration
When multiple developers are working on the same codebase. With Doppar, they don't need to coordinate service provider edits—bindings are localized.

4. Testing and Mocking
While both frameworks support testing, Doppar's explicit bindings make it easier to understand what needs mocking:

// You know exactly what this method depends on
#[Bind(EmailService::class)] EmailServiceInterface $email

Performance: A Tie

Both containers are highly optimized. Laravel has years of performance tuning. Doppar's attribute parsing happens during bootstrap and is cached. In practice, you won't notice a difference.

Developer Experience: Doppar Edges Ahead

Here's where Doppar really wins—the daily development experience.

Less Context Switching
You're not constantly jumping between controllers and service providers. Everything you need is visible in your IDE.

Better IDE Support
Modern IDEs understand attributes well. You get autocomplete, refactoring support, and "go to definition" working perfectly.

Clearer Code Reviews
Reviewers can see exactly what's being injected without opening multiple files. Code review comments like "why is this using CachedRepository?" are answered immediately by looking at the attribute.

Easier Debugging
When something goes wrong, you're not hunting through service providers trying to figure out which concrete class is actually being injected.

The Future is Attribute-Based

Doppar isn't just different—it's showing us where PHP frameworks are heading. Attributes give us the power to make our code more declarative and self-documenting. Why hide your dependency configuration in separate files when you can declare it right where it matters?

Laravel proved that dependency injection could be elegant. Doppar is proving it can be even better—more explicit, more localized, and more aligned with how we actually think about code.

The winner? Developers who value clarity and modern PHP practices. Doppar is here to stay, and it's raising the bar for what we should expect from our dependency injection containers.

What's your take? Have you tried attribute-based dependency injection? Let me know in the comments—I'd love to hear about your experiences with both approaches.

Laravel, Symfony, Doppar in 2026 — Which PHP Framework Should You Pick

Francisco Navarro — Fri, 12 Dec 2025 04:55:51 +0000

Welcome to the near future. It’s almost 2026. If you are reading this, you already know the truth that many outsiders deny: PHP is not dead. In fact, it’s faster, stricter, and more capable than it has ever been. Modern PHP is a powerhouse driving a massive chunk of the enterprise web.

But as we look toward the next few years of development, the question isn't "Should I use PHP?" The question is, "Which flavor of PHP will power my next big idea?"

For the past decade, this conversation has been dominated by a duopoly: the elegant giant, Laravel, and the industrial bedrock, Symfony. They have defined modern PHP development.

However, as we approach 2026, the landscape is shifting. The demand for raw speed, lower latency, and integrated real-time features is pushing the boundaries of what traditional architectures can deliver comfortably.

Enter Doppar

In this deep-dive comparison, we aren't just listing features. We are looking at the philosophy, the ecosystem, and the "soul" of three frameworks—Laravel, Symfony, and Doppar—to understand why, in 2026, any one of them could be the perfect foundation for your next application.

The reigning Titan: Laravel

If you have written PHP in the last ten years, you have felt the influence of Laravel. It is unparalleled in its popularity for one very specific reason: it prioritizes "developer happiness" above almost all else.

Laravel's philosophy is that coding should be an enjoyable, creative experience, not a painful slog through configuration files.

The "Magic" and the Velocity

Laravel is famous (and sometimes criticized by purists) for its "magic." It uses facades, dynamic method calling, and clever service container resolution to make complex tasks feel incredibly simple.

Want to send an email, dispatch a queued job, and fire an event? In Laravel, that might be three readable lines of code that just work. The framework handles the messy wiring in the background. For startups, MVPs (Minimum Viable Products), and agencies working on tight deadlines, this "magic" translates directly to velocity. You can ship features in Laravel faster than almost any other backend framework in existence.

The Ecosystem as a Moat

By 2026, Laravel's biggest strength isn't just the framework code; it's the massive, commercial ecosystem surrounding it.

If you choose Laravel, you aren't just getting a router and an ORM. You have access to first-party tools that solve almost every adjacent infrastructure problem:

Laravel Forge & Vapor: Server provisioning and serverless deployment made trivial.
Laravel Nova & Filament: Beautiful administration panels generated in minutes.
Laravel Echo & Reverb: Real-time WebSocket handling.
Laravel Horizon: glorious GUI for managing Redis queues.

This ecosystem is a massive "moat." You never have to leave the "Laravel Way" of doing things.

The 2026 Outlook for Laravel

In 2026, Laravel remains the default choice for 80% of new projects. It is mature, stable, and its developer experience is still unmatched. Its only real downside is that the layers of "magic" that make it easy to write can sometimes make it harder to debug performance bottlenecks in highly complex, high-load scenarios. It carries a lot of weight to provide that comfort.

The Enterprise Bedrock: Symfony

If Laravel is a sleek sports car designed for the driver's enjoyment, Symfony is the heavy-duty, precision-engineered freight train designed to haul massive loads forever without breaking down.

Symfony’s philosophy is fundamentally different. It prioritizes explicitness, stability, standard compliance (PSRs), and decoupling over "magic."

The Component Philosophy

Symfony’s genius lies in its architecture. It isn't just a monolithic framework; it is a collection of decoupled, reusable PHP libraries called "Components."

The HTTP Foundation component, the Console component, the Routing component—these are the gold standards of PHP code. They are so good that they actually power the guts of Laravel, Drupal, and countless other projects.

When you use the full-stack Symfony framework, you are gluing these robust components together. This means Symfony applications are incredibly stable and easier to upgrade over long periods (think 5–10 year lifecycles).

Explicit over Implicit

In 2026, Symfony remains the choice for complex enterprise domains where clarity is more important than speed of writing.

In Laravel, things often work "automatically" based on naming conventions. In Symfony, you usually have to explicitly configure things (often using attributes or YAML). This means more typing initially—a steeper learning curve—but it pays tremendous dividends when you come back to the code two years later. There is zero ambiguity about what a class does or how a service is wired together.

Symfony forces you to be a better architect. It nudges you toward Design Patterns, Dependency Injection, and SOLID principles more firmly than Laravel does.

The 2026 Outlook for Symfony
In 2026, Symfony is the backbone of serious, long-term corporate PHP. It is the choice for large teams working on complex business logic where maintainability is paramount. It is less "fun" than Laravel, but it is incredibly reliable.

The Disruptive Speedster: Doppar

And now, the new reality of 2026. For years, the argument was: "Use Laravel for speed of development, use Symfony for stability, and if you need raw performance... well, maybe use Go or Rust."

Doppar has entered the chat to violently disrupt that last point.

Doppar is a modern, high-performance PHP framework that attempts to solve the "have your cake and eat it too" dilemma. Its goal is to offer the elegant, expressive syntax developers love in Laravel, combined with the raw execution speed usually reserved for micro-frameworks or compiled languages.

The Need for Speed (and How Doppar Gets It)

By 2026, web applications are heavier than ever. We demand sub-50ms API responses even while doing complex logic. Traditional frameworks, with their massive initialization processes (booting up hundreds of files on every request), struggle to hit those metrics under load without massive hardware throwing at them.

Doppar achieves its "blazing fast" status by having an incredibly lightweight core and intelligently memoizing repeated executions. It is engineered to minimize the "boot tax" that plagues heavier frameworks.

Built-in Modernity: Airbend and Scheduling

Doppar isn't just a stripped-down router. It’s designed for the demands of 2026 applications right out of the box.

Two areas where it shines are real-time data and scheduling:

Airbend (WebSockets): In Laravel or Symfony, handling high-performance, real-time WebSockets usually means bringing in external services (like Pusher) or running separate Node.js servers. Doppar includes "Airbend," a native, high-performance WebSocket component designed for seamless broadcasting. It’s baked in, not bolted on.
Dual-Mode Scheduling: Traditional PHP cron jobs run once a minute. In 2026, that's often too slow. We need things to run every second, or continuously. Doppar includes a daemon-mode scheduler that handles sub-minute tasks efficiently without needing complex Supervisor setups.

The "Hook-Driven" ORM

Doppar’s approach to databases is also unique. Its ORM is designed to be fast and clean, avoiding third-party dependencies. It utilizes a "Hook-Driven Model Architecture," allowing developers to tap into model lifecycles (boot, update, create) with inline logic or classes, keeping business logic clean without the overhead of heavy event observers often found in other ORMs.

The 2026 Outlook for Doppar

In 2026, Doppar is the exciting choice for performance-critical applications. It is where APIs that are crushing under load go to find relief. It is the choice for developers who love PHP's syntax but are tired of optimizing heavy frameworks.

Doppar is the newcomer. In 2026, its ecosystem is growing, but it cannot compete with the sheer volume of packages available for Laravel or Symfony. Choosing Doppar means you might have to write some integrations yourself that you could otherwise just composer require in Laravel. You choose Doppar despite its smaller ecosystem because you need its specific advantages (speed and real-time).

Conclusion: Your 2026 Toolkit

The beauty of the PHP landscape in 2026 is that we aren't forced into a one-size-fits-all solution. The maturity of the language means we now have specialized tools for different jobs.

Choose Laravel in 2026 if: You need to move fast. You are building a startup MVP, a standard SaaS platform, or an application that needs a ton of standard features (auth, billing, notifications) out of the box. You value developer velocity and a cohesive ecosystem above absolute architectural purity or raw throughput speed.

Choose Symfony in 2026 if: You are building a complex, long-lifecycle enterprise application with a large team. You need strict adherence to standards, clear separation of concerns, and a framework that forces you to make good architectural decisions that will stand the test of time. Stability is your North Star.

Choose Doppar in 2026 if: Performance is a primary requirement, not an afterthought. You are building high-load APIs, real-time applications using WebSockets, or systems requiring second-level task scheduling. You love the expressive syntax of modern PHP but want a framework that runs lean and mean, cutting out the bloat to deliver maximum efficiency.

The PHP renaissance is here to stay. Whether you choose the Titan, the Bedrock, or the Speedster, it’s a great time to be a PHP developer.

Dynamic Todo App with Search & Filter in Doppar

Francisco Navarro — Wed, 03 Dec 2025 11:00:24 +0000

In the world of PHP development, CRUD (Create, Read, Update, Delete) applications are the “Hello World” of mastering a new framework. However, a real-world application requires more than just listing database rows. It needs robust searching, intelligent filtering, pagination, and secure state management.

Today, we are going to dissect a fully functional Todo application built using the Doppar Framework. We will walk through the codebase step-by-step, exploring how Doppar handles Modern PHP attributes, Route Model Binding, dynamic query building, and template rendering.

By the end of this guide, you will understand how to implement a feature-rich CRUD system with a clean, maintainable architecture.

Database Migration

Every great application starts with a solid database schema. In Doppar, we use migrations to define the structure of our tables. This ensures version control for our database.

We start by running the CLI command:

php pool make:model Todo --m

This creates both the Model and the Migration file. Let’s look at the migration logic:

use Phaseolies\Support\Facades\Schema;
use Phaseolies\Database\Migration\Blueprint;

public function up(): void
{
    Schema::create('todo', function (Blueprint $table) {
        $table->id();
        $table->string('todo', 100);
        $table->unsignedBigInteger('user_id');
        $table->boolean('status')->default(false);
        $table->timestamps();
    });
}

Now run the migration

php pool migrate

The Model: Logic and Relationships

The Model in Doppar isn’t just a data container; it’s the logic layer that interacts with the database. Let’s examine App\Models\Todo.php

Mass Assignment Protection

protected $creatable = ["todo", "user_id", "status"];

Doppar uses the $creatable property to prevent Mass Assignment vulnerabilities. This acts as a whitelist. Only these fields can be filled via Todo::create([]) or $todo->update([]). This prevents malicious users from injecting fields like is_admin or id into the request.

Defining Relationships

The bindTo method explicitly connects the Todo to the User. This allows us to later fetch the creator of a Todo easily (e.g., $todo->user->name).

public function user()
{
    $this->bindTo(User::class, 'id', 'user_id');
}

The Magic of doppar query binding: __byStatus

This is a standout feature in the provided code:

public function __byStatus(Builder $builder, ?bool $status)
{
    return $builder->whereStatus($status);
}

This magic method acts as a Query Binding. When the controller calls $q->byStatus($val), the framework looks for __byStatus. This keeps our controller code clean. Instead of writing raw where clauses in the controller, we encapsulate that logic inside the Model.

Full Todo Model

<?php

namespace App\Models;

use Phaseolies\Database\Entity\Builder;
use Phaseolies\Database\Entity\Model;

class Todo extends Model
{
    protected $creatable = ["todo", "user_id", "status"];

    public function user()
    {
        $this->bindTo(User::class, 'id', 'user_id');
    }

    public function __byStatus(Builder $builder, ?bool $status)
    {
        return $builder->whereStatus($status);
    }
}

The Controller

The TodoController is where the magic happens. It utilizes PHP 8 Attributes extensively, making the code declarative and easy to read.

create controller

php pool make:controller Todo/TodoController

And this is full version of controller

<?php

namespace App\Http\Controllers\Todo;

use Phaseolies\Utilities\Attributes\Route;
use Phaseolies\Utilities\Attributes\Mapper;
use Phaseolies\Http\Request;
use App\Models\Todo;
use App\Http\Controllers\Controller;
use Phaseolies\Utilities\Attributes\Model;

#[Mapper(prefix: 'todo', middleware: ['auth'])]
class TodoController extends Controller
{
    #[Route(uri: '/', name: 'todo.index')]
    public function index()
    {
        $todos = Todo::embed('user:name')
            ->if(
                request()->status !== 'all' && request()->status !== null,
                fn($q) => $q->byStatus(request()->status)
            )
            ->search([
                'todo',
                'user.name'
            ], request()->search)
            ->newest('id')
            ->paginate(5);

        return view('todo.index', compact('todos'));
    }

    #[Route(uri: 'create', name: 'todo.create')]
    public function create()
    {
        return view('todo.create');
    }

    #[Route(uri: 'store', name: 'todo.store', methods: ['POST'])]
    public function store(Request $request)
    {
        $request->sanitize([
            'todo' => 'required|min:3|max:30'
        ]);

        Todo::create([
            'todo' => $request->todo,
            'status' => (int) $request->status,
            'user_id' => auth()->id()
        ]);

        return redirect()->route('todo.index')->withSuccess('Todo created successfully');
    }

    #[Route(uri: 'edit/{todo}', name: 'todo.edit')]
    public function edit(#[Model(exception: true)] Todo $todo)
    {
        return view('todo.edit', compact('todo'));
    }

    #[Route(uri: 'update/{todo}', name: 'todo.update', methods: ['PATCH'])]
    public function update(#[Model(exception: true)] Todo $todo, Request $request)
    {
        $request->sanitize([
            'todo' => 'required|min:3|max:30'
        ]);

        $todo->update([
            'todo' => $request->todo,
            'status' => (int) $request->status
        ]);

        return redirect()->route('todo.index')->withSuccess('Todo updated successfully');
    }

    #[Route(uri: 'delete/{todo}', name: 'todo.delete', methods: ['DELETE'])]
    public function delete(#[Model(exception: true)] Todo $todo)
    {
        $todo->delete();

        return redirect()->route('todo.index')->withSuccess('Todo deleted successfully');
    }
}

Route Model Binding

Look at the update and delete methods:

public function delete(#[Model(exception: true)] Todo $todo)

Instead of accepting an $id and finding the Todo manually (e.g., $todo = Todo::find($id)), we use the #[Model] attribute. Doppar automatically finds the Todo based on the ID in the URL. If it’s not found, the exception: true flag triggers a 404 error page. This reduces boilerplate code significantly.

The Frontend: Odo & Bootstrap

Layout

<!DOCTYPE html>
<html lang="en" data-theme="light">
    <head>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <title>#yield('title')</title>
        <!-- Bootstrap 5 CSS -->
        <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" rel="stylesheet">
        <!-- Box Icon -->
        <link href='https://unpkg.com/boxicons@2.1.4/css/boxicons.min.css' rel='stylesheet'>
        <meta name="csrf-token" content="[[ csrf_token() }}">
        <style>
           *,.sidebar-menu ul{padding:0}body{color:var(--text-primary);font-family:Inter,-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,sans-serif;background:var(--bg-secondary);overflow-x:hidden}.sidebar-menu ul,.submenu{list-style:none}.card,.dropdown-menu,.search-box input:focus,.sidebar,.toggle-collapse,.top-nav{background:var(--bg-primary)}.sidebar,.toggle-collapse,.top-nav{background:var(--bg-secondary)}.toast,.top-nav{backdrop-filter:blur(10px)}:root{--bg-primary:#ffffff;--bg-secondary:#F0F4F9;--bg-tertiary:#e9ecef;--text-primary:#1a1d29;--text-secondary:#6c757d;--text-muted:#adb5bd;--border-color:#c5c5c5;--shadow:rgba(0, 0, 0, 0.08);--shadow-lg:rgba(0, 0, 0, 0.12);--primary:#6366f1;--primary-hover:#4f46e5;--primary-light:#eef2ff;--success:#10b981;--danger:#ef4444;--warning:#f59e0b;--info:#3b82f6;--sidebar-width:280px;--sidebar-collapsed:80px;--header-height:70px}*{margin:0;box-sizing:border-box}.sidebar{width:var(--sidebar-width);height:100vh;position:fixed;left:0;top:0;z-index:1100;display:flex;flex-direction:column}.search-box i{top:50%;transform:translateY(-50%)}.sidebar.collapsed{width:var(--sidebar-collapsed)}.sidebar-header{height:var(--header-height);padding:0 1.5rem;display:flex;align-items:center;justify-content:space-between;position:relative}.logo{transition:opacity .3s}.sidebar.collapsed .logo{opacity:0;pointer-events:none}.sidebar.collapsed .chevron,.sidebar.collapsed .menu-text,.sidebar.collapsed .sidebar-company-title,.sidebar.collapsed .sidebar-header::after,.submenu{display:none}.dropdown-menu,.toast{box-shadow:0 10px 40px var(--shadow-lg)}.dropdown-item:hover,.sidebar-menu li a:hover,.sidebar-menu li.active a,.theme-toggle:hover{color:var(--primary)}.toggle-collapse{position:relative;cursor:pointer;border:none;border-radius:8px;width:40px;height:40px;display:flex;align-items:center;justify-content:center;transition:.3s;order:1}.sidebar-menu{flex:1;padding:1rem;overflow-y:auto}.sidebar-menu::-webkit-scrollbar{width:6px}.sidebar-menu::-webkit-scrollbar-track{background:0 0}.sidebar-menu::-webkit-scrollbar-thumb{background:var(--border-color);border-radius:3px}.sidebar-menu li a{display:flex;align-items:center;padding:.475rem 1rem;color:var(--text-secondary);text-decoration:none;transition:.2s;font-weight:500;font-size:.95rem;position:relative;overflow:hidden}.sidebar-menu li a i{width:24px;margin-right:12px;font-size:1.1rem;transition:transform .2s}.sidebar.collapsed .sidebar-menu li a{justify-content:center;padding:.875rem}.sidebar.collapsed .sidebar-menu li a i{margin-right:0}.submenu{margin:.5rem 0 0 2.5rem;padding:.5rem 0;animation:.3s slideDown}@keyframes slideDown{from{opacity:0;transform:translateY(-10px)}to{opacity:1;transform:translateY(0)}}.sidebar-menu li.has-submenu.active>.submenu{display:block}.submenu li{margin-bottom:.25rem}.submenu li a{padding:.625rem 1rem;font-size:.875rem;margin-left:0}.chevron{margin-left:auto;font-size:.75rem;transition:transform .3s}.sidebar-menu li.has-submenu.active>a .chevron{transform:rotate(180deg)}.main-content{margin-left:var(--sidebar-width);transition:margin-left .3s cubic-bezier(.4, 0, .2, 1);min-height:100vh}.main-content.collapsed{margin-left:var(--sidebar-collapsed)}.top-nav{height:var(--header-height);position:sticky;top:0;z-index:1000}.profile-dropdown,.search-box input,.theme-toggle{background:var(--bg-secondary);color:var(--text-primary)}.nav-container{height:100%;align-items:center;display:flex;padding:0 2rem}.mobile-menu-btn,.theme-toggle{width:40px;height:40px;cursor:pointer}.nav-actions,.theme-toggle{align-items:center;display:flex}.nav-actions{gap:1rem;margin-left:auto}.dropdown-item,.profile-dropdown{transition:.2s;display:flex;gap:.75rem}.theme-toggle{border-radius:12px;border:none;transition:.2s;justify-content:center}.theme-toggle:hover{transform:scale(1.05)}.profile-dropdown{align-items:center;padding:.5rem 1rem;border-radius:12px;cursor:pointer;text-decoration:none}.profile-dropdown:hover{background:var(--primary-light);transform:translateY(-2px);box-shadow:0 4px 12px var(--shadow)}.profile-info{display:flex;flex-direction:column;align-items:flex-start}.profile-name{font-weight:600;font-size:.875rem;line-height:1.2}.profile-role{font-size:.75rem;color:var(--text-muted)}.dropdown-menu{border:1px solid var(--border-color);border-radius:12px;padding:.5rem;margin-top:.5rem}.dropdown-item{padding:.75rem 1rem;border-radius:8px;color:var(--text-primary);align-items:center}.dropdown-item i{width:20px}.content-wrapper{padding:2rem}.toast-body,.toast-header{padding:1rem 1.25rem}.toast{border:none;border-radius:12px}.toast-header{border-bottom:none;border-radius:12px 12px 0 0}@media (max-width:576px){.search-box{display:none}}.card{border:1px solid var(--border-color);border-radius:16px;background:#fff;box-shadow:0 2px 4px rgba(0,0,0,.08),0 0 1px rgba(0,0,0,.1);padding:10px}.btn-dark{background:var(--primary);border-color:var(--primary);border-radius:12px;padding:.625rem 1.5rem;font-weight:500;transition:.2s}.btn-dark:hover{background:var(--primary-hover);border-color:var(--primary-hover);transform:translateY(-2px);box-shadow:0 4px 12px rgba(99,102,241,.3)}.mobile-menu-btn{display:none;border-radius:12px;background:var(--bg-secondary);border:none;color:var(--text-primary)}@media (max-width:992px){.sidebar{transform:translateX(-100%)}.sidebar.show{transform:translateX(0)}.main-content{margin-left:0}.nav-container{padding:0 1rem}.profile-info{display:none}.mobile-menu-btn{display:flex;align-items:center;justify-content:center}}.sidebar-company-title{font-size:30px;padding:6px;font-weight:700;margin-left:0;order:2;flex:1;text-align:center}.sidebar-header::after{content:'';width:60px;order:3}
        </style>
    </head>
    <body>
        <div class="sidebar">
            <div class="sidebar-header">
                <div class="layout-menu-toggle toggle-collapse" id="toggle-collapse">
                    <i class="bx bx-menu bx-sm"></i>
                </div>
                <div class="sidebar-company-title">
                    doppar
                </div>
            </div>
            <div class="sidebar-menu">
                <ul>
                    <li class="[[ Request::is('/home') ? 'active' : '' ]]">
                        <a href="[[ route('dashboard') ]]">
                            <i class='bx bxs-dashboard'></i>
                            <span class="menu-text">Dashboard</span>
                        </a>
                    </li>
                    <li class="[[ Request::is('/todo') ? 'active' : '' ]]">
                        <a href="[[ route('todo.index') ]]">
                            <i class='bx bxs-dashboard'></i>
                            <span class="menu-text">Todo</span>
                        </a>
                    </li>
                </ul>
            </div>
        </div>
        <div class="main-content">
            <nav class="top-nav">
                <div class="nav-container">
                    <div class="nav-actions">
                        <button class="theme-toggle" id="themeToggle">
                            <i class='bx bx-moon'></i>
                        </button>
                        <div class="dropdown">
                            <a href="#" class="profile-dropdown dropdown-toggle" data-bs-toggle="dropdown">
                                <div class="profile-info">
                                    <span class="profile-name">[[ Auth::user()?->name ]]</span>
                                </div>
                            </a>
                            <div class="dropdown-menu dropdown-menu-end">
                                <a href="[[ route('profile') ]]" class="dropdown-item">
                                    <i class='bx bx-user-circle'></i> Profile
                                </a>
                                <div class="dropdown-divider"></div>
                                <form action="[[ route('logout') ]]" method="POST">
                                    @csrf
                                    <button type="submit" class="dropdown-item">
                                        <i class='bx bx-log-out'></i> Logout
                                    </button>
                                </form>
                            </div>
                        </div>
                    </div>
                </div>
            </nav>
            <div class="content-wrapper">
                #if (session()->has('success'))
                    <div class="position-fixed bottom-0 end-0 p-3" style="z-index: 11">
                        <div class="toast show" role="alert">
                            <div class="toast-header bg-success text-white">
                                <strong class="me-auto">Success!</strong>
                                <small class="text-white">Just now</small>
                                <button type="button" class="btn-close btn-close-white"
                                    data-bs-dismiss="toast"></button>
                            </div>
                            <div class="toast-body bg-light">
                                <div class="d-flex align-items-center">
                                    <i class='bx bxs-badge-check text-success me-2 fs-4'></i>
                                    <span>[[ session()->pull('success') ]]</span>
                                </div>
                            </div>
                        </div>
                    </div>
                #endif
                #if (session()->has('error'))
                    <div class="position-fixed bottom-0 end-0 p-3" style="z-index: 11">
                        <div class="toast show" role="alert">
                            <div class="toast-header bg-danger text-white">
                                <strong class="me-auto">Error!</strong>
                                <small class="text-white">Just now</small>
                                <button type="button" class="btn-close btn-close-white"
                                    data-bs-dismiss="toast"></button>
                            </div>
                            <div class="toast-body bg-light">
                                <div class="d-flex align-items-center">
                                    <i class="bx bxs-error-circle text-danger me-2 fs-4"></i>
                                    <span>[[ session()->pull('error') ]]</span>
                                </div>
                            </div>
                        </div>
                    </div>
                #endif
                #yield('content')
            </div>
        </div>
        <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/js/bootstrap.bundle.min.js"></script>
        <script>
            document.addEventListener('DOMContentLoaded', function() {
                // Mobile Toggle
                const mobileToggle = document.querySelector('.mobile-menu-btn');
                const sidebar = document.querySelector('.sidebar');

                if (mobileToggle) {
                    mobileToggle.addEventListener('click', function() {
                        sidebar.classList.toggle('show');
                    });
                }

                // Sidebar Collapse Toggle
                const toggleCollapse = document.querySelector('.toggle-collapse');
                toggleCollapse.addEventListener('click', function() {
                    sidebar.classList.toggle('collapsed');
                    document.querySelector('.main-content').classList.toggle('collapsed');

                    const icon = this.querySelector('i');
                    if (sidebar.classList.contains('collapsed')) {
                        icon.classList.replace('bx-chevron-left', 'bx-chevron-right');
                    } else {
                        icon.classList.replace('bx-chevron-right', 'bx-chevron-left');
                    }
                });

                // Submenu Toggle
                document.querySelectorAll('.sidebar-menu li.has-submenu > a').forEach(function(menuLink) {
                    menuLink.addEventListener('click', function(e) {
                        if (sidebar.classList.contains('collapsed')) return;

                        e.preventDefault();
                        const parentLi = this.parentElement;
                        const wasActive = parentLi.classList.contains('active');

                        document.querySelectorAll('.sidebar-menu li.has-submenu').forEach(function(
                            item) {
                            if (item !== parentLi) {
                                item.classList.remove('active');
                            }
                        });

                        parentLi.classList.toggle('active', !wasActive);
                    });
                });

                // Theme Toggle
                const themeToggle = document.getElementById('themeToggle');
                const html = document.documentElement;
                const icon = themeToggle.querySelector('i');

                // Load saved theme
                const savedTheme = localStorage.getItem('theme') || 'light';
                html.setAttribute('data-theme', savedTheme);
                updateThemeIcon(savedTheme);

                themeToggle.addEventListener('click', function() {
                    const currentTheme = html.getAttribute('data-theme');
                    const newTheme = currentTheme === 'light' ? 'dark' : 'light';

                    html.setAttribute('data-theme', newTheme);
                    localStorage.setItem('theme', newTheme);
                    updateThemeIcon(newTheme);
                });

                function updateThemeIcon(theme) {
                    if (theme === 'dark') {
                        icon.classList.replace('bx-moon', 'bx-sun');
                        const style = document.createElement('style');
                        style.id = 'dark-mode-filter';
                        style.textContent =
                            'html,iframe,img,video{ filter: invert(1) hue-rotate(180deg); opacity: 1; }';
                        document.head.appendChild(style);
                    } else {
                        icon.classList.replace('bx-sun', 'bx-moon');
                        const darkStyle = document.getElementById('dark-mode-filter');
                        if (darkStyle) {
                            darkStyle.remove();
                        }
                    }
                }

                // Apply filter on initial load if dark mode
                if (savedTheme === 'dark') {
                    const style = document.createElement('style');
                    style.id = 'dark-mode-filter';
                    style.textContent = 'html,iframe,img,video{ filter: invert(1) hue-rotate(180deg); opacity: 1; }';
                    document.head.appendChild(style);
                }
                // Auto-hide toasts
                setTimeout(function() {
                    const toasts = document.querySelectorAll('.toast');
                    toasts.forEach(toast => {
                        const bsToast = new bootstrap.Toast(toast);
                        bsToast.hide();
                    });
                }, 5000);
            });
        </script>
    </body>
</html>

index.odo.php

#extends('layouts.app')
#section('title')
Todos
#endsection
#section('content')
<h2 class="az-content-title">Todos</h2>
<div class="d-flex justify-content-between align-items-center mb-3">
    <form action="#" method="GET" class="mr-3">
        <div class="input-group">
            <input type="text" name="search" class="form-control" placeholder="Search users..."
                value="[[ request('search') ]]" style="height: 38px;">
            &nbsp;
            <div class="input-group-append">
                <select name="status" class="form-control">
                    <option value="all" selected>All</option>
                    <option value="1">Active</option>
                    <option value="0">Inactive</option>
                </select>
            </div>
            &nbsp;
            <div class="input-group-append">
                <button class="btn btn-outline-secondary" type="submit">
                    <svg width="20" height="20" fill="currentColor" xmlns="http://www.w3.org/2000/svg"
                        viewBox="0 0 20 20">
                        <path fill-rule="evenodd"
                            d="M12.442 12.442a1 1 0 011.415 0l3.85 3.85a1 1 0 01-1.414 1.415l-3.85-3.85a1 1 0 010-1.415z"
                            clip-rule="evenodd" />
                        <path fill-rule="evenodd"
                            d="M8.5 14a5.5 5.5 0 100-11 5.5 5.5 0 000 11zM15 8.5a6.5 6.5 0 11-13 0 6.5 6.5 0 0113 0z"
                            clip-rule="evenodd" />
                    </svg>
                </button>
            </div>
        </div>
    </form>
    <div>
        <a href="[[ route('todo.create') ]]" class="btn btn-outline-primary btn-rounded btn-block">
            Create New Todo
        </a>
    </div>
</div>
<div class="card">
    <div class="card-body">
        <div class="table-responsive mt-3">
            <table class="table table-striped mg-b-5">
                <thead>
                    <tr>
                        <th>ID</th>
                        <th>Todo</th>
                        <th>Created By</th>
                        <th>Created At</th>
                        <th>Status</th>
                        <th>Action</th>
                    </tr>
                </thead>
                <tbody>
                    #foreach ($todos['data'] ?? [] as $todo)
                    <tr>
                        <th scope="row">[[ $todo->id ]]</th>
                        <td>[[ $todo->todo ]]</td>
                        <td>[[ $todo->user?->name ]]</td>
                        <td>[[ \Carbon\Carbon::parse($todo->created_at)->diffForHumans() ]]</td>
                        <td>[[ $todo->status ]]</td>
                        <td>
                            <a href="[[ route('todo.edit', $todo->id) ]]">
                                <svg width="40" height="20" viewBox="0 0 24 24" fill="none"
                                    xmlns="http://www.w3.org/2000/svg" transform="rotate(0 0 0)">
                                    <path
                                        d="M20.75 18.5V8.67794L19.25 10.1779V18.5C19.25 18.9142 18.9142 19.25 18.5 19.25H5.5C5.08579 19.25 4.75 18.9142 4.75 18.5V5.5C4.75 5.08579 5.08579 4.75 5.5 4.75H18.314L19.2936 3.77034C19.3842 3.67974 19.4806 3.59848 19.5816 3.52657C19.2607 3.35027 18.8921 3.25 18.5 3.25H5.5C4.25736 3.25 3.25 4.25736 3.25 5.5V18.5C3.25 19.7426 4.25736 20.75 5.5 20.75H18.5C19.7426 20.75 20.75 19.7426 20.75 18.5Z"
                                        fill="#7ea30f" />
                                    <path
                                        d="M20.4838 6.51868C20.7767 6.22578 20.7767 5.75091 20.4838 5.45802C20.1909 5.16512 19.7161 5.16512 19.4232 5.45802L11.9298 12.9514L8.57686 9.59849C8.28396 9.3056 7.80909 9.3056 7.5162 9.5985C7.22331 9.89139 7.22331 10.3663 7.5162 10.6592L11.3995 14.5424C11.6924 14.8353 12.1672 14.8353 12.4601 14.5424L20.4838 6.51868Z"
                                        fill="#7ea30f" />
                                </svg>
                            </a>
                            <form method="POST" action="[[ route('todo.delete', $todo->id) ]]" class="d-inline">
                                #csrf
                                #method('DELETE')
                                <button type="submit" class="btn btn-link p-0 border-0"
                                    onclick="return confirm('Are you sure you want to delete this item?');">
                                    <svg width="40" height="20" viewBox="0 0 24 24" fill="none"
                                        xmlns="http://www.w3.org/2000/svg">
                                        <path
                                            d="M7.99902 4.25C7.99902 3.00736 9.00638 2 10.249 2H13.749C14.9917 2 15.999 3.00736 15.999 4.25V5H18.498C19.7407 5 20.748 6.00736 20.748 7.25C20.748 8.28958 20.043 9.16449 19.085 9.42267C18.8979 9.4731 18.7011 9.5 18.498 9.5H5.5C5.29694 9.5 5.10016 9.4731 4.91303 9.42267C3.95503 9.16449 3.25 8.28958 3.25 7.25C3.25 6.00736 4.25736 5 5.5 5H7.99902V4.25ZM14.499 5V4.25C14.499 3.83579 14.1632 3.5 13.749 3.5H10.249C9.83481 3.5 9.49902 3.83579 9.49902 4.25V5H14.499Z"
                                            fill="#dc3545" />
                                        <path
                                            d="M4.97514 10.4578L5.54076 19.8848C5.61205 21.0729 6.59642 22 7.78672 22H16.2113C17.4016 22 18.386 21.0729 18.4573 19.8848L19.0229 10.4578C18.8521 10.4856 18.6767 10.5 18.498 10.5H5.5C5.32131 10.5 5.146 10.4856 4.97514 10.4578ZM10.774 13.4339L10.9982 17.9905C11.0185 18.4042 10.6996 18.7561 10.2859 18.7764C9.8722 18.7968 9.52032 18.4779 9.49997 18.0642L9.27581 13.5076C9.25546 13.0938 9.57434 12.742 9.98805 12.7216C10.4018 12.7013 10.7536 13.0201 10.774 13.4339ZM14.0101 12.7216C14.4238 12.742 14.7427 13.0938 14.7223 13.5076L14.4982 18.0642C14.4778 18.4779 14.1259 18.7968 13.7122 18.7764C13.2985 18.7561 12.9796 18.4042 13 17.9905L13.2241 13.4339C13.2445 13.0201 13.5964 12.7013 14.0101 12.7216Z"
                                            fill="#dc3545" />
                                    </svg>
                                </button>
                            </form>
                        </td>
                    </tr>
                    #endforeach
                </tbody>
            </table>
            [[! paginator($todos)->linkWithJumps() !]]
        </div>
    </div>
</div>
#endsection

create.odo.php

#extends('layouts.app')
#section('title')
Create Todo
#endsection
#section('content')
<h2 class="az-content-title fw-bold">Create Todo</h2>
<div class="card mt-3">
    <div class="card-body">
        <form action="[[ route('todo.store') ]]" method="post">
            #csrf
            <div class="form-group">
                <label>Todo:</label>
                <input type="text" name="todo" class="form-control" required>
            </div>
            <div class="form-group mt-3">
                <label></label>
                <input type="checkbox" name="status" value="1"> Status
            </div>
            <div class="form-group">
                <button class="btn btn-success btn-submit mt-3" type="submit">Submit</button>
            </div>
        </form>
    </div>
</div>
#endsection

edit.odo.php

#extends('layouts.app')
#section('title')
Update Todo
#endsection
#section('content')
<h2 class="az-content-title fw-bold">Update Todo</h2>
<div class="card mt-3">
    <div class="card-body">
        <form action="[[ route('todo.update', $todo->id) ]]" method="post">
            #csrf
            #method('patch')
            <div class="form-group">
                <label>Todo:</label>
                <input type="text" name="todo" class="form-control" value="[[ $todo->todo ]]">
            </div>
            <div class="form-group mt-3">
                <label></label>
                <input type="checkbox" name="status" value="1" [[ $todo->status === 1 ? 'checked' : '' ]]> Status
            </div>
            <div class="form-group">
                <button class="btn btn-success btn-submit mt-3" type="submit">Submit</button>
            </div>
        </form>
    </div>
</div>
#endsection

By following this pattern, you can scale this simple Todo app into a full-blown Project Management system. You have the primitives for searching, filtering, relating users to data, and managing CRUD operations securely.

Doppar – High Performance PHP Framework

Francisco Navarro — Thu, 18 Sep 2025 12:55:25 +0000

Why Doppar?

As developers, we constantly seek harmony in our craft — the balance between elegance and performance. Often, we find one at the cost of the other: elegant syntax that slows us down, or high performance wrapped in complexity.

Doppar brings both worlds together. It offers aristocratic elegance in syntax and uncompromising performance under the hood — a framework designed for developers who value both beauty and speed.

Doppar is engineered for speed — every repeated execution is intelligently memoized, ensuring results are delivered instantly without unnecessary reprocessing. With minimal reliance on third-party libraries and most features built directly into the core, you get lightning-fast performance right out of the box. No unnecessary bloat—just clean, efficient execution

Doppar Entity ORM and Entity Builder Built entirely from core with zero external dependencies, Doppar delivers a powerful and expressive Entity ORM and Entity Builder system. Manage complex relationships with ease—no third-party packages required.

Whether you're a seasoned PHP developer or just diving in, Doppar makes it easy to build powerful applications quickly and cleanly.

Ultra-Clean Syntax - Unmatched Clarity

Doppar is built around one core principle — clarity without compromise. Every class, method, and directive is designed to be instantly understandable and beautifully expressive. Doppar turns complex backend logic into readable, fluent, and elegant code that feels natural to write and effortless to maintain.

Unlike traditional PHP frameworks that trade simplicity for abstraction, Doppar delivers both — a syntax that’s catchy. In Doppar, everything is explicit, discoverable, and self-documenting. No hidden bindings. No magic facades. No framework guesswork.

#[Route(uri: 'user/store', methods: ['POST'], middleware: ['auth'])]
public function store(
    #[Bind(YourConcrete::class)] YourAbstraction $lala
) {
    //
}

With attribute-based routing and inline dependency binding, Doppar makes intent crystal clear. Every dependency, every route, and every behavior is defined right where it belongs — in your code.

Unmatched Dependency Injection

Doppar’s Service Container redefines how PHP frameworks handle dependency management.
It offers an unparalleled level of clarity, control, and flexibility, allowing you to inject, bind, and resolve services without hidden magic or external dependencies.

With Doppar, dependency injection is first-class, built directly into the core — not added as an afterthought. Whether through service providers, attribute-based bindings, or automatic resolution, the container adapts seamlessly to your application’s structure.

Doppar keeps your bindings visible and meaningful. No verbose configurations. No hidden service maps. Just pure, expressive code that tells you exactly what’s happening.

#[Route(uri: 'user/store', methods: ['POST'])]
public function store(
  #[Bind(UserRepository::class)] UserRepositoryInterface $userRepository
) {
    // #[Bind] resolves UserRepositoryInterface to UserRepository
    // Explicitly and transparently.
}

Localize your dependencies exactly where they are used. Doppar intelligently resolves classes without manual setup. It turns dependency management into an elegant, explicit part of your codebase. Doppar’s container is more than a dependency injector — it’s a clarity engine.

Unmatched Request Object

Doppar introduces a next-generation Request Object that goes far beyond simple input retrieval.
With fluent pipelines, inline validation, and declarative transformations, the Doppar Request turns raw input handling into a clean, expressive, and composable workflow.

Instead of juggling multiple validation layers or helper functions, Doppar lets you filter, transform, and ensure your data — all within a single, elegant chain.

$data = $request
    ->pipeInputs([
        'title' => fn($v) => ucfirst(trim($v)),
        'tags' => fn($v) => is_string($v) ? explode(',', $v) : $v
    ])
    ->contextual(fn($data) => [
        'slug' => Str::slug($data['title'])
    ])
    ->ensure('slug', fn($slug) => strlen($slug) > 0)
    ->only('title','slug');

Post::create($data);

This design makes Doppar’s Request object not just a data carrier — but a powerful input processing engine.
It gives you the clarity of functional pipelines with the simplicity of modern PHP

Dual-Mode Engine For Task Scheduling

Doppar provides a powerful dual-mode scheduling engine that lets you run tasks the way your application needs — either through traditional cron or a real-time daemon loop. This flexibility makes Doppar suitable for everything from standard automation to high-frequency, second-based operations.

Standard Mode

In standard mode, Doppar works just like a typical scheduler: your system cron triggers the scheduler every minute, and Doppar runs all due tasks.

Perfect for everyday jobs
Low resource usage
Simple server setup
Ideal for minute-level or hourly tasks

Run it with:

php pool cron:run

Daemon Mode (Real-Time Execution)

Daemon mode activates Doppar’s continuous scheduling engine. Instead of waiting for cron, Doppar runs in a loop, checking tasks many times per second.

Supports second-based scheduling
Real-time execution
Great for monitoring loops, automation pipelines, IoT, bots, and fast tasks
No supervisor or systemd required — Doppar manages itself

Start the daemon:

php pool cron:run --daemon

While the daemon runs, Doppar automatically:

Handles task timing
Manages background jobs
Prevents overlapping
Tracks PIDs
Logs every action
Recovers safely after errors
Responds to SIGTERM/SIGINT for graceful shutdowns

One Scheduler, Two Execution Styles

Whether you need basic automation or high-frequency task execution, Doppar gives you both — fully integrated into one cohesive scheduling system.

Cron mode → simple, dependable, minimal
Daemon mode → fast, reactive, always running

Choose the mode that fits your application, or combine both for maximum power.

A Native Cron Daemon

Doppar includes a high-performance Cron Daemon, built directly into the framework.No server configuration. No crontab. No Supervisor. No systemd.

Just run:

php pool cron:daemon start

And boom, Doppar launches its own background process capable of executing tasks every second. You don’t need to edit /etc/crontab. You don’t need to use Supervisor. You don’t need systemd services. Doppar manages everything internally:

php pool cron:daemon start
php pool cron:daemon stop
php pool cron:daemon restart
php pool cron:daemon status

This means:

No server configuration.
No crontab.
No Supervisor.
No systemd.
Zero server setup
Zero DevOps complexity
Identical behavior in local, staging, and production
Massive portability

Your entire scheduling system is now fully framework-native.

Doppar Queue Component

The Doppar queue system is designed to handle background tasks efficiently with reliability and scalability in mind. Its feature set ensures smooth job processing, better performance, and full control over how tasks are executed. See the features of doppar queue.

Multiple Queue Support - Organize jobs by priority and type
Automatic Retry Logic - Configurable retry attempts with delays
Failed Job Tracking - Store and analyze failed jobs
Delayed Execution - Schedule jobs for future execution
Graceful Shutdown - Handle SIGTERM and SIGINT signals
Memory Management - Automatic worker restart on memory limits
Job Serialization - Safely serialize complex job data
Fluent API - Fluent syntax for job dispatching
Custom Failure Callbacks - Handle job failures gracefully

Very easy to customize doppar job behaves in the queue by configuring the #[Queueable] attribute directly on the job class like this way.

#[Queueable(tries: 3, retryAfter: 10, delayFor: 300, onQueue: 'email')]
class SendWelcomeEmailJob extends Job
{
    //
}

Your job class is now ready to work as a queueable job with your customized configuration. How cool is this right?

Doppar AI Component

Doppar AI lets you run powerful AI models locally in PHP, combining TransformersPHP for on-device inference and Symfony AI Agent for a clean developer workflow. Choose any supported Hugging Face model, and call it directly from your controllers using the Pipeline API.

use Doppar\AI\Pipeline;
use Doppar\AI\Enum\TaskEnum;

$result = Pipeline::execute(
    task: TaskEnum::SENTIMENT_ANALYSIS,
    data: 'I absolutely love this product! Best purchase ever!'
);

// Output: [['label' => 'POSITIVE', 'score' => 0.9998]]

On first run the model is downloaded automatically and then cached in storage/app/transformers, giving you fast, fully self-hosted AI responses.

Agent for conversational AI

use Doppar\AI\Agent;
use Doppar\AI\AgentFactory\Agent\OpenAI;

$response = Agent::using(OpenAI::class)
    ->withKey(env('OPENAI_API_KEY'))
    ->model('gpt-3.5-turbo')
    ->prompt('Explain quantum computing in simple terms')
    ->send();

echo $response; // Returns the AI-generated explanation

Doppar Benchmark - High-Concurrency Performance Test

We stress-tested Doppar under extreme concurrency to evaluate its throughput, latency, and stability on a real database-backed endpoint. The results speak for themselves. We compared request handling and latency of Doppar under high concurrency with a database-backed endpoint.

Test Setup

Load: 50,000 requests
Concurrency: 1,000 simultaneous requests
Endpoint: /tags (database-backed endpoint to fetch tags)
Tool: ApacheBench (ab)
Metrics Measured: Requests/sec, latency distribution, max latency, response size, error rate

Benchmark Results

Metric	Doppar	Notes
Total Requests	50,000	Total requests completed during the test run
Failed Requests	0	100% success rate, no dropped or errored responses
Requests/sec (RPS)	318.5 req/s	Sustained throughput under 1,000 concurrent users
Avg Latency	~3.1s (3100 ms)	Mean response time across all requests
Median Latency (P50)	~2.7s (2703 ms)	Half of all requests completed at or below this latency
P75 Latency	~3.6s	75% of requests completed within this time
P95 Latency	~4.8s	95% of requests completed within this time
P99 Latency	~6.2s	Only 1% of requests exceeded this latency
Max Latency	~7.9s	Slowest observed request
Response Size	1083 bytes	Size of a single JSON payload returned from `/tags`
Concurrency Level	1,000 connections	Simultaneous open requests during the test
Total Data Transferred	~54 MB (50,000 × 1083 B)	Useful for bandwidth & scaling considerations

Key Takeaways

High Throughput
- Sustained 318+ requests per second with 1,000 concurrent users — a level that pushes most frameworks to their limits.
Stable Latency Under Load
- Median response time remained below 3 seconds, even when hitting the database under extreme concurrency.
Zero Failures
- Across 50,000 requests, Doppar maintained a 100% success rate with no dropped or failed connections.

Why Doppar Stands Out

Handling thousands of concurrent connections while keeping performance predictable is notoriously difficult. Most PHP frameworks show significant degradation in these conditions — but Doppar was engineered for concurrency from the ground up.

What Sets Doppar Apart

7–8× higher throughput than typical PHP frameworks in comparable benchmarks
Predictable latency that keeps user experience smooth, even under peak traffic
Optimized database access, making it ideal for data-intensive applications

👉 If you’re building systems that demand real scalability, high concurrency, and reliable performance, Doppar is ready to power them.

Entity Builder and Entity ORM

Doppar introduces two powerful, fully native systems — Entity ORM and Entity Builder — built entirely from the core with zero external dependencies. Together, they redefine how developers interact with databases by combining expressive syntax, high performance, and total control.

Entity ORM

Entity ORM is a modern, intuitive, and high-performance Object-Relational Mapper designed to make database interactions seamless and efficient. Each database table is represented by a dedicated Data Model, giving you a clean, object-oriented interface for querying, inserting, updating, and deleting records — all without writing raw SQL.

Beyond simple CRUD operations, Entity ORM empowers you to manage complex data relationships with ease. Features like eager loading, nested relationships, and relationship-based filtering make it effortless to work with related data while eliminating repetitive boilerplate code.

Whether you’re handling straightforward tables or building intricate relational architectures, Entity ORM keeps your workflow smooth, expressive, and maintainable — turning database interactions into a natural, enjoyable part of your development process.

Crafted entirely within Doppar’s core, Entity ORM delivers pure, dependency-free performance for clean, reliable, and scalable data handling.

Entity Builder

Entity Builder is a powerful, flexible, and model-free query builder built for developers who want full control over database operations — without relying on predefined models.

With Entity Builder, you can construct, execute, and manage even the most complex SQL queries through a clean, expressive, and chainable interface. From fetching and filtering to joins, inserts, and updates, Entity Builder translates raw SQL power into elegant, object-oriented syntax that feels intuitive and effortless.

While Entity ORM excels in model-driven development, Entity Builder shines in dynamic scenarios — such as data analysis, raw manipulation, or rapid prototyping — letting you query any table directly. It supports nearly all ORM-level query capabilities (minus relationship-based operations) while maintaining the same clarity, consistency, and speed.

Fully integrated into Doppar’s ecosystem, Entity Builder runs without any third-party dependencies, ensuring unmatched reliability and performance across all data-driven applications.

With Doppar Entity Builder, you get the freedom of SQL with the clarity, safety, and precision of Doppar.

ODO

Doppar includes ODO, a modern, lightweight, and fully customizable templating engine designed exclusively for the Doppar Framework.

ODO is designed to be fully flexible. Every part of its syntax—directives, echo tags, raw output, escaped output, and comment markers—can be customized to match your preferred style or project requirements.

The syntax configuration lives in the config/odo.php file. This file allows you to define how ODO interprets template expressions and which symbols or delimiters it should use during compilation

Core Concepts

Doppar brings together modern PHP practices and elegant simplicity — empowering developers to build with grace and precision.

Feature	Description
Service Container	On-demand service loading with optional smart provider resolution.
Service Provider	Cleanly separate concerns and manage dependencies with ease.
Routing	Supports both attribute-based and file-based routes.
Model Hook	Flexible approaches to handle Entity model events.
Request	An unparalleled Request object built for clarity and power.
Middleware	Global, web or route-specific; easily configurable in multiple ways.
Controllers	Structured request-response handling with intuitive flow.
API Presenter	A clean, structured boilerplate for API responses.
Views	Odo templates with custom control capabilities.
Entity ORM	A core-built, dependency-free Entity ORM for pure performance.
Security	CSRF protection, sessions, cookies, and validation out of the box.
Auth	Authentication, encryption, and annotation-based rate limiting.
Utilities	Built-in mail, file uploads, and caching tools.
Atomic Lock	Owner-based locking, Blocking and non-blocking modes with TTL.
CLI	A developer console for streamlined task execution.
Localization	Effortless support for multi-language applications.

API Ready

With API authentication, rate limiting, and JSON-first controllers, Doppar is ready for your next backend. Doppar is built from the ground up with API development in mind. Whether you're creating RESTful services, backend systems for mobile apps, or headless applications for modern frontend frameworks like Vue, React, or Angular—Doppar provides all the tools you need to build secure, scalable, and high-performance APIs.

JSON-First Philosophy

At the core of Doppar’s API readiness is its JSON-first controller structure. Responses are standardized, consistent, and optimized for API consumption. Doppar controllers can be easily configured to return JSON by default, with helpers to format responses, handle pagination, errors, and status codes—so you can focus on your logic, not the boilerplate.

API Authentication

Doppar includes a flexible and secure API authentication system using Doppar flarion, supporting token-based authentication out of the box.

Rate Limiting

To prevent abuse and improve performance, Doppar provides built-in rate limiting. You can apply rate limits globally, per user, per route, or based on IP. With simple configuration, you can:

Protect against brute force attacks
Control load on your infrastructure
Improve the fairness of resource distribution

Rate limiting is managed via middleware, and it's fully customizable. You can load it using attribute based routing system or annotation based or even more file based routing system.

Security by Default

Security is a first-class concern in Doppar. The framework is engineered to provide enterprise-grade protection out of the box, offering developers a secure foundation for applications ranging from microservices to full-scale enterprise systems.

Core Security Features Overview

Feature	Description	Protection Against
Model Properties Encryption	Automatic, transparent encryption of sensitive database fields at rest.	Data breaches, unauthorized database access.
Stateless Authentication	Lightweight, performant token-based authentication (Flarion).	Session hijacking, replay attacks, traditional session vulnerabilities.
CSRF Protection	Automatically managed tokens for web routes.	Cross-Site Request Forgery (CSRF).
Input Validation	Powerful, flexible, and strictly enforced request rules.	Injection attacks (SQLi, XSS), mass assignment, data corruption.
Request Throttling	Middleware-driven rate limiting for critical routes.	Denial of Service (DoS), brute force, API abuse.
Sensitive Input Exclusion	Prevents sensitive fields (e.g., passwords) from being stored in the session.	Session exposure of sensitive user data.
Remember-Me Handling	Secure and strict token generation and validation.	Persistent session hijacking.

From robust security features and flexible authentication to clean controller logic and performance-minded architecture, Doppar gives developers everything they need to build modern, production-grade APIs with confidence.

Data-at-Rest Protection

Doppar provides a sophisticated and transparent way to encrypt cross-origin supported sensitive model attributes directly in the database.

Implementation with `Encryptable` Contract

To enable encryption for a model, it must implement the Phaseolies\Support\Contracts\Encryptable interface and define the fields to be encrypted in the getEncryptedProperties() method.

namespace App\Models;

use Phaseolies\Database\Entity\Model;
use Phaseolies\Support\Contracts\Encryptable;

class User extends Model implements Encryptable
{
    /**
     * Return an array of model attributes that should be encrypted
     */
    public function getEncryptedProperties(): array
    {
        return [
            'email', // This field will be encrypted
        ];
    }
}

When a model is serialized (e.g., converted to JSON for an API response or logging), the encrypted value is preserved unless you explicitly decrypt it, ensuring sensitive data is not accidentally exposed.

{
    "id": 1,
    "name": "Aliba",
    "email": "T0RvMnZqWUIzVWhURkNKdWZSN0ZPaDZvN3g2M0o0L21nUTZ1",
    // ...
}

API Security

Doppar's Flarion package provides a lightweight, stateless personal access token (PAT) system, ideal for APIs, mobile apps, and third-party integrations.

Secure Token Lifecycle

Tokens are hashed using HMAC-SHA256 with the application key to prevent brute-force or rainbow table attacks. Only the hashed lookup and metadata (user ID, abilities, expiration) are stored in the database. Raw tokens are never persisted

Stage	Security Mechanism	Description
Generation	CSPRNG (bin2hex(random_bytes(40)))	Generates a cryptographically strong, unique, and unpredictable raw token.
Storage	HMAC-SHA256 Hashing	The raw token is never stored. Instead, a secure lookup hash is created using the application key and stored in the database.
Validation	HMAC Verification	Incoming tokens are hashed and checked against the stored lookup hash for a fast and secure verification process.
Access Control	Scoped Abilities	Each token is issued with a specific array of permissions (abilities), strictly limiting its power.
Expiration	Configurable Lifespan	Tokens can be configured to automatically expire, minimizing the window for a potential exploit.

This architecture ensures that even if the database is breached, the raw access tokens are never compromised, making the system fast, simple, and enterprise-grade secure.

Sensitive Input Exclusions

Doppar prevents sensitive information from persisting beyond the immediate request by defining a list of fields that are never stored in the session or debug context:

// config/app.php excerpt
"exclude_sensitive_input" => [
    'password',
    '_insight_redirect_chain' // Example: for internal framework tooling
],

Request Throttling

Doppar uses flexible middleware to protect routes from abuse and DoS attacks. The throttle middleware allows for fine-grained control over request limits.

Example Route Throttling:

#[Route(uri: 'login', rateLimit: 10, rateLimitDecay: 1)]
public function login()
{
    //
}

If the limit is exceeded, the client receives an HTTP 429 Too Many Requests response, protecting the server resources. This prevent abuse and ensure fair usage with Doppar’s advanced rate-limiting features.

Configure request thresholds per endpoint, IP, or user to protect your backend from DDoS attacks, brute-force attempts, and excessive API calls. Dynamic rate-limiting rules adapt to traffic patterns, ensuring optimal performance while maintaining service availability for legitimate users.

Input Validation

Doppar provides a powerful and flexible input validation system to ensure incoming request data is always safe and properly formatted. Automatically validates and cleans request data using the sanitize() method. Further modifies or transforms validated inputs via pipeInputs() like method. Built-in protection for web routes to prevent Cross-Site Request Forgery.

Also model $creatable property to explicitly whitelist attributes that can be set in bulk operations, preventing unauthorized updates.

Example:

$request->sanitize([
    'name' => 'required|min:2|max:20',
    'email' => 'required|email|unique:users|min:2|max:100',
    'password' => 'required|min:2|max:20',
    'confirm_password' => 'required|same_as:password',
]);

$payload = $request
    ->pipeInputs([
        'email' => fn($input) => strtolower(trim($input)),
        'password' => fn($input) => bcrypt($input)
    ])
    ->only('name', 'email', 'password');

User::create($payload);

Designed to Scale

Whether you're handling thousands of requests per minute or operating within a microservices architecture, Doppar is ready. Its modular approach to routing, service containers, and middleware allows you to keep your API logic clean, maintainable, and testable.

Contribute or Build Packages

One of Doppar’s greatest strengths is its modular and extensible architecture, which allows developers to extend the framework by building custom packages or integrating community-contributed modules. Whether you're adding new functionality, creating reusable components, or enhancing core features, Doppar’s package development tools are designed to make the process seamless and maintainable.

Doppar enables you to encapsulate features into packages that can be easily reused across multiple projects. This is especially useful for:

By following Doppar’s conventions, your packages can hook into the application's service container, routing, middleware, and more—just like core framework components. This means you can package your features professionally—with the same structure and power as native Doppar components.

Doppar makes package development not just possible, but enjoyable and powerful. Whether you're solving a problem for your own project or building tools for the wider community, Doppar’s extensibility helps you do it cleanly, efficiently, and in a scalable way.

Build Something Great

Doppar is designed to get out of your way—so you can build faster and cleaner. From commands (pool) to rich Entity ORM tools, Doppar ensures your workflow is smooth and enjoyable.