Loading today’s stories
Build1 distinct publisher3 min readPublished
A dev.to walkthrough hands a seven-day onboarding flow to a workflow engine on port 7233. The install is two lines; the part that reshapes your code is the rule that the orchestrator may never touch Eloquent.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
build
Stop defending numprocs=10: derive queue workers from a latency promise1 distinct publisher
build
Once the question needs a cube, you own the parser1 distinct publisher
build
Rewritten tags beat your pin: what laravel-lang says about Composer trust1 distinct publisher
build
PHP-FPM's dynamic pool is a one-second idle-worker loop, not a capacity plan1 distinct publisher
The rule barring the orchestrator from databases, external systems and random functions [6] serves a specific mechanical purpose, not a stylistic one. Nothing about coordinating steps needs it. It only makes sense if that function is expected to run more than once against a recorded history, with each `yield` resolving from something the server already knows. That is the mechanism behind the promise of guaranteed state progression [5]: the wait stops being a delayed job in Redis and becomes an event the cluster owns, and the PHP worker holding the process becomes disposable.
The two timescales in the sample show the seam. The workflow method yields `Workflow::timer(CarbonInterval::days(3))` [11]. The activity stub is constructed with a single option, `withStartToCloseTimeout(CarbonInterval::seconds(30))`, under a comment that calls it retry settings [10]. Three days is 259,200 seconds, so the orchestrator's shortest wait is 8,640 times the ceiling on one activity attempt [2]. That ratio is the point. Nothing in the worker needs to survive the gap, which is exactly the property the hand-rolled version lacks when a server reboots mid-process [4].
Adoption lands in two places. The runtime: a Composer install [8] plus a cluster for `TEMPORAL_ADDRESS` to point at [9]. The walkthrough does not cost that cluster out, and if Redis queues and supervisors are already handling millions of ordinary jobs for you [1], this is a second durable system rather than a replacement. The code: activities keep `User::findOrFail` and the `Mail` facade, resolved through Laravel's container [12], while the workflow keeps the timers and the branch [7]. Any existing job class that both sleeps and queries has to be cut along that line before it can move.
Then read the listing against the claim. Temporal is described as handling state persistence, timeouts, queryable statuses and complex retries [5]. The published code stops mid-identifier at `checkProfileS` [13], so the second timer and the sales-outreach escalation described in the flow [3] exist only in prose. Given the article's subject is keeping track of a user's progress through a flow, that gap is an ironic failure mode to leave hanging.
What would have to be true for this to transfer to your system: the requirement is that a single unit of work outlive a deploy, and a thirty-second email send falls well short of that bar. The seven days of elapsed waiting in this onboarding arc [1] cross at least one release, probably several, and every one of them is a chance to lose the row that says which step a given user reached. That is the threshold I would use, and it is narrower than the framing here suggests. The author's own opening concedes it: standard queues only start to show limits when the work becomes a multi-day, retry-sensitive state machine [2]. Below that line, the delayed dispatch you already run is cheaper than a new cluster plus a determinism rule you have to teach the team.
Ranked by verification strength, evidence, and original report placement.
Workflows are the orchestrator and must be deterministic: they dictate execution flow, handle sleep intervals and coordinate steps, and must not interact directly with external systems, databases or random functions.
Activities are the execution layer, may be non-deterministic, and perform the actual work such as database queries, third-party API calls, sending emails and writing files.
The example onboarding flow is: send a welcome email; wait 3 days; check whether the user uploaded a profile picture; if not, send a reminder; wait another 4 days; if still incomplete, flag the account for manual sales outreach.
The official Temporal PHP SDK is installed with composer require temporal/sdk.
The environment is configured with TEMPORAL_ADDRESS=127.0.0.1:7233 in .env, and a local Temporal installation runs on port 7233 by default.
The workflow constructor calls Workflow::newActivityStub on the activities interface with ActivityOptions::new()->withStartToCloseTimeout(CarbonInterval::seconds(30)), under a code comment describing it as binding the activities interface with retry settings; no retry policy or query method appears in the listing.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 29, 2026
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Checkable in the listing, asserted everywhere else
The mechanics are unusually easy to verify because dev.to prints them: the Composer line, the 7233 address, the workflow/activity split, the 30-second start-to-close timeout, the three-day timer, Eloquent and Mail confined to the activity class. You can audit the architecture without leaving the page. Everything the prose promises around that code is a different matter — guaranteed state progression, queryable statuses, complex retries and reboot survival appear as claims with no configuration, no test and no second account behind them, and the listing quits before the four-day wait exists.
No usage on the record
Nobody in this story runs this anywhere. There is no version pin, no production deployment, no traffic figure, no team saying it held. A worker booted under Supervisor in a tutorial is a demonstration of syntax, and treating it as uptake would be inventing a fact this reporting does not contain.
Promise runs a few days ahead of the code
The gap is narrow, and you can watch it open in a single comment: 'Bind the activities interface with retry settings' sits directly above options that set nothing but a 30-second timeout. The same shape repeats at flow level — a seven-day journey is advertised, three days of it are implemented, and the sales-outreach step exists only as a bullet. What keeps the number modest is that dev.to does not knock Laravel down to sell the alternative; it credits queues with millions of jobs and presents determinism as a restriction you must live with.
Nothing disclosed either way
This is one community post with no statement about any relationship between its author and Temporal, no sponsorship note, and no vendor announcement or rival account to weigh it against. That is an absence of information, not evidence of independence, and we will not fill it in.
One voice, cut off mid-signature
Everything we know here comes from one author writing on dev.to. The mechanical parts we checked by reading them; the durability promises that would actually justify the migration have no second place to go, and the walkthrough breaks off inside a method signature, so even its own demonstration is unfinished. Temporal's documentation, or one shop describing a week-long run that survived a deploy, would move this sharply.