Gally Standard Laravel Package

Technical Evaluation

Architecture fit. gally/gally-standard is not a Laravel package — it is the standard data-model/configuration layer of Gally, a Symfony-based headless searchandising suite built around Doctrine, API Platform, and Elasticsearch/OpenSearch. It assumes Symfony's DI container, bundle configuration, and entity mappings. Laravel's service container, Eloquent models, and HTTP kernel do not map onto those assumptions, so in-process use inside a Laravel app is a poor fit. As a separate search backend consumed over HTTP, the fit is much better: Laravel remains the application/UI layer and Gally owns indexing, querying, and merchandising rules. v2.3.1 does not change this conclusion — no HTTP contract or client abstraction changes land in this release.

Integration feasibility. Composer installation is technically possible but pulls a substantial Symfony/Doctrine/API Platform dependency tree that will coexist awkwardly with Laravel's own versions of shared PSR/Symfony contracts. The pragmatic path remains API-level integration (REST/GraphQL) with Laravel as the client — a moderate, well-understood effort. v2.3.1 reinforces this: the release is almost entirely server-side change (Symfony framework bump, OpenAPI doc corrections, mapping-cache fix), which is exactly the class of change that is invisible to an HTTP client but disruptive to an in-process embed. Every future release with this profile would force a Laravel-side dependency resolution cycle if the package were installed directly. Treat the API boundary as the primary architectural defence.

Technical risk.

• License (unchanged, still the top risk): OSL-3.0 is a reciprocal copyleft license with an "External Deployment" clause that can trigger source-disclosure obligations for modified code offered as a network service. This is a material legal risk for a closed-source commercial SaaS and must go through legal review before any dependency is taken. Nothing in v2.3.1 alters this.
• Compatibility narrowing (new): v2.3.1 moves the baseline to Symfony 7.4, with two follow-up fixes explicitly attributed to the bump (configuration value denormalization, OpenAPI user-roles range type). This confirms the package tracks current Symfony minors closely and does not maintain a wide backward-compatibility window. Budget for a Symfony-line upgrade cadence, not a stable LTS-style one.
• Adoption (slightly improved): six stars and zero dependents remains unproven in the wild, but v2.3.1 shows three separate contributors shipping in one release with tracked internal ticket IDs — evidence of an active, funded maintainer. Bus factor is still low, abandonment risk is lower than previously assessed but not eliminated.
• Release metadata: the earlier anomaly (last release dated 2026-10-13) should still be verified against actual repository tags before planning around it. v2.3.1 is a patch release on top of v2.3.0, so the two should be reconcilable against the public tag list.
• Coupling (unchanged): tight binding to specific Elasticsearch/OpenSearch and Symfony versions; upgrades are not independent of your Laravel upgrade cadence.

Key questions. Is the OSL-3.0 external-deployment clause acceptable for our distribution model? Can gally-standard be consumed standalone, or does it require the full Gally core/runtime? Is there a full supported matrix published for PHP / Symfony 7.4 / Elasticsearch 8 vs. OpenSearch — and does v2.3.1 drop Symfony 6 support outright? What exactly do is_system and is_internal metadata flags gate, and does that affect data we would need to populate during catalog sync? Do we actually need searchandising (rules, boosts, merchandising) or just full-text search — in which case Scout + Meilisearch/OpenSearch is simpler? Is there a commercial support path from Elastic-Suite? Who owns upgrades if the upstream project stalls?

Integration Approach

Stack fit. Treat Gally as a sidecar service: Laravel ↔ HTTP (Guzzle/Laravel HTTP client) ↔ Gally API ↔ Elasticsearch/OpenSearch. Laravel Scout is not a fit out of the box — Gally is not a Scout engine — but a thin custom Scout engine wrapping the Gally API is a reasonable abstraction if the team wants a familiar developer interface. Catalog and merchandising data should flow through Laravel jobs/queues rather than synchronous request-path calls.

Migration path.

