Sonata Elastica Bundle Laravel Package

Technical Evaluation

Architecture fit. This is the first thing a TPM must nail down, because it changes the entire plan: marmelab/sonata-elastica-bundle is a Symfony bundle, not a Laravel package. It exists to swap SonataAdminBundle's Doctrine-backed datagrid for an Elasticsearch query through Elastica/FOSElasticaBundle. It hooks Sonata's AdminInterface, DatagridMapper, and ModelManager — none of which have a Laravel analogue. In a Laravel codebase there is no container binding, no facade, and no seam to sit behind Eloquent. The honest architecture statement for the plan is: this is a Symfony/Sonata admin plugin we would have to host as a separate application, or a pattern we reimplement.

Integration feasibility. Only two viable shapes. (a) Reimplement the pattern in Laravel — a custom repository/Builder that translates admin filters and sort into an ES query and returns an Illuminate\Pagination\LengthAwarePaginator, with writes synced via model events or an outbox. (b) Sidecar Symfony admin — a separate deployable running Sonata Admin + FOSElastica against the same cluster, with Laravel as system of record. Direct embedding inside Laravel is not supportable. Both are multi-week efforts; neither ships this package as a dependency.

Technical risk. High, and mostly organizational rather than technical. The repo is archived — no security patches, no PHP 8.x deprecation fixes, no Elasticsearch 8+/OpenSearch compatibility work. 43 stars and 0 dependents means negligible production usage and no community to lean on. Pins will be old Symfony (2.x/3.x), old Sonata Admin (current lines are 4.x/5.x with changed datagrid interfaces), and old Elastica (7.x). Expect composer conflicts before any feature work, and treat the archive as a hard ceiling, not a floor.

Key questions.

• Is our back-office actually Symfony + Sonata today, or Laravel? If Laravel, the deliverable is a pattern, not a dependency.
• What is the measured pain? Profiler p95 on the slow admin list, query count, and DB vs. ES contention — not anecdote.
• Which Elasticsearch major is in production, and does the pinned Elastica client support it?
• Do we accept an unmaintained dependency (or a fork) in an operator-facing path, and who is the named owner?
• Is a second deployable (auth/SSO, CI, on-call, domain model) acceptable, or is in-stack reimplementation cheaper?
• Is a Laravel-native option — Scout + an ES/Meilisearch driver, or a custom ES repository — sufficient for the same outcome?

Integration Approach

Stack fit. Near zero as a dependency. The bundle assumes Symfony full-stack, Sonata Admin, FOSElastica or a raw Elastica\Client, Doctrine entities with annotations, and Twig admin templates. A Laravel shop supplies none of these. Frame the integration effort as "copy the ~few-hundred-line adapter logic, not the package."

Migration path. Three options, ranked for a TPM plan:

1. Laravel-native reimplementation (default). One admin screen at a time: ES read path behind an Eloquent-shaped repository, pagination in Laravel, write path kept in sync by observers/queue. Stays in-stack, no new deployable, no new on-call surface.
2. Symfony sidecar admin. Only if we already run Sonata somewhere or need its UI. Requires shared ES index, document schema agreement, SSO, and a mutation API back to Laravel. Scope this as a new service, not an integration.
3. Fork the bundle. Justified only for an existing Sonata shop needing a stopgap, with an explicit, funded fork owner and an ES-client upgrade backlog item.

Compatibility. Verify before estimating: supported PHP range, Symfony constraint, sonata-project/admin-bundle version, FOSElastica vs. standalone ruflin/elastica, and target ES server version. Because the repo is archived, any mismatch is a permanent blocker or a fork task — add it to the estimate as a real line item, not a spike risk.

Sequencing. (a) Profile the current admin listing; if the DB isn't the bottleneck, stop and re-scope. (b) One-screen Laravel-native ES read-path spike, timeboxed to 1–2 weeks, with a defined success metric (p95 latency, query count, operator-reported throughput). (c) If a sidecar is still on the table, prove SSO + shared index + schema in a second timeboxed spike. (d) Only then decide whether any MIT-licensed code is worth copying.

Operational Impact

Maintenance. Effectively "we own it." Archived + MIT means fork-and-maintain is the only durable posture: no upstream bumps, no CVE response, and every future ES upgrade (7→8→9, mapping-type removal) is our project. TPM action: log this as a standing tax with a named owner and a recurring upgrade estimate, even for a pattern-copy.

Support. No vendor, no active maintainer, no issue triage, no community corpus at 43 stars / 0 dependents. Knowledge will sit one or two engineers deep. Budget for writing runbooks from scratch and for source-reading as the primary diagnostic method.

Scaling. The read path offloads list queries to ES by design, but the bundle is a UI adapter, not a pipeline. Indexing, reindexing, and freshness are delegated upstream or unowned. In a Laravel-as-source-of-truth design the hard scaling problem moves to sync: outbox depth, queue lag, dual-write consistency, reindex windows. Cluster sizing, shard strategy, and refresh intervals are ours regardless.

Failure modes. (1) Composer dead-end — a transitive pin blocks a PHP/Symfony upgrade and freezes the app. (2) Index drift — admin lists return stale/missing rows while mutations succeed in Laravel, eroding operator trust; this is the highest-probability day-2 issue and needs a reconciliation job in the plan. (3) ES outage — list views hard-fail or degrade silently; confirm fallback behavior up front and decide the product answer. (4) Mapping mismatch — filters silently return wrong result sets, worse than an error because it's invisible. (5) Bus factor — one engineer understands the adapter; mitigate with tests and a written design note.

Ramp-up. Estimate 1–2 weeks for an engineer fluent in the admin stack just to reach productivity on this bundle's source and pinned versions; add Elasticsearch operational depth (mappings, analyzers, reindex procedures) if the team hasn't run an ES-backed admin before. TPM framing for stakeholders: cap the downside with a timeboxed spike and a default outcome of pattern reuse over dependency adoption; approve the experiment, but require a named owner and an exit plan before anything ships to an operator-facing path.