Flow Laravel Package

Product Decisions This Supports

• Pipeline / workflow architecture choice. Flow implements flow-based programming (FBP) in PHP: you compose closures or JobInterface implementations into a typed, ordered pipeline where each stage receives the previous stage's output (D1 → D2 → D3 in the README). This is a legitimate design pattern to evaluate when a feature is inherently a sequence of transforms — ETL, document enrichment, media processing, ingestion with validation stages — and where a hand-rolled chain of service calls is becoming hard to reason about.
• Async execution strategy, decoupled from the runtime. The driver abstraction (AmpDriver, ReactDriver, SwooleDriver, OpenSwoole, FiberDriver, SpatieDriver, ParallelDriver, experimental TrueAsyncDriver) is the most product-relevant asset here: it lets engineering defer the "which event loop / which extension does production run" decision without rewriting business logic. A PM can approve an architecture bet on the pipeline model while leaving the runtime pluggable.
• Build vs. buy for concurrency and batching. AsyncHandlerInterface with BatchAsyncHandler and DeferAsyncHandler, plus Event::SYNC/Event::POOL and IpPool, map directly to product requirements like "batch these messages," "backpressure when the pool is saturated," "defer non-critical work." If roadmap items are phrased that way, this package is a candidate to satisfy them rather than a bespoke queue-consumer.
• Symfony integration decisions. The Symfony bridge and #[AsJob] attribute mean this can be introduced incrementally inside an existing Symfony application rather than as a parallel stack — a meaningful factor in sequencing a migration.
• Recursion and convergence use cases. YFlow/LambdaFlow support recursive composition (documented Y-combinator example), relevant to retry-until-converged, tree traversal, and rule engines.
• Prototyping and architecture spikes, not roadmap commitments. With 18 stars, 0 dependents, and a PHP 8.5 floor, the appropriate product use is a time-boxed spike to validate the pipeline model and driver ergonomics — output is a decision document, not a shipped dependency.

Not supported: this package gives you no signal about market demand, pricing, or customer-facing differentiation. It is an internal architecture enabler only.

When to Consider This Package

Consider it when all of the following hold:

1. You are already on, or committed to, PHP 8.5. This is a hard floor and the single largest adoption gate. If the fleet is on 8.2/8.3 today, this is a roadmap dependency, not an available option.
2. The problem is genuinely a pipeline. Multiple ordered stages, each transforming a typed payload, with a need for parallelism, batching, or per-IP ordering (IpStrategy). If the requirement is a simple job queue, a mature queue system is the better answer.
3. The team is comfortable with functional composition. The API is closure- and monad-oriented (do/fn notation, monads and monoids defined in the changelog). This is a real onboarding cost, not a footnote.
4. A spike is acceptable. Budget days, not a sprint, and expect to read the source. The README's own usage sample does not run as printed ($ip is referenced inside the final closure without being in scope, and the trailing )); is malformed) — treat documentation as indicative and verify behaviour in code.
5. You can pin a version and tolerate churn. The package was renamed (Railway FBP → Flow), moved Flow::do to FlowFactory::create, and now shares a unified 8.x monorepo version line with unrelated packages (Navi, MediaBundle, IaExceptionBundle). Tags do not map to the package's own maturity.

Look elsewhere when:

• Production-critical path with an SLA. Single-maintainer project, no dependents, no visible commercial support. Bus factor is the dominant risk.
• You need durable messaging. v1.2.6 removed the Symfony Messenger integration — the durable-queue story is now weaker than the framework default you likely already have.
• You need ecosystem hiring or vendor SLAs. Zero public dependents means no reference implementations, no Stack Overflow corpus, no third-party integrations.
• Your team wants boring. Symfony Messenger, Laravel queues/Horizon, or plain amphp used directly will be cheaper to onboard and easier to staff.
• PHP 8.5 adoption is not funded. Do not let a library force a runtime upgrade you have not otherwise justified.

How to Pitch It (Stakeholders)

For executives (one paragraph): Flow is an MIT-licensed PHP library for building data pipelines as a chain of small, typed, independently testable steps, with pluggable backends for concurrency (Amp, React, Swoole, Fibers). It is technically credible and unusually well-tooled for its size (PHPStan, Rector, PHP-CS-Fixer, PHPUnit across a monorepo), but it is early-stage and unproven: ~18 GitHub stars, zero known dependents, a single maintainer, and a hard requirement on PHP 8.5. Recommendation: fund a short evaluation spike, do not adopt as a platform dependency. The upside is a clean, reusable pipeline model and a runtime-agnostic concurrency layer; the downside is maintainer and upgrade risk that we would carry alone.

For engineering leads: The interesting asset is the driver abstraction plus AsyncHandlerInterface (batch/defer) and IpPool — that combination is what you would otherwise hand-roll around whichever event loop you pick. The cost is a functional-programming API surface, a PHP 8.5 floor, and the fact that Symfony Messenger support was removed in v1.2.6, so durability is now your problem. Treat the docs as a starting point: the README example does not run as written, and version tags follow a monorepo-wide 8.x scheme unrelated to this package's own maturity. Any spike must include a source read of the driver and event layers, a benchmark against our actual payload shapes, and a written exit plan.

Suggested framing in one line: "A promising, low-adoption pipeline library that lets us defer our concurrency-runtime decision — worth a two-week spike, not worth a production bet today."

Decision ask: approve a time-boxed spike (≈5–10 engineer-days) gated on the PHP 8.5 upgrade path; revisit adoption only if the spike shows a measurable win over Symfony Messenger or amphp used directly, and only with a version pin and a named internal owner.