1. Spike (1–2 weeks): stand up Gally v2.3.1 (not v2.3.0 — it contains a mapping-cache invalidation fix that would otherwise produce confusing indexing behaviour during evaluation) plus Elasticsearch via Docker Compose in an isolated environment; validate the data model against a product catalog sample.
2. Contract-first API layer: define the search/index endpoints Laravel will call; wrap them behind an interface so the backend can be swapped.
3. Catalog sync: event-driven indexing from Laravel domain events → queue → Gally API, with idempotency keys and a full-reindex command. Confirm whether the new is_system / is_internal metadata attributes must be set explicitly on our payloads or are derived server-side.
4. Search cutover: dual-run alongside the existing search behind a feature flag; compare relevance and latency before switching.
5. Searchandising: introduce rules/boosts only after baseline search is stable.

Compatibility. v2.3.1 pins the reference environment to Symfony 7.4, which in practice means PHP 8.2+ and Elasticsearch 8.x / OpenSearch 2.x. Verify the published matrix before committing, and assume Symfony 6 is out of support. Pin exact versions — gally-standard v2.3.1 specifically, not a floating constraint — given both the low release cadence and the demonstrated willingness to take minor-version bumps. Confirm Laravel 10/11/12 compatibility applies only to your client-side integration, not to the package itself; the Symfony 7.4 bump has no bearing on your Laravel version.

Sequencing. Do not Composer-install gally-standard into the Laravel application. Sequence as: infrastructure → data model → sync pipeline → read path → merchandising. Keep the integration behind an anti-corruption layer so a future swap to Meilisearch/Algolia/OpenSearch is a bounded change.

Operational Impact

Maintenance. You inherit two runtimes (Laravel + Symfony/Gally) and an Elasticsearch cluster — three upgrade surfaces with independent cadences. v2.3.1 adds a fourth implicit cadence: Gally's Symfony minor-version tracking. Because the release bundled a framework bump with two corrective patches, plan to re-test the Gally container (not the Laravel app) on each Symfony 7.x minor and to treat these as routine, scheduled work rather than emergencies. OSL-3.0 means any modifications to Gally that are externally deployed may need to be published; establish a policy for patches/forks up front — this matters more if you carry local patches across a Symfony bump. Upstream release quality now looks credible; cadence is still unproven at six stars.

Support. Community-only by default; no vendor SLA unless Elastic-Suite offers commercial support. The v2.3.1 changelog is well-formed with PR links and internal ticket IDs, which is a positive documentation signal, but there is still no large public troubleshooting corpus. Budget internal ownership — someone must become the Gally subject-matter expert.

Scaling. The Gally API tier scales horizontally and is rarely the bottleneck; the Elasticsearch cluster is. Plan shard sizing, index refresh intervals, and reindex windows against catalog size and write volume. Laravel queue workers govern sync throughput; separate the indexing queue from user-facing queues to avoid starvation during full reindexes. Nothing in v2.3.1 changes the scaling model.

Failure modes.

• Index drift / partial sync — products missing or stale; mitigate with reconciliation jobs and index-version aliases. Note that v2.3.1 fixes a source-field mapping cache that was not invalidated on change, meaning pre-2.3.1 deployments could silently serve stale mappings after a schema edit. Pin at or above v2.3.1 and treat mapping changes as requiring an explicit cache clear regardless.
• Search cluster outage — degrade gracefully to database-backed or cached results; never let search be a hard dependency of checkout or browse.
• Schema/model mismatch on upgrade — now the most likely routine failure, given the Symfony 7.4 bump produced two behaviour fixes (config value denormalization, OpenAPI user-roles range). Pin versions and run contract tests against the Gally API surface in CI.
• Metadata semantics regression — the new is_system / is_internal flags change what is exposed or editable; validate that system/internal attributes cannot be overwritten by our sync payloads.
• API latency/timeouts — set aggressive timeouts and circuit breakers on the Laravel client.
• License breach — the highest-severity non-technical failure; gate adoption on legal sign-off.
• Upstream abandonment — maintain a fork/exit plan; the anti-corruption layer is the insurance policy.

Ramp-up. Steep and unchanged. The team needs searchandising domain knowledge (attributes, families, rules, boosts) plus Elasticsearch query DSL and Symfony debugging. v2.3.1 does not reduce this — an HTTP-only integration still requires the team to understand Gally's data model well enough to populate it correctly. The addition of system vs. internal metadata adds one more concept to learn but no new tooling. Estimate 2–4 weeks for a mid-level engineer to be productive on integration, longer for merchandising configuration. Factor this into the build-vs-buy comparison against a managed search service, which for most Laravel teams will still win on time-to-value unless advanced searchandising is a core differentiator.