Sdk Laravel Package

Product Decisions This Supports

• Build vs. buy for orchestration: The core decision this package informs is whether to hand-roll state machines, retry loops, cron jobs, and “where did this order get stuck?” admin tooling — or adopt a durable execution engine. Adopting temporal/sdk means buying into the Temporal paradigm (Workflows + Activities + Workers) rather than buying a vendor product outright, since the engine itself is separately self-hosted or consumed via Temporal Cloud.
• Roadmap: long-running, multi-step business processes. This unlocks a category of features that are painful in typical PHP request/queue architectures: order fulfillment with compensation/sagas, KYC and onboarding pipelines, subscription billing and dunning, provisioning, approval chains with human-in-the-loop signals, and anything that must survive process restarts, deploys, and transient third-party outages.
• Replacing bespoke reliability code. A PM can frame the investment as deleting internal “glue” code: retry schedulers, failed_jobs forensics, reconciliation scripts, and status-transition tables that accumulate cost in every sprint. The payback shows up as reduced incident load and faster feature delivery on workflow-adjacent features.
• Feature-level decision: durability as a requirement. When product specs include “must not lose in-flight work,” “must resume exactly where it left off,” “must be auditable step-by-step,” or “must wait days/weeks for a human or external event,” that is a strong signal to standardize on this rather than approximate it.
• Architecture/roadmap sequencing decision. Because the SDK pins real infrastructure requirements (RoadRunner worker processes, ext-grpc for clients, ext-protobuf recommended for production, a Temporal Service in each environment), adopting it is a platform decision that should be scheduled alongside DevOps capacity — not slipped into a feature sprint.
• Cloud vs. self-hosted decision. v2.19 adds a CloudClient for the Temporal Cloud Operations API, which makes a managed-Temporal path viable for teams that don't want to operate a cluster. That directly affects total cost of ownership and the ops headcount assumption in the business case.
• Testability as a product-quality input. The bundled testing toolkit with Activity mocking and the Replay API for determinism means workflow logic can be unit-tested like ordinary PHP, which supports a decision to put complex business rules inside workflows rather than hiding them in untested scripts.
• Make vs. integrate on developer tooling. The README’s guidance on Temporal CLI (embedded dev server + Web UI), Buggregator/Trap for debugging inside workers, and the PHPStorm Meta Storm plugin are relevant to the “can our team actually be productive in this?” question — and to onboarding cost estimates.
• What this package does not decide for you: it is an authoring SDK, not a hosting, observability, or cost-governance product. A PM should treat “who runs the Temporal Service, and what does it cost at our volume?” as a separate, mandatory decision before committing.

When to Consider This Package

Adopt when most of the following hold:

• Workflows are genuinely long-running and stateful — minutes to months, with waits on humans, webhooks, or third parties — and losing in-flight state is a real business cost.
• You need reliable multi-step orchestration with compensation (sagas, refunds, rollbacks) rather than a linear job chain.
• Your stack is PHP and you want the business logic to stay in PHP. The SDK lets Laravel/Symfony engineers author workflows directly instead of introducing a second-language service (Go/Java) purely for orchestration.
• You have the runtime latitude to add ext-grpc, ideally ext-protobuf, and to run RoadRunner worker processes. This is not a drop-in Composer package for a plain PHP-FPM deployment — treat it as a platform capability.
• Auditability and replayability are requirements — compliance, finance, or support needs to reconstruct exactly what happened in a process, step by step.
• You have (or will buy) operational capacity — either a team comfortable running RoadRunner workers and a Temporal Service, or budget for Temporal Cloud (now directly supportable via the CloudClient).
• You value the testing story. Deterministic replay plus Activity mocking is a meaningful differentiator versus ad-hoc queue consumers, and it's a real adoption criterion for teams with CI discipline.
• You are willing to pin versions deliberately. Feature flags (introduced in 2.11.0, and used again in 2.19 for await() settling semantics) change worker-wide behavior; releases explicitly gate history-affecting changes. This favors teams with a real upgrade cadence over teams that never touch dependencies.

Look elsewhere when:

