Course lesson 36 · Managing Workflows with Durable Objects
Durable Object API
This lesson separates a Durable Object’s in-memory fields from its persistent storage and introduces the alarm API. A counter illustrates why a field alone is insufficient: when an inactive instance is restarted, memory must be rebuilt from stored data. The course begins with key-value storage for the scheduler and previews SQLite-backed objects for later live analytics.
Primary source: course video 36 · Supplied English subtitles · 00:05:12.
Understand the idea
- A Durable Object class defines methods that use the object’s state, storage, alarms, and other platform facilities.
- A constructor runs when an instance is created in memory, including when an object is reactivated.
- In-memory fields provide convenient current state but are not durable across shutdown.
- Persistent storage allows a restarted object to recover earlier values.
- An alarm uses a future timestamp and invokes the object’s alarm method to perform scheduled work.
What the course does
- Inspect the base class and constructor pattern used to access Durable Object capabilities.
- Consider an in-memory flag or counter and predict its value after the object is shut down.
- Compare this with a counter read from storage and written back after incrementing.
- Recognise the two storage approaches described: simple key-value access and SQLite tables.
- Inspect alarm scheduling using the current time plus a future interval.
- Connect the alarm callback to the later goal of starting a workflow with recovered click context.
Watch for
- A variable declared on the class is not automatically persisted simply because the class is a Durable Object.
- The key-value backend choice reflects this course’s initial implementation; do not infer that all durable state must use that backend.
- Added advice: use milliseconds consistently when constructing alarm timestamps, and explain the interval clearly in code.
Recall before revealing
What must happen when a Durable Object wakes up if its last click context only existed in memory?
Reveal the explanation
That context cannot be recovered; it needed to be stored persistently and then loaded during reinitialisation.
Try it
Trace a counter through initialise, increment, write, shutdown, restart, and read. Write down both its memory and stored values after each event.
Check your result
Your trace preserves the increment across restart only when a storage write occurred and startup loaded that saved 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:00:35 — Durable Object class and APIs
- 00:00:59 — Memory versus persistent state
- 00:02:15 — Key-value and SQLite storage approaches
- 00:03:06 — Persistent counter example
- 00:04:10 — Alarm scheduling with timestamps
Companion primary documentation: What are Durable Objects?. For recorded API names, commands, limits, and prices, check the version you use.