Shopify Laravel Package

Technical Evaluation

Architecture fit. This is not a Shopify SDK in the conventional sense — it is a connector module for the SplashSync framework. Splash supplies the sync engine (object model, field mappers, commit/acknowledge protocol, conflict resolution); connector modules like this one supply the translation layer to a specific remote system. The "Embedded" designation means it is designed to run inside the Splash host application, not as a library that a host application calls into. That distinction is the single most important architectural fact for us: our Laravel service would not composer require this and call $connector->pushOrder(). It would either run alongside a Splash runtime or we would have to lift the connector's internals into our own codebase.

Integration feasibility. Composer-installable, MIT-licensed, pure PHP — no exotic runtime dependencies. Because Splash is built on Symfony components and Laravel shares that substrate (HttpFoundation, Console, Process, HttpClient, Serializer), there is more overlap than the package's framing suggests. The friction is at the bundle-registration and container-compilation layer, plus Splash's own persistence and worker assumptions.

Technical risk. Material, and concentrated in four areas:

The composite score of 0.41 against an opportunity score of 0.76 is the interesting signal: high unmet need, low maturity. That is the profile of a reference implementation, not a dependency.

Key questions to resolve before commitment.

1. Does "Embedded" mean it requires a running Splash Console instance, or can the connector's service classes be instantiated standalone? This determines whether the integration is a container deployment or a code-porting exercise.
2. Which Shopify API version is pinned, and what is the observed cadence of version bumps in the commit history?
3. Is polling, webhook-driven, or Splash-orchestrated incremental sync? Webhook support materially changes our operational design.
4. What is the test story — are there integration tests against a Shopify dev store, or only unit tests with fixtures?
5. What does the splash/core version constraint look like, and how tightly does this module track it?
6. Multi-store and multi-currency/location support — in scope or not?

Integration Approach

Stack fit. Do not attempt to embed the Splash runtime inside our Laravel application. Run the connector as an isolated service — a Symfony/Splash container with its own database schema and worker process — and expose a narrow internal contract to Laravel. Laravel remains the system of record for our domain; Splash becomes an anti-corruption layer for Shopify. This keeps our framework upgrade path clean and contains the blast radius if the package is abandoned.

The alternative — forking the connector and re-implementing its mapping logic against our own queue and HTTP client — is the correct move if the sync surface is small (products, inventory, orders) and we want a single deployable. It is the wrong move if we expect to add a second channel (Amazon, BigCommerce, a POS) later, because we would be rebuilding Splash's orchestration piecemeal.

Migration path. A staged spike-then-widen sequence:

• Phase 0 — Feasibility (1–2 weeks). Stand up the Splash container against a Shopify development store. Prove one read-only object (products + variants) end to end. Confirm or refute the embedded-runtime question above. This is a go/no-go gate, and the deliverable is a written decision note, not working software.
• Phase 1 — Product import. Shopify → Splash → our schema. Read-only, idempotent, backfill plus incremental. Establishes the field-mapping contract and the error taxonomy.
• Phase 2 — Orders and customers inbound. Introduce webhook ingestion with HMAC verification and a reconciliation poll as a safety net. This is where idempotency and ordering guarantees get proven.
• Phase 3 — Inventory and fulfilment outbound. Highest write risk; only after inbound sync has run clean for a full billing cycle.
• Phase 4 — Decide on fork vs. depend. Reassess at ~90 days with real operating data.

Compatibility. Verify PHP constraint alignment with our Laravel version, and pin both the Shopify API version and the full splash/* dependency set with a committed lockfile. Treat the connector's Symfony version floor as a hard constraint on our own upgrade timing.

Sequencing. Read before write, single object type before many, one store before many, polling before webhooks, batch before real-time. Each step should be independently reversible.

Operational Impact

Maintenance. Budget for ownership, not consumption. Realistically this is a fork-with-intent — assume we will carry patches, and structure the repo as a vendored dependency with an internal changelog rather than a clean upstream reference. A standing task to review Shopify's release notes each quarter is non-optional; the failure mode is silent schema drift, not a loud break.

Support. Community issue tracker only. No SLA, no vendor escalation path. We should identify whether commercial support exists through the SplashSync organisation and price it — if it exists, it changes the risk calculus considerably.

Scaling. Throughput is governed almost entirely by Shopify's limits, not by our infrastructure: roughly 2 requests/second sustained on REST, or cost-based budgets on GraphQL, per store. Design for a single concurrent worker per store with backoff, prefer GraphQL bulk operations for backfills, and make the queue durable and replayable. Splash's own worker model may not align with our Horizon/queue conventions; expect to bridge or replace it.

Failure modes to instrument explicitly.

• Webhook delivery failure or out-of-order arrival → reconciliation poll as a periodic backstop.
• Partial sync / half-committed object graphs → require atomic per-object commits and a dead-letter queue with replay.
• Access token expiry or scope revocation → alerting on auth failures, not just on sync errors.
• Inventory oversell during a lagging sync → decide now whether Shopify or our system is authoritative for stock, and enforce it in code.
• Upstream package abandonment → mitigated by the fork plan and by keeping the internal contract narrow enough that a rewrite is weeks, not quarters.
• Duplicate order creation on retry → idempotency keys enforced at the boundary.

Ramp-up. Roughly two to three weeks for a mid-level PHP engineer to reach a working Phase 0 spike, with the caveat that Splash's documentation is the critical path and it is thin. Allocate explicit discovery time and pair the engineer with whoever owns the Shopify-side store configuration and app credentials. Beyond the initial spike, plan for one engineer to hold this area as a named owner — the knowledge concentration risk of a low-adoption package is real, and a single points-of-failure on a sync pipeline is an availability issue, not just a staffing one.