Course lesson 37 · Managing Workflows with Durable Objects
Building the Base Class
The instructor builds a small persistent counter inside the future evaluation-scheduler class to make Durable Object identity and state tangible. The constructor restores stored state under blockConcurrencyWhile, methods update and return the count, and a temporary HTTP route calls those methods through a stub. Calling the route with two names demonstrates two independent objects whose values remain separate.
Primary source: course video 37 · Supplied English subtitles · 00:13:44.
Understand the idea
- The class defines the behaviour shared by many object instances; the instance name selects which independent state is accessed.
- blockConcurrencyWhile protects asynchronous initialisation so other operations do not observe incomplete restored state.
- Each increment updates memory and writes the new count to persistent storage.
- A namespace binding resolves an application-defined name to an ID, then returns a stub for calling the object.
- Wrangler bindings, migrations, entrypoint exports, and generated types connect the class to the deployed application.
What the course does
- Create the evaluation-scheduler class, call the base constructor, and initialise a count field.
- Restore count from storage under blockConcurrencyWhile, defaulting when no value exists.
- Implement increment with a storage write and get-count with an in-memory read.
- Configure the Durable Object binding and the initial migration for the course’s key-value-backed class.
- Export the class, regenerate environment types, and add a temporary route that selects an object by name.
- Run locally and alternate between two names, observing independent counters and retained values when returning to each name.
Watch for
- The counter and temporary route are teaching scaffolding; lesson 38 removes them.
- ID-from-name uses an application-defined identity; ID-from-string expects the representation of an existing Durable Object ID.
- Added advice: a class migration is a lifecycle/configuration change, not the same thing as a SQL data migration within an object.
Recall before revealing
Why do test-one and test-two keep separate counts even though they use the same class?
Reveal the explanation
The namespace resolves their different names to different object instances, and each instance owns its own state.
Try it
Reproduce the two-name counter experiment, then stop and restart the local service without deleting its persistent state and check the counts again.
Check your result
You can distinguish separate object identities from separate in-memory lifetimes and explain how storage restores each value.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Rewatch only what you need
Open this lesson in your original course library and seek to the times below. Videos are not hosted on this site.
- 00:01:49 — Restoring persisted count safely
- 00:03:02 — Increment and storage write
- 00:05:20 — Initial Durable Object migration
- 00:08:26 — Application identity with idFromName
- 00:11:19 — Testing independent named counters
Companion primary documentation: What are Durable Objects?. For recorded API names, commands, limits, and prices, check the version you use.