East Foundation Laravel Package

Technical Evaluation

Architecture fit. teknoo/east-foundation is a framework-agnostic "foundation" layer rather than a full-stack framework. Its value proposition is (a) the #east object convention — every public method returns $this or a new instance — and (b) a set of PSR-aligned HTTP primitives: PSR-7 messages, PSR-11 containers, PSR-15 middleware, plus typed streaming abstractions (ChunkGeneratorInterface, SseGeneratorInterface, CallbackStreamFactoryInterface). The streaming and SSE pieces are the most concrete, differentiated capability; the philosophy layer is a stylistic constraint with real ergonomic trade-offs (it effectively forbids void returns, which collides with event dispatch, loggers, and conventional command-query separation). The underlying "recipe/state" orchestration (Teknoo/Recipe, Teknoo/States) is a bespoke control-flow model that a team must learn before it can read the code, which is a nontrivial architecture-fit cost for most Laravel/Symfony shops.

Integration feasibility. Composer-installed, PHP 8.1+, PSR-2/12, PHPStan-verified, 90% PHPUnit coverage with Behat on top — the engineering hygiene signals are stronger than the 4-star/0-dependent adoption signals suggest. For Laravel specifically, integration is possible but indirect: Laravel is a PSR-11 container, so the package can be bootstrapped, but PSR-7/PSR-15 semantics must be bridged to Laravel's HTTP kernel and its Response/streamed response model. There is no Laravel service provider, no published Laravel integration path, and no evidence of community usage. Symfony 6.0+ has first-party support via Teknoo\East\FoundationBundle and HttpFoundationFactory, which converts chunk/SSE streams into a Symfony StreamedResponse.

Technical risk.

• Adoption risk (high): 4 stars, 0 dependents, effectively a single-vendor ecosystem (Teknoo). No signal of production users to learn from.
• Bus factor (high): one maintainer, one philosophy, an internal dependency chain (Teknoo/Immutable, Teknoo/States, Teknoo/Recipe) that all share the same risk profile.
• Paradigm risk (medium-high): the #east constraint is non-idiomatic. Code review, onboarding, and static analysis tooling will fight it in places; the cost lands on every engineer touching the code, not just at integration time.
• Contract risk (medium): the streaming interfaces are the reason to look at this package, but they are young interfaces — expect signature churn before 1.0 stabilization.
• License risk (low): BSD-3-Clause is permissive and business-friendly.

Key questions.

1. What does this give us that PSR-15 middleware plus Symfony StreamedResponse (or Laravel's response()->stream()) does not, for the specific endpoints we care about?
2. Is the streaming/SSE capability the actual requirement, or is it the recipe/state orchestration? These carry very different switching costs.
3. Who is the accountable maintainer, and what is the release cadence and support commitment?
4. Can we consume only src/Http/Message/* and the stream factory, leaving the #east philosophy confined to that boundary?
5. What is the fallback if the package is abandoned — are the streaming interfaces small enough to vendor/fork at low cost?
6. Are there upstream users (in Teknoo's own products) that de-risk the "nobody uses this" concern?

Integration Approach

Stack fit. Best fit is a Symfony 6+ application using the provided bundle. Laravel is feasible but second-class: expect to write the container binding, the PSR-7↔Illuminate request/response bridge, and a streamed-response adapter ourselves. The package is not a fit for the core domain model of any application — it is a transport/orchestration utility.

Migration path. Treat this as a bounded, reversible adoption, not a platform decision:

1. Spike one long-lived streaming endpoint (SSE or chunked progress feed) behind a feature flag, wired through CallbackStreamFactoryInterface and HttpFoundationFactory.
2. Keep the #east convention scoped to that adapter layer; do not let it leak into application services.
3. Measure against the incumbent (Symfony StreamedResponse / Laravel stream()) on LOC, memory behavior under load, and client-disconnect handling.
4. Only expand beyond the streaming boundary if the recipe/state model demonstrates a concrete win over our existing orchestration.

Compatibility. PSR-7/11/15/20 alignment means it will not fight our existing HTTP abstractions. PHP 8.1+ is likely already satisfied. Verify the PSR-7 implementation we already use (Guzzle, Laminas, Nyholm) against the infrastructures/laminas/ reference and check for duplicate-interface conflicts with any other PSR-7 package in the tree.

Sequencing.

• Phase 0 — Due diligence: confirm maintainer responsiveness, review open issues/PRs, read the streaming tests, verify the "stops when the HTTP client closes the connection" claim under our web server (php-fpm vs. Octane vs. RoadRunner behave very differently).
• Phase 1 — Isolated POC: one endpoint, non-critical path, telemetry on chunk latency and memory.
• Phase 2 — Hardening: decide whether to pin a tag, vendor the streaming interfaces, or fork. Define an exit plan.
• Phase 3 — Expand only on evidence. Default answer is "no further adoption."

Operational Impact

Maintenance. This is the dominant cost driver. Adopting the package means adopting a philosophy, three sibling libraries, and a bespoke orchestration model, all with a single-digit-star ecosystem. Budget for internal ownership: someone must be able to read and patch the recipe/state internals, because upstream support is best-effort at best. If we fork, the 90% coverage / PHPStan gate becomes our burden on every patch — a real, recurring tax.

Support. No commercial support, no SLA, no published LTS policy. Incident response for a streaming bug becomes "read the source and patch it" — acceptable for a non-critical feature, unacceptable for anything on the revenue path. Escalation must be internal.

Scaling. The streaming design is reasonable on paper: per-chunk write-and-flush, connection-close detection, generator-driven memory profile (constant rather than buffered). Real scaling behavior depends entirely on the runtime — callback-based flush assumes a long-lived, non-buffering execution context, which holds for php-fpm per-request but needs explicit verification under Laravel Octane, RoadRunner, or Swoole where worker reuse and output buffering change the rules. SSE through corporate proxies and load balancers is a recurring operational surprise; plan for buffering and timeout tuning.

Failure modes.

• Abandonment: package goes stale, PHP version advances, we are stuck on a pinned SHA. Mitigated by keeping the blast radius to one adapter.
• Stream truncation: chunk generators that throw mid-stream produce a 200 with a partial body — clients must be designed to detect this. Confirm the step sets status/headers before acceptResponse() as documented, or clients will observe a hung connection.
• Client-disconnect detection: claimed, but runtime-dependent; if it fails, generators run to completion and burn workers.
• Interface churn: pre-1.0 signatures shifting under a semver-minor bump.
• Philosophy leakage: once $this-everywhere spreads into application code, it is expensive to unwind.

Ramp-up. Non-trivial and underestimated. A new engineer must absorb: the #east return convention, the recipe/state orchestration, PSR-15 middleware layering, and the stream/SSE callback lifecycle — four unfamiliar concepts before writing a line of business logic. Estimate days-to-weeks, not hours, and expect review friction. If the team already works in Symfony with PSR habits, the curve is shallower; for a Laravel team, add the bridge layer on top.

Recommendation. Constrained pilot only, gated on the streaming use case being real and the exit plan being cheap. Do not adopt the #east philosophy as a house convention, do not let it near the core domain, and do not invest further without a named internal owner and evidence from Phase 1.