Solarium Async Plugin Laravel Package

Product Decisions This Supports

• Search latency budget / Core Web Vitals trade-off. If a search results page issues multiple Solr round trips (select + facets + highlighting + spellcheck/suggest + more-like-this, or several cores/shards), serial execution makes page latency the sum of those calls. Async fan-out turns it into roughly the max. This directly informs whether "add one more query for relevance/recs" is affordable — a roadmap-enabling decision, not a feature in itself.
• Feature vs. infrastructure trade-off. A PM can use demonstrated async capability to justify not building a search-API aggregation layer or a separate microservice just to parallelize Solr calls. That is a concrete build-vs-buy (build-vs-adopt) input.
• Capacity / cost decisions. Blocking PHP-FPM workers on sequential Solr I/O inflates worker count and p95 under load. Async fetches reduce wall-clock hold time per request, which feeds hosting sizing and autoscaling assumptions.
• Experimentation velocity. Relevance experiments (extra query variants, A/B select handlers) each add Solr calls. Async makes those experiments cheaper to run, so the search roadmap can carry more per-request experimentation without a latency regression.
• Risk-acceptance decision. With ~1 star and 0 dependents, this is a source of a pattern, not a supported dependency. The product decision is "vendor/fork the small plugin and own it" versus "schedule a Solarium upgrade instead."

When to Consider This Package

Consider it when all of these hold:

• You are on a legacy Solarium version in the HTTPlug era (Solarium 3.x/4.x-class, using php-http/* adapters). Verify the pinned Solarium version against the plugin's event hooks before anything else — this is the single biggest adoption gate.
• You have measurably ≥3 Solr round trips per request, and profiling shows Solr I/O (not PHP, not templating) dominates p95.
• An upgrade to a newer Solarium with native async/PSR-18 support is expensive or blocked by other constraints, so a small bridge buys time.
• Your team can vendor the source into your repo and accept ownership of maintenance, security review, and version pinning. MIT licensing makes this straightforward.
• You can validate with a before/after latency benchmark rather than vendor claims (there is no community evidence base here).

Look elsewhere when:

• You are on Solarium 6+ / PSR-18: use native async/concurrent request support or a curl-multi adapter; HTTPlug promises are the wrong abstraction and this plugin likely won't fit.
• You issue one Solr query per request — there is nothing to parallelize.
• You need a maintained dependency with release cadence, security patching, or vendor support. One star and zero dependents is a hard no for "just composer require it."
• You actually need query-level caching or a search aggregation layer — this plugin solves concurrency, not caching, relevance, or resilience.

How to Pitch It (Stakeholders)

For executives: Search pages that fan out several Solr calls currently pay for them one after another. There is a small, MIT-licensed plugin that lets those calls run concurrently, which can cut search response time and reduce the number of PHP workers tied up waiting on Solr. The catch: it is essentially unmaintained (one star, no downstream users), so we would copy the code into our own codebase and own it, at a cost of roughly a day of engineering plus ongoing pinning. Recommendation: treat it as a validated pattern to prototype, not a dependency to adopt. Timebox a spike, measure p95 before/after, and fund it only if the latency win is material and the migration to a modern Solarium async path is not cheaper.

For engineering: This is a Solarium plugin that hooks the request-execution event and returns HTTPlug promises instead of blocking results, with an wait()-style resolution step. The code surface is tiny, so the sane move is to vendor it, pin it to our exact Solarium/HTTPlug adapter version, and add a test that asserts all promises resolve and errors propagate (promise rejection handling is the likely failure mode we'd inherit). Migration path: when we move to PSR-18-era Solarium, delete the vendored plugin and use the client's native concurrency. Gate the spike on: (1) version compatibility check, (2) a reproducible benchmark of a representative multi-query search page, (3) confirmation that error/timeout semantics match today's serial behavior.