• The work is short-lived and fan-out-shaped — sub-minute jobs, image resizing, email sending. A queue plus a scheduler is cheaper and simpler; orchestration is overhead you'll pay for in worker infrastructure.
• You cannot add PHP extensions or long-running worker processes — shared hosting, restrictive PaaS, or security policy that forbids RoadRunner. This is a hard blocker, not a preference.
• Latency-critical, high-RPS request paths. Workflows are the wrong primitive for hot request handling; use them asynchronously behind a normal request.
• You already have a strategic orchestration platform (existing Temporal investment in another language, or an entrenched managed alternative). Introducing a second orchestrator fragments operational ownership.
• The team has no appetite for running stateful infrastructure and no budget for a managed service. You will inherit cluster lifecycle, upgrades, namespace management, and worker scaling.
• Feature parity with the flagship SDKs matters. The PHP SDK trails Go/Java/TypeScript in feature timing; if you need bleeding-edge platform capabilities on day one, verify against the current release notes rather than assuming parity.
• You require a vendor with commercial support SLAs on the SDK itself. MIT-licensed, community-supported: support comes from Slack/forum/GitHub issues, or from Temporal commercially at the platform layer.
• Signal caveat: the reported “0 dependents” is a metric artifact, not a maturity verdict — Temporal SDKs are consumed directly by application code, so they don't accumulate library-level dependents the way utility packages do. Judge this package by the engine behind it and the release cadence (regular 2.x releases, most recently 2.19), not by that number.

How to Pitch It (Stakeholders)

To executives — one paragraph: We are proposing to adopt the Temporal PHP SDK as the standard way we build long-running, multi-step business processes (order fulfillment, onboarding, approvals, billing lifecycle). Today we approximate this with queues, cron jobs, and custom retry/status code that we maintain indefinitely and that still loses in-flight work during deploys and outages. Temporal makes each process a durable, resumable, auditable workflow: if a server dies mid-process, it continues exactly where it stopped, and support can replay the history step by step. The package is MIT-licensed and maintained by the Temporal project on a steady release cadence, so there is no license cost and no lock-in to a proprietary SDK. The cost is not the SDK — it's a modest platform commitment (worker processes and a Temporal Service, self-hosted or managed). The decision we need is whether to fund that platform commitment; the return is fewer reliability incidents, less bespoke glue code, and faster delivery of any feature that spans more than one system or more than one moment in time.

To engineering leadership — what they're actually signing up for:

• Runtime requirements are explicit and non-negotiable: ext-grpc for clients, RoadRunner for workers, ext-protobuf strongly recommended in production. Plan this as a platform/environment change, not a dependency bump.
• The codebase splits cleanly into Clients (start/schedule/manage, plus OperatorClient and, as of 2.19, CloudClient for the Cloud Operations API) and Workers (execute). That maps well onto existing service boundaries and gives us a natural path to a managed Temporal Service later without rewriting workflows.
• Quality story is genuinely better than our current approach: Activity mocking, deterministic replay in CI, a first-class dev server via the Temporal CLI with an embedded service and Web UI, and Buggregator/Trap for debugging inside workers where var_dump and echo don't work.
• Upgrade discipline is required, not optional. Behavior-changing flags (2.11 feature flags; 2.19's opt-in await() settle-on-first-settled semantics) exist specifically to protect history replay compatibility. We should budget a recurring dependency-review slot so we don't silently fall behind on a deprecated default.
• Integration is unopinionated but supported: first-class Spiral guidance, plus full documentation for using the SDK standalone inside a Laravel/Symfony app.
• Risk to flag honestly: PHP is not the first-tier Temporal SDK for feature timing. Before we commit any roadmap item to a specific platform capability — Workflow Update, updateWithStart, Eager Start — we validate it against current release notes and the samples repository rather than assuming parity with Go/Java.

Ask: approve a short, time-boxed spike — one real workflow (e.g., a billing or onboarding process) built on the SDK behind a feature flag, running on RoadRunner in a staging environment — with a written go/no-go covering platform cost, upgrade cadence, and the first two candidate workflows to migrate.