Backpine / Full Stack on Cloudflare
Your course, compressed into a connected study guide: what each piece does, why it exists, and how to check that you understand it.
The course builds Smart Links: a short-link application with country-based redirects, click analytics, AI destination checks, accounts, and subscription billing. The main learning goal is to understand how those features fit together. The course assumes working familiarity with JavaScript/TypeScript and web development; this guide explains the relationships, but is not a complete introduction to those languages.
Read the system overview below, then open course lesson 01. For each study unit, read the summary, explain the recall answer aloud without looking, and attempt the small task. Rewatch the linked timestamps when your explanation breaks down. Come back the next day and a week later to answer again; these intervals are a suggested routine, not a measured personal schedule.
Begin with course lesson 01 → · Keep the concept reference nearby
Think in three paths: managing links, serving visitors, and processing the resulting events. The same repository shares code, but the two applications can be deployed separately.
The interface handles navigation and server-data state. The server validates inputs and identity, then uses shared database operations. Better Auth supplies session handling; Stripe integration adds subscription records and checkout flows later.
The redirect service reads the link configuration and selects a destination using request metadata. A separate background helper sends the click to a queue and also to an account-scoped tracker for live map updates. Completing the redirect alone does not prove the background send succeeded.
Two Durable Object responsibilities appear: a link-and-destination scheduler controls when an evaluation runs, while an account tracker coordinates live viewers. Workflows manage the evaluation steps; R2 stores bulky evidence; D1 stores queryable application records.
Synthesis of course lessons 01, 18, 22–24, 34–38, and 39–44. This is an architectural explanation of the tutorial, not a claim that every production concern is implemented.
Move in course order on your first pass. Each module adds one reason for the next service to exist.
Establish the local-development and deployment loop before adding more services. The tangible result is a project you can run, change, and deploy.
Your checkpoint: Explain the path from source files to a deployed Worker.
Open this module →Framework code still runs inside an execution environment. Learn the Worker entrypoint, request lifecycle, environment, and resource bindings so configuration errors become understandable.
Your checkpoint: Point to the entrypoint and explain how it reaches a database.
Open this module →The monorepo shares database operations and types across applications. React and TanStack provide the UI; tRPC connects it to server procedures; Drizzle queries D1.
Your checkpoint: Trace a UI action through validation, a query, and the rendered result.
Open this module →A separate Hono service handles public smart-link traffic. It looks up link configuration, chooses a country-specific or default destination, and uses KV to speed up repeat reads.
Your checkpoint: Predict the redirect for a country match, a missing match, and a missing link.
Open this module →Click processing should not dominate the visitor's redirect latency. The producer sends an event and consumers validate, process, retry, or divert failed messages.
Your checkpoint: Explain what happens if processing fails after a message is delivered.
Open this module →Render a destination page, classify its availability, preserve evidence in R2, and save a structured result in D1. Lesson 34 repairs the earlier ordering to avoid oversized step results.
Your checkpoint: Draw the final workflow with small values crossing step boundaries.
Open this module →Repeated clicks should not launch an expensive evaluation every time. An object keyed by link and destination coordinates whether an alarm has already been scheduled.
Your checkpoint: Distinguish a click-triggered delayed check from a perpetual daily schedule.
Open this module →A SQL-backed Durable Object stores recent click events and broadcasts updates over WebSockets. Service bindings let the application Worker reach the data service internally.
Your checkpoint: Describe what a new subscriber sees and where durable history differs from live delivery.
Open this module →Environment-specific Workers, bindings, resources, builds, and routes turn a local experiment into repeatable deployments. Follow one consistent public URL design.
Your checkpoint: Trace which database and services a stage build can access.
Open this module →Better Auth introduces users and sessions. The UI checks session state, while the API must independently authenticate callers and restrict records to the current account.
Your checkpoint: Explain why a hidden page or a disabled button is insufficient access control.
Open this module →Stripe products and recurring prices feed a checkout flow, while webhooks synchronize subscription changes back to the application. The recorded deployment uses Stripe sandbox credentials on stage.
Your checkpoint: Separate checkout completion, webhook synchronization, and feature entitlement enforcement.
Open this module →The final UI ties together the earlier features. Mocked unit tests cover selected business logic; the closing lesson assigns production work such as enforcing plan limits and extending tests.
Your checkpoint: Name the behavior already demonstrated and the production work still left to implement.
Open this module →The recordings contain evolving code, deliberate scaffolding, and dated platform details. These notes distinguish the demonstrated behavior from later fixes and current documentation.
Course correction: lesson 34 supersedes the earlier workflow sequence. Generate the evaluation ID, collect and store large artifacts inside the first step, return text plus ID, classify with AI, then save the D1 row. A later recording may still display the older sequence. Current docs retain a 1 MiB limit for non-stream step results and also support streamed binary results; R2 references remain useful for large or long-lived artifacts.
Current-doc update, checked 13 September 2026: the Queues pricing page lists a Workers Free allowance. Lesson 20's paid-only requirement reflects the recording. Learn how writes, reads, deletes, payload size, and retries affect cost; consult the linked plan pages before estimating a real workload.
Added implementation guidance: Queues provides at-least-once delivery. A consumer must tolerate the same message arriving again. Use a stable event ID and a duplicate-safe database operation or downstream idempotency key when repeating an action would be wrong. A TypeScript type or successful parse does not solve duplicate processing.
Course caveat: lesson 17 uses a 24-hour TTL without demonstrating write-side invalidation. Current docs describe KV as eventually consistent, so an update may not become visible everywhere immediately. Decide how destination edits update or invalidate cached records and what stale behavior is acceptable.
Terminology correction: request.cf is Cloudflare request metadata, not simply a collection of HTTP headers. Country and latitude/longitude describe the client's inferred location; colo identifies the Cloudflare data center serving the request. Use the former for country-based destination selection.
Course implementation: lessons 35–38 schedule a check after a click when no alarm exists, using link ID plus destination URL as the object identity. The demonstration delay becomes 24 hours. Continued daily checks without clicks require explicit rescheduling, which this demand-triggered path does not establish.
Course limitation: lessons 39–44 build a bounded recent-click feed. Initial-history replay is proposed but the later demonstration shows an empty new tab until another click. Timestamp offsets and a capped set of events should not be treated as a lossless accounting system.
Terminology correction: JWT claims can be carried in a signed/MACed token or an encrypted token. A signed token alone does not hide its payload. Cookies describe a storage/transport mechanism, so cookie-based sessions and JWTs are not mutually exclusive categories.
Course boundary: lesson 56 demonstrates publicly reachable webhooks on stage using Stripe sandbox, not real-money live mode. Lesson 59 explicitly leaves plan-limit enforcement as further work. Checkout and synchronized subscription records must be connected to server-side feature and quota checks before they enforce a paid product.
Course boundary: lesson 58 mocks key dependencies to test selected business logic. Those tests do not by themselves verify real D1 migrations, bindings, queue retries, WebSocket authorization, or webhook delivery. Cloudflare's Vitest integration is a primary source for a separate runtime-testing layer.
Course progression: lesson 47 demonstrates Cloudflare Workers Builds with Git integration; configuring the data service is a follow-up exercise. Lesson 48 demonstrates /r/* routing, but 57 returns to go-stage/go subdomains. Choose one URL scheme and apply it consistently to generated links, bindings, and environment variables.
Observed caveat: lessons 10 and 30 describe a createdBefore cursor, but greater-than comparison appears in the narration or screen code. For descending history, verify older-page behavior with fixed timestamps and a tie-breaking key. The summary does not treat the demonstrated pagination as proven correct.
Course sequencing caveat: lesson 56 fixes a Better Auth default-secret warning only late in the recording. When building your own application, configure a suitable secret in each deployed environment before exposing authentication. The successful final demo should not be read as endorsing the earlier temporary setup.
Added implementation review: lesson 52 authenticates the application Worker’s tRPC and socket routes and forwards a verified account identity. It does not prove every detail/update query checks ownership or that a public data-service socket cannot bypass that middleware. Check direct backend reachability and record-level authorization; a trusted header must only come from a trusted caller.
Search across explanations, concepts, and pitfalls. Open one entry for its full notes, or use the focused lesson link for a shorter page.
The course builds Smart Links, a short-link SaaS application whose redirects can vary by country and whose dashboard reports clicks and destination health. Its central lesson is how to divide a full-stack product into services with different responsibilities, then connect Cloudflare compute and storage products. React and the other libraries provide the working example; this is a systems course rather than a beginner framework tutorial.
Primary source: course video 01 · Supplied English subtitles · 00:20:15.
Why does this project have two applications and a shared package?
The apps separate user-facing CRUD/authentication from redirects and background processing; the package lets both reuse the same data definitions and queries.
Draw three boxes for the user application, data service, and Data Ops. Place link editing, public redirecting, and database query definitions in their appropriate boxes.
You can explain each responsibility and show that shared code is imported into deployable apps rather than called as another network service.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Cloudflare Workers runtime APIs. For recorded API names, commands, limits, and prices, check the version you use.
The starter is a pnpm monorepo containing two applications and one reusable package. The lesson gets the existing interface running, establishing the build order and the relationship between root convenience scripts and scripts inside each workspace package. The visible dashboard is still mostly a scaffold with dummy data, so a working page does not yet mean the backend features exist.
Primary source: course video 02 · Supplied English subtitles · 00:07:31.
Why build Data Ops before starting an application that imports it?
The application consumes the package’s exported build output; the build creates the JavaScript and type files at those export paths.
In a separate course checkout, identify the workspace package names, build the shared package, and start the user application.
The dashboard opens locally, and you can point to the scripts and package that produced it.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Cloudflare Workers runtime APIs. For recorded API names, commands, limits, and prices, check the version you use.
The first deployment turns the working starter into a live Cloudflare Worker application. Wrangler reads the application configuration, builds the project through its deploy script, and uploads both static browser assets and server code. Deploying early makes the hosting process a familiar development step before the product becomes complicated.
Primary source: course video 03 · Supplied English subtitles · 00:05:50.
What two kinds of output are uploaded when this application is deployed?
Static browser assets and the server-side Worker bundle; they serve different parts of the application.
Deploy the starter from your course checkout and trace its deployed name and entrypoint back to the Wrangler file.
The returned URL loads the same starter interface and the matching Worker appears in your account.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Cloudflare Workers runtime APIs. For recorded API names, commands, limits, and prices, check the version you use.
This conceptual lesson explains why Workers use V8 isolates and how that differs from the instructor’s traditional-server and Lambda examples. The provider handles routing requests and making an execution environment available, leaving the application to implement handlers. A second distinction is active CPU work versus elapsed request time: waiting for another service is different from executing code.
Primary source: course video 04 · Supplied English subtitles · 00:11:45.
Why can a one-second request consume much less than one second of CPU time?
It may spend most of that second waiting on database or API I/O rather than actively executing application instructions.
Sketch a request that validates input, waits for an API, parses the response, and returns JSON. Mark which spans represent CPU work.
You distinguish elapsed time from active computation and can explain why isolate startup and application execution are separate concerns.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Cloudflare Workers runtime APIs. For recorded API names, commands, limits, and prices, check the version you use.
A framework becomes runnable on Workers when its build produces static assets and a compatible server entrypoint. The lesson inspects this boundary using a basic fetch handler, Hono, and a Next.js/OpenNext example, then explains how runtime environment bindings differ from copied Node.js configuration patterns. Understanding the build output helps debug both deployment problems and missing secrets.
Primary source: course video 05 · Supplied English subtitles · 00:22:39.
Why can copying a database-client example from Node documentation fail in a Worker project?
The example may assume process.env or initialization timing that differs from the project’s Worker runtime and framework adapter.
Find your course app’s static output, server entrypoint, local secret configuration, and deployed secret configuration.
You can explain when each value or file is used and identify how server-only configuration reaches the request handler.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Cloudflare Workers runtime APIs. For recorded API names, commands, limits, and prices, check the version you use.
Bindings connect a Worker to a Cloudflare resource through its runtime environment. The lesson demonstrates the recurring pattern with KV: create a namespace, declare it in Wrangler, regenerate types, then read and write through the binding. The same discovery process extends to other Cloudflare products, reducing the amount of connection setup repeated in application code.
Primary source: course video 06 · Supplied English subtitles · 00:06:59.
What is the difference between a KV resource ID and its binding name?
The ID selects the namespace in Cloudflare; the binding name is the environment property through which this Worker accesses it.
Reproduce the demonstration with an isolated test KV namespace and explain where the saved ID lives during your chosen development mode.
The read route retrieves the saved value, and you can identify the configuration, generated type, and method call involved.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Cloudflare resource bindings. For recorded API names, commands, limits, and prices, check the version you use.
The user application pairs React with TanStack Router, TanStack Query, and a tRPC backend deployed as a Worker. The lesson traces a dashboard table from its route loader to a query hook and then to the server procedure, showing how these tools divide navigation, server-data state, and typed communication. At this stage, those procedures still return placeholder data.
Primary source: course video 07 · Supplied English subtitles · 00:14:21.
Which tool handles navigation, which handles server-data state, and which supplies the typed backend interface?
TanStack Router handles navigation, TanStack Query handles server-data state, and tRPC connects typed client calls to server procedures.
Trace one dashboard value through its component, query options, route loader, and server procedure without changing the code.
You can point to where the current dummy data originates and where a real database query would be inserted.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: tRPC introduction. For recorded API names, commands, limits, and prices, check the version you use.
The course creates a D1 database and uses Drizzle to represent its tables as TypeScript schemas. Schema and query code lives in Data Ops so both applications can share it, and database initialization is centralized to reduce provider-specific setup scattered through the apps. This lesson uses a database-first workflow: create tables remotely, then introspect them into code.
Primary source: course video 08 · Supplied English subtitles · 00:17:49.
Why is the first schema pull empty, and why does the second contain tables?
The first runs before any tables exist; the second introspects the tables just created in D1.
Create the course’s three tables in a dedicated study database and explain what event or action writes to each one.
The generated schemas match the database tables, and you can distinguish link configuration, click history, and evaluation results.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Drizzle with Cloudflare D1. For recorded API names, commands, limits, and prices, check the version you use.
This lesson implements the first real end-to-end write: submitting a link form creates a database row and returns its generated short-link ID. A validated tRPC mutation calls a reusable Data Ops query, which gets the initialized Drizzle database and inserts the row. The debugging sequence makes the difference between package exports, runtime initialization, resource bindings, and local versus remote data concrete.
Primary source: course video 09 · Supplied English subtitles · 00:22:23.
Why can a D1 query still fail after its binding has been declared?
The shared Drizzle accessor may not be initialized, or development may be using a separate local database whose tables were never created.
Create a link and follow its ID from form submission to the database row and the page URL.
The stored destination and name match the form, and the final page URL contains the ID actually returned by the database operation.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Drizzle with Cloudflare D1. For recorded API names, commands, limits, and prices, check the version you use.
The remaining demonstrated link-management operations replace placeholder results with real shared queries. The application lists an account’s links, loads one link, updates its name, and changes its default and country-specific destinations. TanStack Query invalidation refreshes the affected server data after a successful mutation, keeping the UI synchronized with the database.
Primary source: course video 10 · Supplied English subtitles · 00:24:54.
Why does a new get-link request appear immediately after the destination update succeeds?
The success handler invalidates that query’s cached data, causing the displayed server data to be fetched again.
Change a name, add a country override, and disable geo-routing while inspecting network requests and database state.
The name persists, the override appears then is removed, the default remains, and you can explain the refresh request after each affected mutation.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: tRPC introduction. For recorded API names, commands, limits, and prices, check the version you use.
This short checkpoint deploys the now data-backed user application and verifies its link operations against D1. The instructor demonstrates reading a build error rather than postponing deployment until the entire course is finished. Continuous deployment checkpoints help isolate problems to a small set of recent changes.
Primary source: course video 11 · Supplied English subtitles · 00:04:28.
What does deploying at this checkpoint validate beyond seeing the local page work?
It validates the application build, deployment configuration, hosted D1 binding, and actual link operations in the Cloudflare environment.
Deploy your current course application and perform one persistent edit through the hosted interface.
The deployment succeeds, the expected D1 binding appears, and the edit survives a full reload.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Drizzle with Cloudflare D1. For recorded API names, commands, limits, and prices, check the version you use.
The course now moves from the dashboard’s lightweight backend to the separate data service. Its first responsibility is receiving a short-link ID and redirecting the visitor to a default or country-specific destination. The lesson starts with a minimal WorkerEntrypoint class, explaining event handlers and deploying a hello-world response before adding routing complexity.
Primary source: course video 12 · Supplied English subtitles · 00:07:20.
Why establish a working hello-world deployment before adding the redirect logic?
It confirms the data service’s entrypoint and deployment setup independently, making later failures easier to attribute to the new functionality.
Run and deploy the data service, then name one responsibility that belongs here and one that stays in the user application.
Both local and hosted URLs respond, and you assign public redirecting to the data service and link editing to the user application.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Cloudflare resource bindings. For recorded API names, commands, limits, and prices, check the version you use.
Hono adds a small routing layer inside the data-service Worker so the application can define paths without manually inspecting each URL. The Worker remains the entrypoint and forwards the request, environment, and execution context to the Hono app. A dynamic ID route initially returns JSON, establishing the seam where real short-link logic will be added.
Primary source: course video 13 · Supplied English subtitles · 00:08:26.
Why must the Worker forward more than the request to Hono?
The routes also need the runtime environment for bindings and the execution context for Cloudflare-specific request-lifecycle capabilities.
Add the Hono ID route and inspect responses for / and /sample-link in your local data service.
The ID route returns JSON, the homepage is unmatched, and you can trace the same request through the Worker and Hono layers.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Hono on Cloudflare Workers. For recorded API names, commands, limits, and prices, check the version you use.
The lesson inspects the request information available for geo-routing. Hono wraps the original Request with convenience methods but preserves it under its raw property; the Cloudflare-specific cf object is accessed there. The implementation extracts country, latitude, and longitude so subsequent lessons can use country for routing and coordinates for click analytics.
Primary source: course video 14 · Supplied English subtitles · 00:05:50.
Where does this implementation obtain the country used for routing?
From the Cloudflare-specific cf metadata on Hono’s raw incoming Request, rather than from a country supplied in the short-link URL.
Inspect a development request and identify its country and coordinate values, including any missing values.
You can distinguish Hono’s request wrapper, the raw Request, ordinary headers, and Cloudflare metadata without treating them as interchangeable.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Cloudflare Request API. For recorded API names, commands, limits, and prices, check the version you use.
The data service reuses the existing Data Ops get-link query to read the same configuration created through the dashboard. The lesson connects that reusable code to this Worker’s own D1 binding and initializes the shared database accessor in the WorkerEntrypoint constructor. It also demonstrates how a missing await can hide the real error by returning before the asynchronous query finishes.
Primary source: course video 15 · Supplied English subtitles · 00:08:08.
Why did importing a working query from the dashboard package not make it immediately work in the data service?
The separate Worker still needed its D1 resource binding and the shared database accessor initialized for its own execution path.
Use a link created through the dashboard to retrieve its configuration through the data-service ID route.
The returned name and destinations match D1, and you can explain the binding and initialization steps that made the shared query work.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Cloudflare resource bindings. For recorded API names, commands, limits, and prices, check the version you use.
This lesson turns the data-service lookup into an actual redirect. It validates the relevant Cloudflare metadata, chooses a country-specific destination when configured, and otherwise chooses the default URL. A small routing helper holds the selection logic while the Hono route coordinates lookup, error handling, and the redirect response.
Primary source: course video 16 · Supplied English subtitles · 00:11:50.
What destination is chosen for a valid link when its country is absent or has no override?
The routing helper chooses the default destination; a failure to parse the entire metadata object follows a separate error path in the demonstrated route.
Predict and test three cases: a configured country, an unconfigured country, and a missing link ID.
The configured country uses its override, the unconfigured country uses the default, and the missing link receives a not-found response.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Hono on Cloudflare Workers. For recorded API names, commands, limits, and prices, check the version you use.
The redirect service adds a KV cache to reduce repeated database round trips, especially for visitors far from the demonstrated D1 location. It first looks up the link ID in KV, validates cached JSON, and falls back to D1 on a miss or invalid cached value. A successful database lookup populates KV with a 24-hour expiration before returning the same link shape used by the routing helper.
Primary source: course video 17 · Supplied English subtitles · 00:12:06.
After editing a link in D1, why might the redirect still use its previous destination?
The routing service can continue using a cached copy until it is invalidated, replaced, or expires; KV visibility is also eventually consistent.
Diagram the cache hit, cache miss with a database record, and missing-link paths, then inspect logging for one repeated link request.
You can explain which paths call D1, when KV is populated, and why freshness needs an explicit policy.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: How Workers KV works. For recorded API names, commands, limits, and prices, check the version you use.
The completed redirect becomes the event source for the rest of the product. Instead of expanding the request handler with analytics, realtime updates, and AI processing, the course proposes recording a click event on a queue and letting later processing react to it. This transition explains why the next sections introduce Queues, Durable Objects, and Workflows.
Primary source: course video 18 · Supplied English subtitles · 00:03:08.
Why make a click event feed several backend features instead of performing all of them in the redirect route?
The route can stay focused on getting the visitor to the destination while downstream processing independently persists, broadcasts, and evaluates the event.
Draw a click event flowing from the redirect route into a queue and then to analytics storage, a realtime update, and a health workflow.
You can name the event fields each downstream feature needs and distinguish implemented redirect behavior from the upcoming processing design.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Hono on Cloudflare Workers. For recorded API names, commands, limits, and prices, check the version you use.
The course introduces a queue as a handoff between the user-facing request and background processing. A producer records an event, and a consumer processes it separately, allowing the redirect service to stay responsive while the application builds analytics and other features. Queues also give failed work a defined retry and recovery path instead of tying every operation to the lifetime of an HTTP connection.
Primary source: course video 19 · Supplied English subtitles · 00:05:36.
Why use a queue for link-click analytics when redirecting a visitor?
The redirect can complete quickly while a separate consumer processes the click; failures in downstream processing have a retry path.
Draw the path for one successful click and one click whose analytics handler temporarily fails. Label where the visitor receives a response.
Your diagram distinguishes the HTTP response from background completion and shows the failed message returning for another attempt.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Queues delivery guarantees. For recorded API names, commands, limits, and prices, check the version you use.
This lesson explains the account upgrade used in the recording and separates the base subscription from usage-based charges. Its durable teaching point is to estimate costs from both request volume and CPU work, then improve those estimates with real measurements. The specific prices, limits, and requirement to upgrade for Queues describe the recording and require a current documentation check before following them.
Primary source: course video 20 · Supplied English subtitles · 00:04:45.
Why can two applications with the same request count have different compute costs?
The amount of CPU work performed per request can differ, and the application may also use different separately billed products.
Create a small cost-estimate worksheet in your notes with placeholders for requests, average CPU time, and downstream product usage. Mark every recorded number as historical.
You can explain the inputs you need to measure and distinguish a course example from a current price.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Queues pricing. For recorded API names, commands, limits, and prices, check the version you use.
The instructor creates a staging queue, configures the data-service Worker as its consumer, and implements a queue handler that logs message bodies. Sending test messages in the dashboard makes batching visible: one handler invocation can contain several messages. Pausing and resuming delivery then demonstrates that accepting messages and delivering them to a consumer are separate operations.
Primary source: course video 21 · Supplied English subtitles · 00:08:50.
What is the difference between a message and a batch in this lesson?
A message contains one event body; a batch groups several messages delivered together to one queue-handler invocation.
Using a test queue, send several distinguishable messages while delivery is paused, then resume it and compare invocation logs with individual message logs.
You can identify both the batch-level trigger and each message processed within it, and explain why the message count need not equal the invocation count.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Queues delivery guarantees. For recorded API names, commands, limits, and prices, check the version you use.
The redirect route becomes a queue producer: it packages each click with the destination and location context, then sends that event for later processing. The course uses the execution context’s waitUntil facility so waiting for the send does not delay the visitor’s redirect. This completes the connection between the fast HTTP path and the queue consumer built in the previous lesson.
Primary source: course video 22 · Supplied English subtitles · 00:09:16.
At what point has a click become a durable queued event?
After the queue has accepted the send; returning the redirect or starting a waitUntil promise is not itself that acknowledgement.
Trace each payload field back to its source: link lookup, selected destination, request location, or generated timestamp.
You can explain why the consumer has enough context to process a click without repeating the redirect request.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Queues delivery guarantees. For recorded API names, commands, limits, and prices, check the version you use.
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.
Why validate messages if the producer already uses a TypeScript type?
Types are development-time checks; the actual queue payload can still be malformed or come from a different producer or version.
Describe a second event type that could use the same queue. Specify its type label, required fields, and dedicated handler responsibility.
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.
Companion primary documentation: Queues delivery guarantees. For recorded API names, commands, limits, and prices, check the version you use.
This lesson extends queue operation with delayed delivery, retry configuration, and a dead-letter recovery path. The instructor deliberately breaks the consumer, observes failed events arriving in a paused dead-letter queue, restores the handler, and resumes delivery to recover the records into D1. It also distinguishes code organisation from deployment topology: producer and consumer may share one Worker or live in separate services.
Primary source: course video 24 · Supplied English subtitles · 00:13:04.
Why fix the consumer before resuming a paused dead-letter queue?
Resuming sends those failed events back to processing; if the original defect remains, recovery will fail again and may exhaust the new retry policy.
Write a five-step recovery checklist for a temporary database outage, from detecting dead-letter messages to confirming their records were saved.
The checklist includes investigation, a verified fix, controlled replay, outcome checks, and duplicate-handling considerations.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Queues delivery guarantees. For recorded API names, commands, limits, and prices, check the version you use.
The next feature evaluates destination pages: render their content, ask AI whether the product remains available, and preserve evidence. Cloudflare Workflows supplies named steps with persisted progress and configurable retry behaviour, making the process easier to manage than a long HTTP request. The lesson explains the intended architecture before implementation and contrasts it with much heavier data-processing orchestration.
Primary source: course video 25 · Supplied English subtitles · 00:07:27.
Why give browser rendering and AI inference different retry policies?
They have different failure modes and costs; retrying an expensive inference repeatedly may waste money even when retrying a transient rendering failure is useful.
Sketch three or four named steps for checking a product page, and write the output needed by the following step.
Each step has a clear responsibility and a reason for the data it passes onward; the AI input comes from rendered evidence.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Workflows Workers API. For recorded API names, commands, limits, and prices, check the version you use.
The instructor creates and deploys the first destination-evaluation workflow with one named step returning dummy data. The class, entrypoint export, Wrangler binding, resource name, and class name are connected so Cloudflare can discover and execute it. A manual dashboard trigger then confirms the wiring before real browser and AI work are introduced.
Primary source: course video 26 · Supplied English subtitles · 00:09:15.
Follow the final workflow correction in lesson 34 when combining these steps.
What is the difference between a workflow definition and an instance?
The definition is the deployed class and its steps; an instance is one execution of that definition with its own identity, inputs, and progress.
Change the dummy step to return a small diagnostic object describing the input URL, then trigger two distinct test instances.
You can locate each instance separately and connect its visible output to the parameters supplied for that execution.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Workflows Workers API. For recorded API names, commands, limits, and prices, check the version you use.
The dummy collection step becomes a real Browser Rendering operation using Cloudflare’s Puppeteer integration. The workflow opens the destination, waits for network activity to settle, and extracts visible body text, HTML, and the response status for later analysis. The instructor then moves this logic into a helper and explicitly closes the browser to release the session.
Primary source: course video 27 · Supplied English subtitles · 00:14:50.
Follow the final workflow correction in lesson 34 when combining these steps.
Why preserve both body text and HTML rather than feed the whole HTML directly to AI?
Text gives the model the content it needs with less markup, while HTML provides richer evidence for later debugging.
Compare a simple static page with a page that fills content after loading. Record what the rendered text contains and what readiness condition you used.
You can explain whether the collected input actually includes the content needed for a page-health decision.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Workflows Workers API. For recorded API names, commands, limits, and prices, check the version you use.
This lesson introduces Workers AI as the model service and the AI SDK as a common interface for calling providers. The key design choice is structured output: instead of interpreting a free-form paragraph, application code receives named fields whose shape is described by a schema. The forthcoming destination checker will use that approach to turn scraped content into a status the rest of the application can consume.
Primary source: course video 28 · Supplied English subtitles · 00:06:46.
Follow the final workflow correction in lesson 34 when combining these steps.
What problem does a response schema solve, and what does it leave unsolved?
It makes the output shape usable by application code; it does not ensure the model understood the page or chose the correct status.
Define a small destination-check result with a status and a reason. Explain which values should be allowed when the evidence is incomplete.
Your design represents uncertainty explicitly and does not require fragile string searching through a paragraph.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Workflows Workers API. For recorded API names, commands, limits, and prices, check the version you use.
The course implements an AI destination-checking helper with a Zod output schema, the Workers AI provider, and the AI SDK’s recorded generateObject API. The helper receives extracted page text and returns an availability status plus a concise reason, and a new workflow step calls it with a restrained retry policy. Testing reveals an important limitation: a more detailed prompt still produces an unknown result when the collected page content is incomplete or unexpected.
Primary source: course video 29 · Supplied English subtitles · 00:21:52.
Follow the final workflow correction in lesson 34 when combining these steps.
Why is the unknown result useful evidence rather than simply a failed prompt?
It can indicate that the model was given missing or different page content; the pipeline must inspect its input before blaming the model.
Write three short page-text samples: clearly available, clearly unavailable, and missing product information. State the expected status and supporting phrase for each.
Your expected results distinguish uncertainty from unavailability and can be used as a small repeatable evaluation set.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Workflows Workers API. For recorded API names, commands, limits, and prices, check the version you use.
This lesson connects the AI classification to persistent application data. Sampled video frames show a database-save workflow step, shared evaluation queries, and a fix that initializes the database inside the workflow entrypoint. The final D1 Studio frame shows an evaluation saved with UNKNOWN_STATUS, preserving uncertainty instead of silently treating it as an available product. This summary covers visible implementation; the narration was unavailable.
Primary source: course video 30 · Sampled video frames; narration unavailable · 00:09:20.
Follow the final workflow correction in lesson 34 when combining these steps.
Why might the workflow fail to save when the ordinary Worker already initializes the database?
The workflow has its own entrypoint and execution path. Its database helper must be initialized with the binding available to that path; initialization in another entrypoint cannot be assumed.
Sketch the fields in a saved evaluation and mark which come from the workflow payload and which come from the AI result. Add where database initialization occurs.
Link/account/destination identifiers come from the payload, status/reason come from the model result, and the workflow initializes its database access before querying.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Drizzle with Cloudflare D1. For recorded API names, commands, limits, and prices, check the version you use.
The workflow backs up rendered page evidence to R2 and links it to the evaluation saved in D1. The lesson explains why relational records belong in a database while larger documents and images fit object storage, then uses a shared evaluation ID to connect those two kinds of data. Inspecting the stored AliExpress text confirms that the renderer did not collect the expected product information, giving a concrete reason to improve observability.
Primary source: course video 31 · Supplied English subtitles · 00:15:36.
Follow the final workflow correction in lesson 34 when combining these steps.
How can a database query lead to the exact evidence objects for an evaluation?
The evaluation’s ID and account identify the object-key pattern, so query results provide the information needed to retrieve those objects.
Design key names for one evaluation’s HTML, text, and screenshot, then write the minimum database fields needed to locate them.
All three objects are unambiguously associated with the same evaluation and can be located without scanning their contents.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Workflows Workers API. For recorded API names, commands, limits, and prices, check the version you use.
The application’s evaluation screens are connected to real backend records instead of placeholder arrays. Two shared DataOps queries supply problematic destinations and recent evaluations through tRPC, filtered by the account context. The debugging sequence shows that an empty UI can be correct when the selected account differs from the account attached to the stored evaluation.
Primary source: course video 32 · Supplied English subtitles · 00:05:45.
Follow the final workflow correction in lesson 34 when combining these steps.
Why could D1 contain evaluations while the application displays none?
The route filters by account, and the demonstration’s stored test account initially did not match the application’s temporary account value.
Write a troubleshooting sequence for an empty evaluations screen. Include a query with the exact account ID being used by the route.
You can separate a valid empty result from a broken connection and identify whether the stored account matches the requested account.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Workflows Workers API. For recorded API names, commands, limits, and prices, check the version you use.
This update adds screenshots to the rendering evidence so the instructor can inspect what the remote browser actually saw. The browser helper returns an encoded screenshot, and the R2 backup step converts it into image bytes and stores it beside the HTML and text. The resulting image shows an error page, explaining why the AI could not infer the product’s availability from the collected content.
Primary source: course video 33 · Supplied English subtitles · 00:03:29.
Follow the final workflow correction in lesson 34 when combining these steps.
What did the screenshot explain that the unknown AI status could not explain by itself?
It showed that the rendering session saw an error page, so the expected product evidence was absent before the model was called.
For an unexpected classification, write the evidence you would inspect in order: rendered screenshot, collected text, response status, prompt, and model output.
Your investigation can identify whether the problem began during collection or interpretation instead of treating every unknown status as a model defect.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Workflows Workers API. For recorded API names, commands, limits, and prices, check the version you use.
This corrective lesson fixes workflow failures caused by oversized persisted step output, especially after screenshots were added. The first step now creates the evaluation ID, renders the page, and writes bulky evidence directly to R2, returning only the text needed for AI and that ID. The AI step remains, and the final database save accepts the already-created ID rather than generating its own.
Primary source: course video 34 · Supplied English subtitles · 00:02:52.
Why does moving the R2 upload into the first step fix the screenshot-related failure?
The large screenshot no longer has to be returned and persisted as that step’s output; it is stored in R2 before the checkpoint.
Redraw the final workflow after this patch and annotate which data is stored in R2 versus returned between steps.
Your diagram shows collection plus backup first, AI second, database save last, with a shared ID and no large image crossing a step boundary.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Workflows limits. For recorded API names, commands, limits, and prices, check the version you use.
The course introduces Durable Objects to decide when expensive destination-evaluation workflows should run. Instead of launching a workflow for every click, a stateful coordinator groups relevant clicks and schedules later work with an alarm. This places the scheduling and future subscription rules between the queue consumer and the evaluation workflow while keeping the redirect path fast.
Primary source: course video 35 · Supplied English subtitles · 00:07:58.
What responsibility belongs to the Durable Object here, and what remains in the workflow?
The Durable Object decides when to start an evaluation using stored context and an alarm; the workflow performs the rendering, AI analysis, and persistence.
For 500 clicks to the same link and destination, describe the state and alarm you need to run one evaluation after a chosen delay.
Your design keeps scheduling independent from evaluation execution and explains why the other 499 clicks do not require new workflows.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: What are Durable Objects?. For recorded API names, commands, limits, and prices, check the version you use.
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.
What must happen when a Durable Object wakes up if its last click context only existed in memory?
That context cannot be recovered; it needed to be stored persistently and then loaded during reinitialisation.
Trace a counter through initialise, increment, write, shutdown, restart, and read. Write down both its memory and stored values after each event.
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.
Companion primary documentation: What are Durable Objects?. For recorded API names, commands, limits, and prices, check the version you use.
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.
Why do test-one and test-two keep separate counts even though they use the same class?
The namespace resolves their different names to different object instances, and each instance owns its own state.
Reproduce the two-name counter experiment, then stop and restart the local service without deleting its persistent state and check the counts again.
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.
Companion primary documentation: What are Durable Objects?. For recorded API names, commands, limits, and prices, check the version you use.
The persistent counter becomes a working evaluation scheduler integrated with the link-click consumer. Each object stores click context, schedules an alarm only when no alarm is pending, and starts the destination workflow when that alarm fires. The demonstration uses ten seconds to verify the full pipeline and then changes the interval to twenty-four hours so repeated clicks share one scheduled evaluation.
Primary source: course video 38 · Supplied English subtitles · 00:23:25.
Follow the final workflow correction in lesson 34 when combining these steps.
If a destination receives no further clicks after an evaluation, will this scheduler automatically evaluate it again tomorrow?
No. The implementation schedules from incoming clicks when no alarm is pending; it does not show the alarm scheduling its own next run.
Trace clicks at minute zero, minute five, and after the first alarm has fired. State how many pending alarms and workflow launches exist at each point.
Your trace shows one shared pending alarm before the first firing and a new delayed run only after another click arrives.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: What are Durable Objects?. For recorded API names, commands, limits, and prices, check the version you use.
This section designs a live map of link clicks using one Durable Object per account. The redirect service keeps its existing queue path for background processing, while also sending geographic click data directly to the object so map updates avoid queue delay. Each object combines a small SQLite history with connected WebSocket clients, allowing one incoming click to be broadcast to several viewers.
Primary source: course video 39 · Supplied English subtitles · 00:06:21.
Why retain both the queue and a direct Durable Object call?
The queue supports existing background processing, while the direct call lets the live map receive updates without waiting for queue consumption.
Draw the path of one click and one newly connected viewer, labeling storage and live delivery separately.
Your drawing includes the redirect, queue, account-scoped object, SQLite table, and all connected viewers.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Durable Objects WebSockets. For recorded API names, commands, limits, and prices, check the version you use.
The tracker becomes a SQLite-backed Durable Object with a small geographic click table and an insertion method. A temporary HTTP endpoint reads the table so storage can be verified before WebSockets are introduced. The redirect’s background helper now enqueues the original analytics event and then writes usable geographic data to the correct account object.
Primary source: course video 40 · Supplied English subtitles · 00:16:36.
What determines whether two clicks share the same tracker database?
They share it when their links belong to the same account and therefore resolve to the same Durable Object identity.
Explain how you would test account isolation using the temporary endpoint.
You predict that clicks for account A appear under A’s endpoint while another account’s object remains separate.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: What are Durable Objects?. For recorded API names, commands, limits, and prices, check the version you use.
This lesson replaces the tracker’s temporary JSON response with a WebSocket handshake. It introduces the object’s message, close, and error handlers, then explains how one connection can receive a response or how all connected clients can receive a broadcast. The surrounding Hono route forwards the incoming request to the selected account object.
Primary source: course video 41 · Supplied English subtitles · 00:08:50.
Which end of a WebSocketPair remains associated with the Durable Object?
The server end is accepted by the object; the client end is returned to establish the browser’s connection.
Trace an incoming message through an echo implementation and then through a broadcast implementation.
You distinguish sending to the originating socket from iterating over every accepted socket.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Durable Objects WebSockets. For recorded API names, commands, limits, and prices, check the version you use.
The frontend hook is connected to the locally running data service to verify the WebSocket handshake before adding richer server behavior. Incoming messages feed the shared geographic click store, whose state drives the map. The lesson then explains the intended architecture: browsers connect through the user application’s Worker, where authentication will happen, and that Worker proxies to the data service.
Primary source: course video 42 · Supplied English subtitles · 00:09:07.
Why place the socket proxy in the user application’s Worker?
That server can validate the user and choose authorized account data before forwarding the connection to the data service.
Write a three-observation checklist for a successful local socket connection.
Your checklist includes connected UI state, a persistent pending socket request, and a server close event after closing the tab.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Durable Objects WebSockets. For recorded API names, commands, limits, and prices, check the version you use.
The tracker now uses an alarm to batch clicks before broadcasting them to connected browsers. Each new click is stored, and if no alarm exists one is scheduled roughly two seconds ahead; the alarm queries a bounded recent set, sends it, advances offsets, and removes older rows. The instructor verifies the full redirect-to-map flow using local clicks, a Malaysia VPN location, and a phone.
Primary source: course video 43 · Supplied English subtitles · 00:17:32.
Why send the batch before performing cleanup?
The lesson prioritizes getting the selected clicks to viewers promptly, then updates offsets and trims retained history.
Walk through a burst of 200 clicks with a 50-record query limit and explain the map’s purpose.
You describe bounded visualization and identify the separate queue path instead of claiming all 200 clicks must appear individually.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Durable Objects WebSockets. For recorded API names, commands, limits, and prices, check the version you use.
The frontend’s Worker receives a service binding to the data service and becomes the browser’s WebSocket entry point. A small Hono application handles both tRPC routing and the socket proxy, adding an account header before forwarding the request through the binding. Local and deployed checks confirm that one click reaches multiple open dashboard tabs.
Primary source: course video 44 · Supplied English subtitles · 00:10:49.
What changes in the browser when the service binding is introduced?
It targets the user application’s host instead of hardcoding the data service host; the Worker performs the forwarding.
Describe the request route from a dashboard tab to the account tracker, identifying where authentication will be added.
Your route is browser → user-application Worker → bound data service → account Durable Object, with authentication at the user-application Worker.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Workers remote procedure calls. For recorded API names, commands, limits, and prices, check the version you use.
The existing deployment is reorganized into an explicitly named stage environment, preparing for a separate production copy. Resource bindings move under the stage section of each Wrangler configuration, and deployment and type-generation commands must select that environment. The lesson exposes practical migration issues: Worker names change, queue consumers conflict, Vite selects environments differently, and service bindings must follow the renamed backend.
Primary source: course video 45 · Supplied English subtitles · 00:10:44.
Why does renaming the backend deployment require a frontend configuration change?
Its service binding targets the deployed service name, which now includes the stage suffix.
List the names and settings that must agree for a stage frontend to reach its stage backend.
You identify the selected environment, deployed backend name, service binding target, and browser base host.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Wrangler environments. For recorded API names, commands, limits, and prices, check the version you use.
A production environment is created with its own storage and messaging resources, mirroring stage without sharing application data. The backend is deployed first, followed by a production-specific Vite build of the user application. A failed dashboard then reveals a separate requirement: provisioning a database does not create the application tables.
Primary source: course video 46 · Supplied English subtitles · 00:08:47.
Why can the production Worker deploy successfully while the dashboard fails?
The Worker exists and runs, but queries fail until its separate production database has the expected schema.
Make a production-readiness checklist from this lesson’s resource and schema steps.
It distinguishes creating resources, connecting bindings, building the correct frontend, and creating database tables.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Wrangler environments. For recorded API names, commands, limits, and prices, check the version you use.
Cloudflare’s repository-connected builds automate the user application’s stage and production deployments. A push to the stage branch triggers its stage command, and merging stage into main triggers production. The monorepo build must install dependencies, build the shared data package, and then deploy the selected application; the lesson uses build failures to uncover missing dependencies and missing build-time variables.
Primary source: course video 47 · Supplied English subtitles · 00:15:50.
Why did a locally successful build fail when tsc was unavailable in Cloudflare?
The local machine supplied TypeScript globally, while the clean build needed it declared and installed as a project dependency.
Explain the full command chain for a production frontend deployment from the monorepo root.
You include installation, shared-package build, application filtering, production build, and deployment.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Wrangler environments. For recorded API names, commands, limits, and prices, check the version you use.
The application receives its own domain, first through whole-host custom domains and then through path-based Worker routes. Separate production and stage hosts are configured, and the frontend’s socket host must be updated to match them. For short links, the final demonstrated design reserves an /r/ path prefix so requests can reach the data service without swallowing frontend routes.
Primary source: course video 48 · Supplied English subtitles · 00:15:29.
Why introduce /r/ before every short-link identifier?
It gives the routing configuration an unambiguous pattern for sending short links to the data service while leaving other application paths with the frontend.
Assign /app, /api/auth, and /r/example to the appropriate service in the final design.
You place application and authentication paths with the user-application Worker and /r/example with the redirect data service.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Wrangler environments. For recorded API names, commands, limits, and prices, check the version you use.
This overview separates authentication UI, server verification, sessions, and reusable middleware. Better Auth is chosen as an application-integrated library that supplies provider handling, client hooks, and schema generation while keeping authentication data in the project’s database. Its plugin model is introduced as the bridge to organizations, API keys, and the subscription integration developed later.
Primary source: course video 49 · Supplied English subtitles · 00:13:00.
Why is hiding a dashboard with a frontend hook insufficient protection?
A caller can reach the server directly, so protected server requests still need authentication and authorization checks.
Draw a sign-in sequence and label which responsibilities belong to the provider, Better Auth server, database, and frontend hook.
Your explanation places identity verification and session validation on the server side, with UI state reflecting the result.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: RFC 7519: JSON Web Token. For recorded API names, commands, limits, and prices, check the version you use.
Better Auth configuration is connected to the existing Drizzle workflow so authentication tables can be generated and then created in D1. A shared factory supports both schema generation, where provider credentials are unnecessary, and runtime initialization, where they are required. The generated authentication schema is also registered with the runtime Drizzle adapter, and package exports are repaired after TypeScript’s output layout changes.
Primary source: course video 50 · Supplied English subtitles · 00:15:44.
Why share one Better Auth configuration factory between generation and runtime?
It keeps the enabled providers and plugins aligned, while allowing generation placeholders and real runtime dependencies to be supplied differently.
Write the ordered steps required after adding a plugin that needs a new table.
You include configuration, schema generation, SQL generation, applying database changes, and making the runtime adapter aware of the schemas.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Better Auth basic usage. For recorded API names, commands, limits, and prices, check the version you use.
Google social login is wired through the user application’s Hono Worker and Better Auth’s React client. The lesson configures Google OAuth origins and callback URLs, routes authentication traffic through Worker code, replaces mock frontend authentication, and guards dashboard navigation. It then repeats the necessary provider and runtime-secret configuration for the deployed custom domain.
Primary source: course video 51 · Supplied English subtitles · 00:16:58.
Why can a working login still leave API data unprotected at this stage?
The UI and navigation now know about sessions, but protected API handlers still need server-side session enforcement.
Trace one Google sign-in from button click to the dashboard and identify the two callback destinations involved.
You distinguish Google returning to the auth callback endpoint from Better Auth navigating the signed-in user to /app.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Better Auth basic usage. For recorded API names, commands, limits, and prices, check the version you use.
The server now protects both tRPC calls and WebSocket connections with Hono authentication middleware. Better Auth validates the session from request headers, and the middleware stores the authenticated user ID in typed request context. That identity replaces hardcoded account values in the socket proxy and tRPC context, so each user sees their own data.
Primary source: course video 52 · Supplied English subtitles · 00:08:42.
Why should the socket’s account header come from middleware rather than browser input?
Middleware derives it from a validated session, preventing the browser from simply selecting another account’s tracker.
Explain the expected result for a signed-out API request and a signed-in request from a different user than the demo account.
The first is rejected; the second proceeds with its own identity and does not inherit the hardcoded demo account’s data.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Better Auth basic usage. For recorded API names, commands, limits, and prices, check the version you use.
The Better Auth Stripe plugin is added to the shared authentication configuration, first to create Stripe customers and then to support subscriptions. Each configuration change is used to regenerate the authentication schema and produce the corresponding database alteration. The lesson also separates generation-time Stripe setup from runtime configuration so the deployed application can receive its own key and webhook settings.
Primary source: course video 53 · Supplied English subtitles · 00:15:57.
Why does adding the Stripe plugin require database work?
The plugin needs persistent customer and subscription state, so its configuration introduces columns and tables the database must actually contain.
Compare the schema changes caused by enabling customer creation and by enabling subscriptions.
You identify the user’s Stripe customer-ID field for the first and the subscription table for the second.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Better Auth Stripe plugin. For recorded API names, commands, limits, and prices, check the version you use.
The application’s authentication initialization is updated to accept Stripe configuration, and Node compatibility is enabled after a dependency fails on a Node utility import. A new sign-in verifies automatic Stripe customer creation. The instructor then creates three sandbox subscription products and maps their recurring price IDs to named plans in Better Auth.
Primary source: course video 54 · Supplied English subtitles · 00:11:44.
Which Stripe identifier should the backend plan configuration use for billing?
It uses the recurring price ID associated with the product, not merely the product’s identity or display name.
Create a paper mapping of application plan name, Stripe product, and recurring price ID for three tiers.
Each plan points to a specific recurring price, and you can explain where its billing amount comes from.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Better Auth Stripe plugin. For recorded API names, commands, limits, and prices, check the version you use.
The frontend gains an upgrade page, subscription status sidebar, and cancellation dialog through Better Auth’s Stripe client plugin. The lesson exercises subscription listing, checkout, upgrades, cancellation, and restoration, while forwarding Stripe webhooks to localhost for state synchronization. Several failures show why the browser, local database, Stripe account, and webhook listener must all agree.
Primary source: course video 55 · Supplied English subtitles · 00:20:36.
Why can Stripe show an upgraded subscription while the application still shows the old plan?
The application relies on webhook processing to update its local subscription records; an incorrect account, endpoint, or signing secret can prevent that update.
Outline a sandbox test covering signup, first purchase, upgrade, cancellation, and restoration.
For each transition you verify both the Stripe state and the application’s stored and displayed subscription state.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Better Auth Stripe plugin. For recorded API names, commands, limits, and prices, check the version you use.
The subscription integration is deployed to the stage application with a publicly reachable Stripe webhook endpoint, while still using sandbox payments. Nonsecret price IDs move into Wrangler variables, and sensitive keys are configured as runtime secrets. The instructor troubleshoots endpoint typos and the mistaken use of a webhook endpoint ID, then fixes a missing Better Auth application secret discovered in logs.
Primary source: course video 56 · Supplied English subtitles · 00:16:25.
What is the difference between a webhook endpoint ID and its signing secret?
The ID identifies the configured endpoint; its signing secret is the value used to verify webhook signatures and is what the integration requires.
Create a diagnosis sequence for a paid-plan change that is absent from the dashboard.
You check Stripe event delivery, exact endpoint URL, response error, signing secret, and resulting local subscription state.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Stripe webhooks. For recorded API names, commands, limits, and prices, check the version you use.
The dashboard’s placeholder statistics are replaced with account-filtered database queries exposed through existing tRPC routes. The queries calculate recently active links, click counts over several windows, and country breakdowns. The final UI cleanup supplies the frontend build variable used to construct clickable short-link URLs.
Primary source: course video 57 · Supplied English subtitles · 00:09:19.
Why must analytics queries use the user ID from tRPC context?
That context contains the authenticated identity, allowing results to be restricted to the requesting user’s account.
Define expected dashboard results for two users whose links receive different clicks in the last hour.
Your expected counts, active links, and country breakdowns remain separated by account.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Cloudflare Workers Vitest integration. For recorded API names, commands, limits, and prices, check the version you use.
The testing section demonstrates unit tests around business logic, using mocks to isolate database calls, workflow scheduling, and Durable Object dependencies. Queue-handler tests check forwarded data, operation order, and error behavior. Tracker tests cover alarm creation, avoiding duplicate alarms, broadcasting a batch to multiple clients, advancing offsets, and deleting older clicks.
Primary source: course video 58 · Supplied English subtitles · 00:14:52.
What can a mocked tracker test prove, and what can it not prove?
It can check the application’s decisions and calls for controlled inputs; it cannot prove that the real Cloudflare runtime behaves exactly like those mocks.
Design one meaningful failure-path test for the tracker or queue handler and state the behavior it protects.
Your test links a realistic failure to an explicit business requirement, rather than merely repeating the implementation’s call sequence.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Cloudflare Workers Vitest integration. For recorded API names, commands, limits, and prices, check the version you use.
The final lesson turns the completed tutorial into a set of independent extension projects. Its central gap is that subscription plans currently accept payment without enforcing different feature allowances. The instructor proposes notifications, custom links and domains, thoughtful deletion behavior, smarter evaluations and scheduling, and an administration interface that can inspect AI quality.
Primary source: course video 59 · Supplied English subtitles · 00:10:27.
Which missing feature most directly connects billing to actual product behavior?
Backend enforcement of plan entitlements and usage limits, because the existing plans currently collect payment without changing allowed features.
Choose one stretch goal and write a small design with a trigger, affected data, success case, and failure case.
You can explain the extension without replaying a tutorial and identify how you will demonstrate that it works.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Companion primary documentation: Cloudflare Workers Vitest integration. For recorded API names, commands, limits, and prices, check the version you use.
All 59 MP4 files were inventoried from the supplied course library. All 58 available English VTT transcripts were read in full by three subagents; the parent assembled and reviewed the study pack. Course video 30 has no VTT, so 28 frames were sampled and screen code was checked visually. That lesson remains partial with respect to narration. Other summaries follow narration and may omit silent on-screen code details. Timestamp references identify moments to revisit in the original course videos.
These are original summaries and added exercises. The original videos are not hosted here. To rewatch a section, open the matching numbered video in your course library and seek to the displayed time.
Full Markdown summary · Coverage and source index
Checked 13 September 2026. These sources support the correction notes and further reading; they do not replace the supplied course as the source for lesson summaries. Some documentation changes independently of the recorded dependency versions.
Optional practitioner community: Cloudflare Developers Discord, linked by Cloudflare’s official Workers documentation. Bring a small reproduction or an architecture question once you have tried the relevant exercise.