Gearman Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for background processing. If we need asynchronous job execution (report generation, image/PDF processing, bulk email, third-party API sync, webhook fan-out), this package is the "buy" option for the Symfony integration layer. It answers: do we write our own worker bootstrap, job registration, and CLI tooling, or take a convention-driven bundle that wires Gearman into the framework? Scope of savings: days, not months — it removes boilerplate, not architecture.
• Queue technology selection (Gearman vs. the field). This package is only rational once Gearman is already the chosen broker. It lets us evaluate Gearman on its actual merits — language-agnostic workers, simple protocol, in-memory job server — rather than losing the comparison on "no framework integration."
• Stack-fit / framework lock-in. Critical caveat: this is a Symfony bundle, not a Laravel package. It ships Symfony service definitions, a bundle class, annotation/attribute-based worker discovery, and a console command surface. In a Laravel codebase it is not droppable — we would be porting it. This directly supports a "do not adopt / adopt Symfony Messenger or Laravel queues instead" decision if our stack is Laravel.
• Roadmap enabler for latency-sensitive features. Offloading work off the request cycle is a prerequisite for several roadmap items (large exports, media pipelines, AI/long-running calls). This package is a cheap way to prove the async pattern before committing to heavier infrastructure.
• Legacy modernization / sunset planning. If we inherit a Gearman-based system, this is the reference for how it was wired. It informs the keep vs. replace analysis: replacement cost is dominated by rewriting workers, not by this bundle.
• Infrastructure cost scoping. Adoption implies running gearman-job-server plus installing/maintaining the PECL gearman extension. That is real operational surface the PM must budget for in the same breath as the dependency — it is not a pure composer require.
• Maintenance signal, updated for v5.1.1. The release is housekeeping, not capability: it upgrades doctrine/annotations to 2.0 and refactors the bundle's annotation handling to fit it, contributed by a first-time contributor. Two PM-relevant reads: (a) the project is alive — someone is paying down dependency debt, which is a mild positive for the "willing to own it" trade; (b) the direction of travel is keeping the annotation ecosystem working, not migrating worker discovery to native PHP 8 attributes first. 237 stars, effectively no downstream dependents — this remains a risk-register entry, not a platform bet.
• Dependency-resolution impact (mildly breaking, not for us). Bumping doctrine/annotations to 2.x is a major-version graph change: it can collide with older Symfony versions or with apps still pinned to the 1.x annotation surface, and it forces composer update churn on any legacy system we point it at. Nothing in the release changes the public job/worker API, so it does not change our build-vs-buy math — it changes our upgrade-risk line item if we ever revive a Gearman-based legacy app.

When to Consider This Package

Adopt-consider criteria (all should hold):

• The application is Symfony, and we have confirmed the bundle's supported Symfony and PHP versions in composer.json — "Symfony2" in the description is historical, not current, and must be verified rather than assumed. After v5.1.1, also verify the doctrine/annotations ^2 constraint lands inside our dependency graph.
• Gearman is already chosen or mandated — existing workers in production, org familiarity, or a hard requirement.
• We specifically benefit from polyglot workers: Gearman clients exist for Python, Go, Java, Ruby, etc. If all our workers will be PHP, this advantage evaporates and a native PHP queue wins.
• We need a synchronous + asynchronous + background job model with workers defined declaratively near the code that implements them — that is exactly what the bundle's annotation/attribute-driven worker registration buys.
• Small team, near-term delivery pressure, and a willingness to own the dependency if upstream stalls.

Look elsewhere when:

• The stack is Laravel. Use the native queue system / Horizon, or Symfony Messenger concepts ported deliberately. Do not fork a Symfony bundle to get a queue.
• Greenfield with no Gearman installed. Symfony Messenger (with Doctrine/Redis/AMQP transports) is the framework-native path and carries the ecosystem's momentum. Gearman's in-memory job server gives weak durability — retries, dead-letter handling, delayed/scheduled jobs, and observability are all things we would end up building ourselves.
• We are starting from attributes-only, modern PHP. Worker discovery here is still annotation-centric (v5.1.1 keeps that pipeline current rather than replacing it). If our codebase is attributes-first, we would be adopting an aging configuration idiom for the sake of the broker.
• We need managed infrastructure (SQS, Google Pub/Sub, managed RabbitMQ), per-message visibility, or durable persistence. Gearman's persistence story is thin and the operational story is "you run the server."
• We need a vendor SLA or a large hiring pool. Zero dependents and a narrow contributor base means we are the support contract.
• The PHP extension is a blocker. The PECL gearman extension must be installed and rebuilt across PHP upgrades and container images; on some hosting platforms this is painful or impossible. If the team cannot own that, stop here.

How to Pitch It (Stakeholders)

One-liner for executives: A small, MIT-licensed Symfony add-on that lets us push slow work out of the user's request and onto background workers using Gearman — it saves integration effort, but it only makes sense if Gearman is already our queue, and it adds a server and a PHP extension to operate.

The recommendation in three parts:

1. Treat it as an accelerator, not a platform. It removes wiring work (worker registration, discovery, CLI runner, job submission services) worth roughly days of engineering. It does not provide durability, retries, scheduling, or monitoring — those remain our problem.
2. Gate adoption on the broker decision, not on the bundle. The expensive, hard-to-reverse choice is "Gearman or not." If we are not already on Gearman, the default should be Symfony Messenger (if Symfony) or native queues (if Laravel); this bundle should not be the reason we pick Gearman. The latest release (v5.1.1) is dependency housekeeping — a doctrine/annotations 2.0 bump plus refactor — not a feature investment, so it changes nothing about that recommendation.
3. Price the ownership. Add to the estimate: gearman-job-server in every environment, the PECL extension in every image and CI job, annotation/PHP-version pinning that now includes doctrine/annotations 2.x, and a named owner for the dependency given its thin downstream adoption. Cheap to try, non-trivial to depend on.

For engineering: Convention over configuration for worker definitions and a console-driven worker lifecycle — fast to prototype, familiar Symfony idioms, no framework fight. The 5.1.1 bump confirms active maintenance but also confirms annotations remain the discovery mechanism; verify supported Symfony/PHP versions and PECL extension availability before we commit a sprint, and prefer native attributes where the bundle allows them.