Solr Bundle Laravel Package

Technical Evaluation

Architecture fit — poor to marginal. floriansemm/solr-bundle is a Symfony bundle, not a Laravel package. Its architecture assumes:

• Symfony DI container bootstrapping (Bundle, Extension, CompilerPass) with bundle config merged from config.yml
• Doctrine2 ORM event listeners/subscribers that hook postPersist/postUpdate/postRemove to keep the Solr index in sync
• A Solarium-based client layer (typically) wrapped in Symfony services

Laravel has no bundle concept — its service-provider lifecycle, config repository, and container semantics differ enough that the package cannot be installed and used as-is. On the persistence side, Laravel's default ORM is Eloquent, not Doctrine, so the single most valuable feature (automatic index synchronization) has no out-of-the-box attachment point. The translatable value is narrow: the query-building abstraction, field mapping, and index/schema handling.

Integration feasibility — feasible only as a fork/extraction, not an adoption. A realistic path is to vendor the source and harvest the Solr client + query builder, discarding all Symfony and Doctrine glue. That is a day-to-two-day spike for a senior PHP engineer, contingent on the code compiling under a modern PHP runtime (see risk below). If the goal is simply "search in Laravel," better-supported options exist and should be evaluated first:

Technical risk — high. Concretely:

• Abandonment. Last release 2018-11-15. Effectively ~7 years without a tag; assume zero upstream responsiveness.
• Framework drift. Almost certainly constrained to Symfony 2.x/3.x-era APIs and PHP 5.6/7.0–7.1 syntax. Under PHP 8.x you should expect deprecation noise at minimum and hard failures (removed functions, reserved words, dynamic property deprecations) at worst.
• Dependency drift. Bundled Solarium versions predate Solr's JSON Request API becoming the norm; the package likely emits legacy query-string/XML-era requests. Solr 8/9 compatibility is unverified.
• Zero dependents. No downstream packages means no community smoke-testing, no shared patches, no de facto maintenance. You are the only consumer.
• Security surface. Unmaintained code parsing external config and issuing network calls is a standing audit item.

Key questions for the spike:

1. What Solr server version was this validated against, and does it work against Solr 8/9?
2. Which Solarium version is pinned, and is the client layer cleanly separable from Symfony classes?
3. Does the code run under PHP 8.2+ (our runtime) without patching — and if patching is needed, how many files?
4. Are there maintained forks with recent commits we could track instead of forking ourselves?
5. Is the Doctrine listener logic (change detection, commit ordering) worth porting to Eloquent observers, or is it simpler to write fresh?
6. What is the actual feature delta versus Scout + a Solr driver — i.e., what are we paying for with the fork?

Verdict: technically viable only as a source to mine, not as a dependency. The high "opportunity" score reflects a genuine gap (no first-class Solr integration for Laravel), but this package does not fill it.

Integration Approach

Stack fit. This is a Symfony/Doctrine artifact landing in a Laravel/Eloquent stack — a two-layer mismatch (framework and ORM). Any integration plan must be explicit that we are reimplementing, not installing. Assume ~70% of the package's surface area is framework glue to be discarded and ~30% is transferable domain logic (query construction, field mapping, index operations).

Migration path. Recommended sequence for a fork-and-harvest approach:

1. Vendor the source into packages/solr-search via a Composer path repository; keep MIT headers intact for attribution.
2. Strip all Symfony\Component\* and Doctrine\* imports; isolate the Solr-facing classes behind a single namespace boundary.
3. Wrap in a Laravel ServiceProvider — config published to config/solr.php, client bound as a singleton, connection params from env.
4. Replace Doctrine listeners with Eloquent observe/model events or, preferably, explicit index jobs dispatched to a queue. Do not rely on synchronous model hooks in the request path.
5. Introduce a repository/search abstraction in front of the client so a future engine swap (or Scout adoption) is not a rewrite.
6. Parity tests against a containerized Solr instance (Testcontainers/Docker Compose) before any production traffic.

Compatibility. Validate early and cheaply:

• Run composer why-not php 8.2 style checks and a static analysis pass (PHPStan level 5) on the vendored code to size the patch surface.
• Confirm the pinned Solarium major version and whether it can be bumped independently of the bundle's glue.
• Confirm solr server image version in CI matches production (Solr major-version drift is a silent schema/handler mismatch risk).
• If Laravel Doctrine (laravel-doctrine/orm) is already in the stack, the listener layer becomes partially reusable — verify before discarding it.

Sequencing and gates. Timebox a 2-day spike with a hard go/no-go: (a) client layer separated, (b) one document indexed and one query returned against Solr 8+, (c) estimated patch count under a stated threshold. If the spike fails gate (b) or blows the patch budget, exit to Solarium-direct and stop spending. Do not run the fork and an alternative in parallel beyond the spike — the comparison is cheap, the dual maintenance is not.

Recommendation: treat solr-bundle as reference material for schema design and query patterns. Ship v1 on Solarium behind a Laravel service provider. Revisit the fork only if a specific capability (e.g., rich multi-field query DSL) demonstrably cannot be reproduced in a few days.

Operational Impact

Maintenance — we own it entirely. With a 2018 release cadence and zero dependents, there is no upstream to absorb PHP/Solr upgrades. Budget recurring engineering time for: PHP minor-version compatibility, Solarium security patches, Solr server upgrades, and schema evolution. A forked codebase of this vintage realistically needs a maintenance window each quarter, not each year.

Support. No vendor, no active maintainer, no responsive issue tracker. Internal documentation of why we forked and what we changed becomes the only institutional knowledge — this must be written at fork time, not reconstructed later. Named ownership (one engineer, one backup) is mandatory for a fork; without it the code becomes load-bearing orphan infrastructure with a long tail of silent risk.

Scaling. The PHP layer is thin, so throughput is dominated by indexing strategy, not the package:

• Synchronous Doctrine-style listeners on writes serialize index updates into the request path — replace with queued jobs and batching. This is the single largest scalability decision.
• Solr itself scales horizontally (replicas, sharding) independently of this package; the package contributes no scaling capability and no obstacle.
• Commit strategy matters: frequent soft commits for visibility vs. hard commits for durability. Define explicit SLA for "how stale can search results be" — e.g., 5–30s eventual consistency is usually acceptable and buys substantial throughput.

Failure modes. Enumerate these in the runbook:

Two failure modes deserve emphasis as product risks rather than engineering ones: silent index drift (users lose trust in search before anyone notices) and Solr-downtime coupling (a search dependency taking down the storefront). Both argue for asynchronous indexing and a circuit-broken read path from day one — retrofitting either is expensive.

Ramp-up. Two distinct skill gaps: (1) Solr operations — schema design, analyzers, commit tuning, core management — which no PHP package removes and which the team likely lacks; (2) Symfony internals, needed only if we fork, since debugging the harvested code requires reading DI-era idioms. Budget for a Solr primer plus a documented schema decision record. If the team has no Solr operational experience, factor managed Solr (or a hosted search service) into the cost comparison — that decision likely dominates the build-vs-fork calculus more than the package choice does.