Sdk Laravel Package

Product Decisions This Supports

• Build vs. buy for orchestration. The recurring alternative is a hand-rolled state machine: a status column, chained queue jobs, cron sweeps, and ad-hoc retry logic. This SDK replaces that with durable execution — the server persists workflow state, handles retries/timeouts, and resumes after process death — while the workflow definition stays in PHP. That's a "buy the durability layer, keep your language" decision, not a rewrite.
• Where business logic lives. Because workflows are authored in PHP and executed by a worker against a Cloud or self-hosted server, you can keep long-running business logic inside the Laravel codebase (same ORM, same domain models, same test tooling) instead of extracting it into a Go/Java service the way Temporal adoption often pressures teams to do.
• Roadmap unlocks for multi-step, failure-prone flows. Checkout and payment authorization → inventory reservation → fulfillment → notification (with compensations on failure); subscription dunning and billing retries; KYC/onboarding with human-in-the-loop approval steps; document/claims processing; refund and chargeback handling; scheduled recurring jobs that need idempotency and visible run history.
• Deployment topology and lock-in posture. The SDK explicitly targets both Durable Workflow Cloud and self-hosted Server, which lets you start on Cloud for speed, then move on-prem for data-residency or cost reasons without changing application code — a vendor-risk decision the SDK keeps open rather than foreclosing.
• Incremental migration scope. The realistic adoption path is extracting one fragile queue chain at a time (the flow that pages someone every month) rather than a platform-wide migration, so the roadmap decision is which workflow gets extracted first, not whether to re-architect.
• Observability as a product requirement. Durable execution gives you per-step run history and audit trails for business processes. If a stakeholder is asking "where is order #1234 stuck and why," that requirement is a reason to adopt orchestration rather than a reason to add more logging.

Honest signals to weigh: 4 stars, 0 dependents, and a low overall score (20.25) against a high opportunity score (63.75) tells you this is a real, underserved gap — PHP is thin on durable-execution options — served by an early-stage package. The recent release date suggests active maintenance, but there is no third-party adoption to lean on. Treat the first integration as a spike with an exit path, not a load-bearing commitment.

When to Consider This Package

Adopt when most of the following hold:

• You have workflows that outlive a single request or job and currently rely on cron + queue chaining + a status column to survive partial failure.
• You need retries with backoff, timeouts, compensations, and in-flight versioning as first-class primitives, not bespoke code per flow.
• Your team is Laravel/PHP-committed and unwilling to move business logic to Go/Java — or unwilling to take on Temporal's RoadRunner/Swoole operational footprint.
• You can run a worker process (supervisor, container, Kubernetes deployment) and are comfortable operating or paying for a workflow server alongside your app.
• You need an auditable run history of business processes for support, compliance, or finance.
• You are willing to be an early adopter: read the source, run the self-hosted server locally for tests, and pin versions.

Look elsewhere when:

• You need proven third-party adoption, published case studies, or a support contract with SLAs — the dependency graph here is empty; you would be the reference customer.
• Your infrastructure can't run long-lived worker processes (shared hosting, restrictive PaaS, no process supervision).
• Your problem is plain async job processing, not orchestration — Laravel's queue and Horizon already cover fan-out, retries, and rate limiting at lower operational cost.
• You need extreme throughput or sub-millisecond coordination, or a deep connector ecosystem (activities for dozens of SaaS systems) — a more mature engine wins on breadth.
• You're not prepared to run and back up a stateful server and Cloud is off the table for compliance reasons; adding a stateful dependency without an owner is worse than the status-column you have now.

How to Pitch It (Stakeholders)

To executives: We have a class of business processes — checkout, billing retries, onboarding approvals — that fail halfway and require manual cleanup, and today we handle that with custom retry code that only one or two engineers understand. This package lets us define those processes as ordinary PHP and hands the hard parts (persistence, retries, timeouts, recovery after a crash) to a workflow engine. It's MIT-licensed with no per-seat cost, it runs against either a managed cloud or a server we host ourselves, and it keeps the logic in our existing codebase — so this is an incremental improvement to code we already own, not a platform migration or a rewrite in another language. The trade-off is maturity: the project is early, so I'd propose a time-boxed pilot on one non-critical workflow with a documented fallback before we commit further.

To engineering: The SDK is a thin client plus a worker loop. Workflows are PHP classes; steps are ordinary methods; the server owns durable state, so a mid-flight failure resumes instead of vanishing. That deletes the retry/backoff/dead-letter/status-column scaffolding we keep rewriting per flow, and it gives us run history for free instead of reconstructing incidents from logs. Cost is operational: we run a worker under supervision, we need a local server for integration tests, and we need a versioning discipline for workflows that are in flight during deploys. Recommend a two-week spike extracting one existing queue chain, measured against the current implementation on failure-recovery, debuggability, and deploy safety.