Staci Laravel Package

Technical Evaluation

Architecture fit. splash/staci follows the Splash connector-bundle pattern: a Composer package that registers a Laravel service provider and exposes STACI as a Splash DataSource/DataSet so it can be composed into a pipeline. The "Embedded" designation is the important architectural signal — the connector runs in-process inside our PHP workers rather than proxying to a separate service or SDK daemon. That is a good fit for batch/CLI ETL and scheduled imports in a Laravel app, and a poor fit for anything needing low-latency request-path reads or independent scaling of the source. Treat it as a data-extraction adapter, not a runtime dependency for user-facing traffic.

Integration feasibility. Mechanically trivial: composer require splash/staci, confirm package discovery, define a pipeline. The real feasibility question is whether the package is installable at all from our toolchain — the repository lives on GitLab, and with zero stars and zero dependents there is no evidence it is published to Packagist or that any external team consumes it. Expect to add a VCS repositories entry or a path/vendor repository, pin a specific commit, and accept that "latest" may be a moving branch.

Technical risk. This is an unproven artifact with no adoption signal. Concretely:

• Bus factor 1. Single-maintainer GitLab project; no issue history, release cadence, or community to fall back on.
• Compatibility drift. Constraint set against Splash core, PHP, and Laravel versions is unknown. A Laravel major upgrade is likely to break it silently.
• Contract opacity. Neither the STACI data model nor the connector's failure/retry semantics are documented in what we can see; we would be integrating against behavior, not spec.
• Security surface is small (embedded, no network listener) but supply-chain review is still required for an unpinned, low-visibility dependency.

Key questions to resolve before commitment. What exactly is STACI and is it a system we already license? Is the package on Packagist, and what is the tagged release history? What PHP/Laravel/Splash versions are supported? What license? Is there a test suite and does it run green? Who is the maintainer and what is their response SLA? Does the connector stream or buffer full result sets in memory?

Integration Approach

Stack fit. Assume a standard Laravel app with queue workers and the scheduler. The connector slots in as the extract step of a pipeline invoked from a console command or queued job. Because it is embedded, we add no infrastructure — no sidecar, no credential broker beyond what STACI itself needs. That keeps the deployment surface flat and is the main argument for using it at all.

Migration path. Do not let Splash types leak into domain code. Define an internal StaciReader interface in our own namespace, implement it with a thin adapter over the package, and bind it in a service provider. If the package is abandoned — a live possibility — swapping to a hand-rolled HTTP client or an exported CSV becomes a one-class change rather than a refactor.

Compatibility. Before anything else, run a dependency resolution spike against our actual PHP version and Laravel major. If constraints conflict, fork to an internal GitLab namespace, relax the constraint, run the suite, and pin by commit SHA. Pin Splash core and the connector together; they version in lockstep more often than not.

Sequencing.

1. Spike (1 week, one engineer): install in a sandbox branch, pull one small dataset end to end, record memory profile and failure behavior on a malformed response.
2. Fork and pin: internal mirror, license check, dependency audit, CI job that runs the package's own tests.
3. Adapter and contract tests: interface wrapper plus fixture-based tests so upstream breakage is caught in CI, not production.
4. Pilot: one non-critical, idempotent dataset on a schedule, with row-count and freshness assertions.
5. Productionize: only after the pilot survives two weeks and one dependency bump.

Operational Impact

Maintenance. Assume we own this. Budget a recurring line item — roughly a day per quarter for dependency bumps and Laravel upgrade compatibility, more if we carry a fork. If the fork accumulates patches, that cost rises and should be tracked as technical debt with an explicit exit trigger.

Support. There is no vendor SLA and no community to escalate to. Escalation path is "read the source." Ensure at least two engineers have opened the connector internals before go-live; a single-owner integration on top of a single-maintainer package is a compounding risk.

Scaling. Embedded execution means throughput is bound by PHP worker memory and CPU. Large extracts will need chunking at the pipeline level, queue-based fan-out, and a memory ceiling per job. This scales horizontally with workers, not vertically with data size — plan capacity accordingly and set hard limits so a runaway extract kills a job, not a node.

Failure modes to instrument. Silent schema drift at the STACI source (assert expected columns and row-count bands every run); partial extraction committed as success (require an explicit completion marker before downstream consumers read); swallowed connector exceptions (do not rely on the package's error handling — wrap every call); and version breakage on framework upgrades (covered by contract tests).

Ramp-up. The package itself is small; the learning curve is Splash pipeline conventions plus the STACI data model, not the connector. Expect one to two engineers, roughly a sprint from spike to pilot, with the majority of that time spent on observation and instrumentation rather than integration code.