Gally Sample Data Laravel Package

Technical Evaluation

Architecture fit

• gally/gally-sample-data is not an architectural component; it is a fixture/demo-data package for Gally, the open-source Laravel-based searchandising suite. It seeds a Gally instance with a sample catalog, attributes, and likely merchandising rules so search/facets/rules can be exercised immediately.
• Fit is therefore conditional and peripheral: it only makes sense if Gally is already (or is being evaluated as) your searchandising layer between storefront/PIM and Elasticsearch/OpenSearch. It does not integrate with a general Laravel app.
• It should be treated as a require-dev concern — local bootstrap, CI fixtures, demos — not as a production data path.
• v2.3.1 does not change this positioning: it is a dependency-only patch (Symfony 7.4 bump), with no new fixture content, commands, or schema.

Integration feasibility

• Low effort: add the Composer dependency, run the Gally install/migration steps, execute the provided seed/import command, then build the Elasticsearch indices. A Laravel developer can be productive in hours.
• Real value is time-to-first-search: it removes the chicken-and-egg problem of needing a realistic catalog before you can evaluate relevance, faceting, and rule behavior.
• It is not a catalog migration tool. Real ingestion must go through Gally's connectors (PrestaShop/Magento modules) or its REST ingestion API.
• v2.3.1 is a drop-in for v2.3.0 — no fixture or command changes means no re-validation of seeded content is required beyond a smoke run.

Technical risk

• Version coupling: sample fixtures are tightly bound to Gally core index mappings and entity schemas. Any Gally upgrade can silently break seeds or produce documents that no longer match templates. Note this bump is a transitive Symfony constraint, not a Gally-core alignment signal — it says nothing about fixture/schema currency.
• PHP floor moved implicitly: Symfony 7.4 requires PHP ≥ 8.2 and constrains the Symfony component range shared with Laravel. If your Gally install pins an older Symfony line, this patch can create a Composer resolution conflict in an otherwise working dev setup. Pin deliberately.
• Zero external validation: 0 stars, 0 dependents, single-vendor ownership. No community signal, no third-party usage evidence, no ecosystem pressure to keep it correct.
• Health score is poor (≈20/100); the 2026-10-13 last-release timestamp suggests automated mirroring/CI tagging rather than a curated release cadence — v2.3.1 (a bot-style deps PR, single contributor, patch bump) is consistent with that read. Verify tags map to real, tested Gally versions.
• OSL-3.0 is a reciprocal (weak copyleft) license. Internal use is fine; distributing modified versions triggers source-disclosure obligations. Route through legal if you fork it.
• Footgun risk: an easily-invoked seed command can overwrite or pollute shared environments.
• Fixture data is small and synthetic — it will not surface performance, relevance-at-scale, or long-tail taxonomy problems.

Key questions

1. Is this package explicitly dev/demo-only, or is it sanctioned for seeding staging environments?
2. What is the version contract with Gally core — exact pin, caret range, or unpinned? Does the v2.3.1 Symfony 7.4 requirement narrow the compatible Gally core versions?
3. Does it ship index mappings/templates and rules, or only documents?
4. Which entity types are covered (products, attributes, facets, thesaurus, merchandising rules)?
5. Is there a documented teardown/reset path, and is seeding idempotent?
6. What is the vendor's support model and release cadence for this package specifically — will fixture content ever be refreshed, or is the roadmap dependency maintenance only?
7. Where is the real catalog onboarding toolkit, and how much of the POC depends on it?

Integration Approach

Stack fit

• Target stack: PHP 8.2+ (per the Symfony 7.4 constraint introduced in v2.3.1), Laravel (Gally's framework), Composer, MySQL/Postgres for Gally metadata, Elasticsearch/OpenSearch for indices.
• Add as require-dev, pin to the exact Gally core version in use, and isolate invocation to local + CI profiles.

Migration path

• Do not position this as a data migration. Use it for four narrow jobs:
  1. Local developer environment bootstrap.
  2. CI fixtures for search-relevance and rule-engine regression tests.
  3. Sales/pre-sales demos and stakeholder walkthroughs.
  4. Onboarding new engineers to Gally's data model.
• For production catalogs, plan a separate workstream around Gally connectors or REST ingestion, with its own mapping/validation and relevance QA.
• Upgrading to v2.3.1 needs no fixture re-baselining; it is a lockfile refresh plus a smoke test.

Compatibility

• Verify composer.json constraints against your PHP and Gally core versions before adopting. v2.3.1 raises the effective PHP floor to 8.2 and moves the Symfony component set to 7.4 — run composer why-not / a dry-run update against your pinned Gally tree before bumping.
• Confirm the sample documents match the index templates your installed Gally version creates; mismatches manifest as mapping conflicts or silently dropped fields.
• Pin Elasticsearch/OpenSearch major version — analyzer and mapping behavior differ across majors.

Sequencing

1. Stand up Gally (containerized) with a pinned core version.
2. Run install/migrations; confirm admin UI and empty indices.
3. Add gally/gally-sample-data at the matching version as a dev dependency.
4. Seed, then trigger a full index build.
5. Validate search results, facet counts, and at least one merchandising rule end-to-end.
6. Document the reset/teardown procedure and gate the command behind local/CI env checks.
7. Convert the validated queries into CI smoke tests.
8. Only after the above, scope real-catalog ingestion and relevance tuning.

Operational Impact

Maintenance

• Low but non-zero. You inherit breakage on every Gally upgrade, and there is no external user base to surface issues early. Budget a small verification task per Gally bump.
• v2.3.1 confirms the maintenance surface is drifting toward dependency hygiene rather than fixture currency — expect Composer-resolution churn without content updates. Budget a dependency-conflict check per bump, not just a fixture check.
• If you customize fixtures, expect to maintain a fork under OSL-3.0 obligations.

Support

• Community/vendor-repo support only; no warranty under OSL-3.0. Escalation depends entirely on an Elastic Suite commercial relationship, if one exists.
• Treat as best-effort. Do not let a POC timeline hinge on upstream responsiveness; a single-contributor patch release is not a support signal either way.

Scaling

• Sample data is intentionally small. It does not exercise index-size capacity planning, alias switching/zero-downtime reindex, large facet cardinality, or query latency under load.
• Do not derive performance or infrastructure sizing conclusions from it.

Failure modes

• Version mismatch → seed command aborts or partially seeds, leaving inconsistent state.
• Dependency conflict introduced by the Symfony 7.4 bump → composer update fails or forces a collateral upgrade of shared components in the dev environment.
• Elasticsearch mapping conflict → documents rejected; search returns empty and looks like an application bug.
• Destructive re-seed against a shared environment.
• Fixture drift: CI stays green against stale sample schema while production mappings diverge — a risk this release does nothing to reduce.
• Silent dependency on demo taxonomy that doesn't exist in the real catalog.

Ramp-up

• Low for any Laravel developer — roughly half a day to a day to a working demo instance.
• The organizational risk isn't ramp-up; it's misreading scope. The package accelerates evaluation and testing and nothing else. Adopt it as a dev dependency, keep it out of production paths, and fund real catalog ingestion and relevance QA as separate line items.