Course lesson 23 · Working with Queues
Building Type Safe Queue Handlers
The queue consumer now validates incoming messages and routes recognised event types to dedicated handlers. A Zod discriminated union turns the event’s type label into a dependable choice of payload shape, and the first handler persists link-click data to D1 through the shared DataOps package. This creates an end-to-end path from a visitor’s click to a queryable database record.
Primary source: course video 23 · Supplied English subtitles · 00:11:00.
Understand the idea
- TypeScript helps producers during development; runtime schema validation checks the actual message arriving at the consumer boundary.
- A discriminated union associates each literal event type with its corresponding data schema.
- safeParse returns a success or failure result, allowing the code to choose how to handle invalid data.
- The queue entrypoint performs validation and routing, while a dedicated handler owns the business operation.
- Shared database queries keep persistence code reusable across the web application and data service.
What the course does
- Inspect the common queue envelope and the specific link-click schema in DataOps.
- Validate each message body with the queue schema’s safeParse operation.
- Log validation errors for unrecognised or malformed messages in the course implementation.
- Create the add-link-click query that inserts the event fields into the link-clicks table, then rebuild DataOps.
- Add a link-click handler that calls the shared query, and await it from the consumer after checking the event type.
- Deploy, visit a known smart link, and query D1 to confirm that a real click record appears.
Watch for
- The course’s invalid-message branch only logs an error; it does not demonstrate a quarantine or recovery strategy.
- Added advice: decide explicitly whether invalid events should be rejected, archived, alerted on, or retried.
- Added advice: account for duplicate delivery before extending the handler with operations that must not repeat.
Recall before revealing
Why validate messages if the producer already uses a TypeScript type?
Reveal the explanation
Types are development-time checks; the actual queue payload can still be malformed or come from a different producer or version.
Try it
Describe a second event type that could use the same queue. Specify its type label, required fields, and dedicated handler responsibility.
Check your result
Your new type has a distinct schema and handler, and adding it does not require mixing its business logic into the existing link-click handler.
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:23 — Runtime validation with Zod
- 00:01:42 — Discriminated union by event type
- 00:02:48 — safeParse on message.body
- 00:05:14 — Shared add-link-click database query
- 00:09:10 — Confirming a persisted click in D1
Companion primary documentation: Queues delivery guarantees. For recorded API names, commands, limits, and prices, check the version you use.