docs: Serverless Workers - Encyclopedia (4/4)#4415
docs: Serverless Workers - Encyclopedia (4/4)#4415lennessyy wants to merge 3 commits intofeat/serverless-worker-prereleasefrom
Conversation
Add the encyclopedia entry for Serverless Workers, update workers.mdx and task-queues.mdx with serverless references, add the architecture diagram, update sidebar, and add "Serverless Worker" to Vale terms. Change onBrokenLinks/onBrokenAnchors to 'warn' to accommodate cross-references to pages in other PRs in this series. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📖 Docs PR preview links |
| @@ -41,7 +41,7 @@ A Worker Program is the static code that defines the constraints of the Worker P | |||
| - [How to run a development Worker using the TypeScript SDK](/develop/typescript/workers/run-worker-process#run-a-dev-worker) | |||
There was a problem hiding this comment.
The worker page is going to need a rewrite. With serverless workers, I think we need to update how users should think of this abstraction that we never quite defined well in the docs. Would love some product/engineering input on this question.
- What is a worker?
We don't answer this question at all right now, and deflect to lower-level abstractions, which isn't very helpful and does not account for serverless workers:
In day-to-day conversations, the term Worker is used to denote either a Worker Program, a Worker Process, or a Worker Entity. Temporal documentation aims to be explicit and differentiate between them.
Maybe something like:
A Worker is the execution environment for your Workflows and Activities. It's where your application code actually runs within Temporal's architecture.
| There is no always-on infrastructure to provision or scale. | ||
| Temporal invokes the Worker when Tasks arrive on a Task Queue, and the Worker shuts down when the work is done. | ||
|
|
||
| A Serverless Worker uses the same Temporal SDKs as a traditional Worker. |
There was a problem hiding this comment.
I have been using "traditional worker" to refer to long-lived workers when comparing them against serverless. Do we have a preferred name for our normal workers? Standard worker? Long-lived worker? Hosted worker (not great sounds like we host them)? Always-on worker? Or are we happy with traditional
There was a problem hiding this comment.
Long-lived worker is a good name that we also use internally. I am not opposed to a 3-word compound: "traditional Long-lived Worker"
The comparison table lives on the evaluate page now. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
| There is no always-on infrastructure to provision or scale. | ||
| Temporal invokes the Worker when Tasks arrive on a Task Queue, and the Worker shuts down when the work is done. | ||
|
|
||
| A Serverless Worker uses the same Temporal SDKs as a traditional Worker. |
There was a problem hiding this comment.
Long-lived worker is a good name that we also use internally. I am not opposed to a 3-word compound: "traditional Long-lived Worker"
|
|
||
| A Serverless Worker uses the same Temporal SDKs as a traditional Worker. | ||
| It registers Workflows and Activities the same way. | ||
| The difference is in the lifecycle: instead of the Worker starting and polling continuously, Temporal triggers the compute environment, the Worker starts, processes available Tasks, and then exits. |
There was a problem hiding this comment.
Same comment as other PR: "triggers the compute environment" >> "triggers the serverless worker"
| 3. Temporal uses the compute provider configuration to invoke the serverless function. For example, calling AWS Lambda's `InvokeFunction` API. | ||
| 4. The serverless function starts, creates a Temporal Client, and begins polling the Task Queue. | ||
| 5. The Worker processes available Tasks until the compute environment's deadline approaches. | ||
| 6. The Worker gracefully drains in-progress work and shuts down. |
There was a problem hiding this comment.
"shuts down": We use "exits" in prior text. I like "shutdown" / "shuts down" because Durable Lambda Function use this terminology so it might be easier for folks to comprehend: https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html
akhayam
left a comment
akhayam
left a comment
There was a problem hiding this comment.
I liked the lifecycle diagram on the Lambda docs page: https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html
Should we make something like this for our Serverless Workers?
2 participants
Summary
docs/encyclopedia/workers/serverless-workers.mdx) with conceptual overview and architecture diagramworkers.mdxandtask-queues.mdxwith references to Serverless Workersserverless-worker-flow.svgdiagram to static assetsonBrokenLinks/onBrokenAnchorsfrom'throw'to'warn'to accommodate cross-references to pages in other PRsPart 4 of 4 in the series splitting #4405 into smaller PRs.
Test plan
🤖 Generated with Claude Code
┆Attachments: EDU-6187 docs: Serverless Workers - Encyclopedia (4/4)