Recipe Laravel Package

Product Decisions This Supports

• Build-vs-buy for workflow orchestration. If a roadmap item calls for configurable, step-based business flows in a PHP backend (order routing, onboarding, approval chains, content moderation, data-enrichment pipelines), teknoo/recipe is a viable build short-cut: it supplies the execution model (ordered middleware, conditional requirements, sub-flows, error handlers) so the team only writes business steps.
• Feature: tenant- or plan-specific business logic. Because recipes are immutable definitions with relative step positioning and runtime ingredient checks, Product can offer “tiered” behavior (e.g. premium approvals run before standard ones) without branching spaghetti — recipes can be composed, extended and reused per segment.
• Feature: dynamic step composition. DynamicBowl and runtime ingredient resolution let the workflow decide which callable runs at execution time from the workplan — useful for plugin-style extensibility and customer-defined steps, as long as inputs are trusted.
• Roadmap: pipeline-as-data. Treating flows as first-class objects (Recipe/Plan, train(), given()) means flows can be versioned, tested and injected like any other service. That supports a roadmap of “customer-configurable pipelines” without inventing a DSL from scratch.
• Roadmap: parallel and long-ish-running steps. Fiber bowls plus the CookingSupervisor give cooperative concurrency inside a request/worker — relevant for fan-out enrichment, batch validation, and multi-provider calls. It is not durable long-running orchestration.
• Use cases worth scoping: payment-provider routing and fallback, document/OCR post-processing, KYC and onboarding checklists, pricing-rule evaluation, webhook fan-out, import/validation pipelines, feature-flagged release flows.
• Product-level risk input to the buy decision: the package is BSD-3 (no lock-in, forkable), but adoption is effectively zero (3 stars, 0 dependents, very low score). It should be judged as source code we adopt, not an ecosystem we depend on.
• Reusable algorithm catalogs. PlanInterface implementations can be shipped as injectable classes, letting multiple product surfaces (API, CLI, queue workers) reuse the same vetted flow definitions — a governance win for consistency across teams.

When to Consider This Package

Consider it when:

• The stack is PHP 8.4+ and the team is comfortable with strict types, enums, attributes, DI containers, and immutable object design.
• Workflows are a meaningful product differentiator (configurable, customer-specific, or rapidly changing), not incidental glue code.
• You need conditional execution by declared requirements (ingredients), not just a fixed A → B → C chain.
• You want sub-recipes, relative step ordering, loops, and cooperative concurrency without standing up an external orchestrator.
• You can own the dependency: vendor/fork it, pin the version, and accept that upstream velocity and support depend on a very small maintainer base.
• Your steps are in-process and short-lived (seconds, not days), with state in the workplan rather than persisted by the library.

Look elsewhere when:

• The runtime is PHP < 8.4, or the team cannot adopt fibers and the east-style promise model.
• You need durable, long-running or crash-resilient workflows — persistence, retries with backoff, timers, saga/compensation, exactly-once semantics. Choose Temporal, Camunda/Zeebe, Laravel queues + a workflow package, or the Symfony Workflow component instead.
• Product requires a visual workflow designer or business-user editing; this is a developer-facing library with no authoring UI.
• You need observability, dashboards, audit trails, human-in-the-loop tasks, or SLAs out of the box.
• The pipeline is simple and linear — Laravel’s pipeline, Symfony middleware, or plain decorated services are cheaper to own.
• You require vendor support, security SLAs, or an active CVE-response process, or your procurement gate demands measurable community adoption.
• Steps may be fed by untrusted user input. The documented security caveats around DynamicBowl and object-type ingredients make user-driven composition a hard no without a strict allow-list layer.

How to Pitch It (Stakeholders)

For executives: We have a candidate library, teknoo/recipe, that lets us express business workflows as composable, testable “recipes” — ordered steps that run when their required inputs are present. In plain terms, it lets Product ship configurable flows (routing, approvals, enrichment, tiered rules) faster, without licensing a BPM platform and without vendor lock-in: it is BSD-3, forks cleanly, and is pure PHP with no external services. It is a build-vs-buy accelerator, not a platform bet. The material risk is maturity: a tiny maintainer base and near-zero adoption mean we must own the code — pin it, review it, and keep the option to fork. Recommendation: run a bounded pilot in one flow with clear rollback, then decide. Do not put it on the critical path of revenue-critical orchestration until the pilot and a security review clear.

For engineering: It is a DI-friendly, immutable, middleware-style execution engine for PHP 8.4+ — recipes compile into trained Chef instances, bowls map workplan ingredients onto callable parameters, and sub-recipes, relative ordering, loops, and fiber-based concurrency are built in. The engineering hygiene is genuinely strong: 100% coverage, PHPStan max, PSR-12, Behat features, a documented changelog and strict “never modify an existing test” discipline — that is a meaningful signal for a small project. The costs are conceptual weight (fibers, east-style promises, stated classes, ingredient resolution order) and operational surface (we drive the supervisor ourselves; no persistence). Two security rules must be enforced in code review: never map a user-controlled key into dynamic bowls, and never let user input satisfy object/class-name ingredients. Suggested adoption path: a spike on one non-critical flow, vendored and pinned, with an internal wrapper so our domain code does not import the library directly — that keeps an exit cheap if the maintainer disappears.