Streams Platform Laravel Package

Technical Evaluation

anomaly/streams-platform is not a utility library — it is an application platform that layers a domain-driven, config-as-code data model, an addon/module system, and an admin control panel on top of Laravel. The correct framing for the decision is "are we adopting a framework?" rather than "are we adding a dependency?" That raises the bar for fit, exit cost, and governance well above a typical Composer package.

Architecture fit

• The platform owns routing surfaces, view namespaces, the asset pipeline, and the control panel. It is designed to be the backbone of the application, not a passenger in someone else's Laravel app.
• "Code-configured" means streams (domain entities), fields, and assignments live in versioned code/config, not in a database admin UI. This is a strong fit for teams that already treat schema as code, review changes via PR, and deploy through CI.
• "Flat-file" is the load-bearing assumption. It reduces relational coupling and simplifies local development, but it relocates state and consistency concerns to the filesystem. That is acceptable for content-shaped or configuration-shaped domains and questionable for high-write, transactional, or reporting-heavy workloads.
• Best fit: greenfield product lines, internal tools, and multi-tenant-ish "many small apps" portfolios where a shared addon kit compounds in value. Poor fit: retrofitting an existing Laravel domain model.

Integration feasibility

• Composer-installable and Laravel-native, so the mechanical install is low-effort; the structural integration is the expensive part.
• Addon ecosystem is effectively nonexistent at this scale — 170 stars and 0 dependents means we will author nearly every domain module ourselves. Treat the addon framework as an internal accelerator, not an ecosystem we are buying into.
• Coexistence with conventional Eloquent models is technically possible but creates two competing data-access idioms. Any mixed-mode app needs an explicit boundary rule or it will drift.

Technical risk

• License is the gating item. NOASSERTION is not a license. We cannot ship this to production until counsel clears it; the repository name and package naming suggest MIT, but a TPM cannot accept "suggest."
• Bus factor of one. A single-maintainer project with no dependents and no downstream user base provides no early-warning system for breakage and no peer network for troubleshooting.
• Momentum signal is weak. The opportunity score of 14.92 is consistent with a niche, author-driven project rather than one with a widening adoption curve. We should not assume the community will grow to cover our risk.
• Upgrade churn. Laravel majors move fast; a framework-shaped package must track them. Without a published BC/LTS policy, every Laravel upgrade is an unbounded project.
• Performance profile unknown. File-backed reads/writes, cache invalidation, and control-panel query behavior at realistic data volumes are unverified for our use case.

Key questions to resolve before any commitment

1. What is the actual license, and will the maintainer publish an SPDX identifier?
2. What is the support matrix (Laravel majors, PHP versions, DB drivers) and the BC policy across releases?
3. Is there a commercial sponsor, or a stated succession/vendoring plan?
4. What are the documented concurrency and atomic-write guarantees for the flat-file driver?
5. At what data volume or write rate does the file driver need to be swapped for a database driver, and how invasive is that swap?
6. Can the control panel be extended or replaced without forking core?

Integration Approach

Stack fit. Only viable for a PHP/Laravel team already comfortable with service providers, the container, Blade, config caching, and asset publishing. Teams on other runtimes, or teams without deep Laravel fluency, should stop here — the platform amplifies Laravel idioms rather than abstracting them. The control panel is opinionated UI; if our product needs a bespoke admin experience, we are fighting the platform.

Migration path.

• Greenfield: direct adoption is reasonable, provided the license clears.
• Brownfield: do not attempt an in-place retrofit of an existing domain. Use a strangler approach — mount Streams behind a route prefix or subdomain, leave the incumbent app's core untouched, and move capability over feature by feature only where the platform's model is a genuine fit.
• Exit path: the single most important architectural rule is that business logic lives in our addon classes with thin Streams bindings, and domain state must be exportable. If business rules exist only as Streams config, we have no exit and no leverage.

Compatibility. Verify before the spike, not during: supported Laravel majors against our current version, PHP version, storage driver requirements (local vs. object storage), whether it tolerates our cache/session/queue configuration, and whether addon versions are pinned to platform versions. A platform that must be upgraded in lockstep with Laravel changes our release cadence, not just our dependency list.

Sequencing.

1. Gate 0 — Legal. License clarification in writing. No engineering time spent before this clears.
2. Gate 1 — Timeboxed spike (2–3 weeks). One non-critical internal tool, one addon, one control-panel customization, and a rehearsal of a Laravel minor/major upgrade. Instrument for performance on realistic data.
3. Gate 2 — Decision review. Compare measured spike outcomes against building the same thing on plain Laravel + a conventional admin package. This is the real counterfactual and should be an explicit line item.
4. Pilot. Production use on a low-blast-radius surface with a named owner and a rollback plan.
5. Standardize. Internal addon conventions, CI checks for config drift, scaffolding templates, and upgrade runbooks.
6. Broaden. Only after surviving one full Laravel upgrade cycle without a fork.

Operational Impact

Maintenance. Config-as-code shifts schema change management into code review and deployment. That is good discipline and a real operational tax: no DBA-in-a-UI, no hotfixing a field definition in production, and every domain tweak is a release. Budget one engineer as the named platform owner — this is not a package anyone "just maintains." Upgrades track Laravel majors; reserve capacity each cycle, and assume at least once you will vendor or fork.

Support. There is no commercial backing and the community is thin. Our support model is internal expertise plus source access. That means we should be comfortable reading the platform's internals, not just its docs, and we should maintain a fork-readiness checklist (clean patch set, documented local modifications).

Scaling. The flat-file premise is the scaling question. Horizontal scale likely requires a shared or distributed filesystem, or a switch to a database driver — validate which before committing to multi-node deployment. Caching strategy materially affects both performance and correctness (stale config after deploy is a classic). Control-panel asset compilation adds build-time cost to every deploy, and addon count compounds it.

Failure modes to design against.

• Filesystem permission errors, disk exhaustion, and non-atomic writes under concurrency.
• Stale config or view caches after deployment, producing silent divergence between environments.
• Addon load-order conflicts and version lockstep breakage during upgrades.
• Schema drift between environments because definitions are code that can be branched.
• Silent fallback to defaults when a stream or field is missing — failures that look like empty pages rather than errors.
• Vendor abandonment: no upstream fix for a Laravel incompatibility.

Ramp-up. Steep. A competent Laravel developer needs roughly one to two weeks to ship a simple addon, and one to two months to be genuinely proficient with the platform's mental model — streams, fields, assignments, criteria, repositories — layered on top of Laravel itself. Documentation exists but reflects a small-team project; expect source-reading. Onboarding cost scales with team size and is the hidden line item in any "it's free and open source" comparison.

Assessment summary. The architecture is coherent and the code-as-config philosophy will appeal to disciplined teams, but the adoption case is blocked by an unclear license, single-maintainer concentration, zero downstream dependents, and unverified scaling behavior. Recommended posture: hold pending Gate 0, then run a tightly timeboxed spike against a real plain-Laravel counterfactual before any production commitment. For a greenfield internal tool on a Laravel-native team, this can be a strong accelerator; as a retrofit to an existing system, the expected cost and exit risk outweigh the benefit.