qdiz: The PHP Safety Valve for Framework-Agnostic Apps

For years, PHP developers have faced a binary choice for background processing. They could either adopt a heavy framework like Laravel to access robust queueing features, or they could write fragile, custom cron jobs that poll an arbitrary database table. The framework route introduces massive dependency trees. The custom route introduces systemic instability. qdiz emerges as a sophisticated rebellion for the minimalist developer.

Built strictly for Redis, qdiz is a queue system that prioritizes stability in non-framework environments. It achieves this through a surprising architectural decision for a micro-library: enforcing subprocess isolation by default.

The Blast Shield Architecture

The classic 'long-running worker' problem in PHP is well documented. Because PHP was historically designed to die after every HTTP request, long-running CLI processes are notoriously susceptible to memory leaks and stale database connections. If a single background job crashes or exhausts memory, it can take the entire worker down with it.

Most lightweight queue libraries ignore this risk to save overhead, running tasks synchronously within the main worker loop. qdiz takes the opposite approach. It treats every background job as a potential grenade. When the worker polls a new job from Redis, it spawns a fresh, isolated PHP subprocess to handle the execution. If the job leaks memory or fatally errors, the child process dies, but the parent worker remains completely unaffected. The state is wiped clean for the next task.

Laravel DX, Without the Laravel

Despite its anti-bloat philosophy, qdiz refuses to abandon developer experience. It brings the 'magic' ergonomics of Laravel's Artisan commands to vanilla PHP projects. The library includes a CLI utility to generate job classes from predefined stubs, enforcing a consistent architectural pattern without requiring developers to write boilerplate code.

Every job is a self-contained class that handles its own serialization and lifecycle hooks. Instead of a centralized manager dispatching generic payloads, the job object itself is instantiated, populated with data, and told to dispatch.

class SendWelcomeEmail extends Qdiz
{
    public function onProcess(): void
    {
        // Execution logic runs in an isolated subprocess
        $email = $this->email;
        Notifier::send($email);
    }

    public function onFail(\Throwable $e): void
    {
        // Hook triggered upon failure
        Log::error($e->getMessage());
    }
}

The Redis Handshake

At the storage layer, qdiz relies entirely on Redis. The worker command utilizes `blpop`, a blocking pop operation that waits for elements to be pushed to a list. This is vastly more efficient than a constant polling loop that hammers the database every second.

When a job is dispatched, it serializes its public properties and its fully qualified class name into a JSON payload. The worker receives this string, uses the class name to re-hydrate the object in the new subprocess, and triggers the `onProcess` method. If the job fails, the library automatically increments a retry counter in the payload and pushes it back onto the Redis list using `lpush`.

Choosing Your Constraints

qdiz is not a universal solution. It lacks the complex workflow orchestrations, batching, and chained jobs found in enterprise framework queues. It also utilizes a GPL-3.0 license, which requires derivative works to also be open-source, a factor that closed-source commercial projects must consider.

However, for developers building microservices, legacy API wrappers, or CLI tools in PHP, it provides exactly what is needed: a robust safety valve. It delivers the operational stability of a major framework without demanding the architectural surrender.