Object Pool Laravel Package

Product Decisions This Supports

• Pooling and resource strategy for long-lived PHP workers. Object pooling is the capability that makes Swoole/Octane-style concurrency safe for stateful resources — PDO connections, Redis clients, HTTP/Guzzle clients, RPC stubs. The decision it informs: "do we share warm clients across coroutines, or open and tear down per request?"
• Build vs. buy for pooled resources. A generic pool needs acquire/release, max size, idle eviction, wait timeouts, destroy hooks, and health checks. This package gives you a small core of that; teams must decide whether the remaining 30% (reconnect, leak detection, metrics) is cheaper to build in-house or source from a mature ecosystem.
• Roadmap gating for a Swoole/Octane migration. Pooling is a prerequisite capability, not a feature. Whether we have a trustworthy pool determines whether a service can move to coroutine mode this quarter or next.
• Capacity and cost modeling. Fewer connection churns mean less pressure on PgBouncer/DB proxies, Redis maxclients, and cloud NAT/egress. This is a cost lever to be sized, not a DX win to be marketed.
• Ecosystem positioning. Adopting it binds us to mix-php's coroutine conventions. That is an architecture decision that belongs on the roadmap, not in a sprint ticket.
• Representative use cases: high-QPS API services, queue workers doing DB + Redis per job, RPC gateways, TLS-heavy outbound clients, anything with expensive constructor or handshake cost.

When to Consider This Package

Consider it when:

• You are already running, or deliberately committing to, mix-php. This is the honest fit — this is a Swoole-oriented library, not a Laravel package: no service provider, no facade, no Octane integration, no config publish. If the question is "Laravel," the answer is "only under Octane, and you wire the pool yourself."
• Profiling shows constructor/handshake churn in long-lived workers: DB auth, Redis AUTH/SELECT, TLS negotiation, client bootstrap.
• You want a minimal, composable pool abstraction and are willing to own health checks, failure semantics, and instrumentation.
• You are prototyping and want a reference implementation of pooling semantics before standardizing on Hyperf's pool, Swoole\ConnectionPool, or a bespoke solution.

Look elsewhere when:

• You are on classic PHP-FPM Laravel. The process dies at request end — there is nothing to pool across requests. This package adds zero value.
• You need vendor support, SLAs, or a maintained critical-path dependency. Five stars, zero dependents, no downstream adoption signal: high bus-factor and abandonment risk.
• You are on Hyperf. It already ships hyperf/pool with connection health, reconnection, and framework integration. Reimplementing on top of this is strictly worse.
• You need observability out of the box — pool saturation, wait-time histograms, leak detection. Expect to build it; that is real PM-visible scope, not "free."
• Scale is low. Below meaningful QPS, pooling trades a measurable performance win for lifecycle bugs: leaked objects, stale connections, coroutine deadlocks under saturation.

How to Pitch It (Stakeholders)

Executives: Don't buy the package as strategy — buy the capability. Connection pooling is a genuine cost and reliability lever when we move PHP services to long-lived workers: fewer connection storms, less DB and Redis pressure, more headroom per instance. But this specific library is a 5-star, zero-dependent component with no maintainer depth, so treat it as a reference design, not a dependency. Recommendation: fund pooling plus observability inside the Swoole/Octane workstream, and only select a library once the runtime is chosen — hyperf/pool if we go Hyperf, first-party wiring if we stay on Octane.

Engineering: Small, focused Swoole object pool — acquire/release, max size, idle handling. Low ceremony and no framework coupling, which makes it compose cleanly if you're in mix-php. That is also the problem: zero ecosystem gravity means we own the failure modes — stale connections, leaks on exception paths, wait timeouts under saturation, no reconnection. If we adopt it, wrap it behind an internal Pool interface (acquire / release / withConnection) so we can swap to Hyperf's pool or a bespoke implementation without touching call sites, and ship pool saturation and wait-time metrics on day one.

Bottom line: Good pattern, thin package, wrong ecosystem for a Laravel-first team. Rate the idea highly and the dependency low. Revisit only if we commit to mix-php.