Lesson 44: Serverless with Cloudflare Workers

44.1 Serverless

The sign-up server runs on your computer, so it's only available while your computer is on, and only to you. To let every club member sign up from their phone, it has to run somewhere that's always on and reachable from the internet.

One way is to rent a server and keep it running. Another is serverless: you give your code to a company, and it runs the code whenever a request arrives, on computers you never see or manage. Cloudflare Workers is a serverless platform with a free plan, and it's where the club's website already lives, since Lesson 24. Publishing a Site for Free. Its database, D1, is SQLite, so the SQL from Lesson 43. Storing Data carries over almost unchanged.

A Worker is simpler than an Express server in one way: there's no app.listen, because Cloudflare does the listening. Your code is a function that receives a request and returns a response:

export default {
  async fetch(request, env) {
    return new Response("Hello from the College Community Garden!")
  }
}

request is a standard Request object, the same kind fetch sends, and the function returns a standard Response, the same kind fetch receives. So everything you learned about requests and responses in Lesson 41. How the Web Works applies directly. env holds the Worker's bindings: connections to other Cloudflare services, such as a D1 database.

44.2 Moving the API

Here's the request, in a new chat with your learner profile from Lesson 43. Storing Data:

The reply stopped in the middle of a function. Long replies sometimes do, when they reach the limit on how much the assistant can write at once. The fix is simple, and works in any assistant:

Read the setup first. Wrangler, Cloudflare's command-line tool, does the work: wrangler login connects it to your account, wrangler d1 create makes a database, a configuration file connects the database to the Worker as the binding DB, and wrangler d1 execute runs SQL files against the database, first a local copy for testing, then the real, remote one. wrangler dev runs the Worker on your own computer, with the local database, and wrangler deploy puts it online. The advice to test locally, then check counts in the real database after deploying, is exactly right.

Two details in the setup are dated: the configuration file. New Cloudflare projects now usually use wrangler.jsonc, the same settings in JSON, and the compatibility_date should be a recent date, which the reply mentions. The older wrangler.toml still works.

Then the code. The Worker's fetch handler does its own routing: it splits the address's path into parts, /shifts/6/signups becoming ["shifts", "6", "signups"], and checks the method and parts to decide which function handles the request. Each function is the Express route's logic with D1's methods: env.DB.prepare(sql).bind(values).first() for one row, .all() for many, and .run() for changes, all awaited, because D1 is a service across the network. Instead of res.json(), a small json helper builds a Response with the status and a content-type header.

44.2.1 What was lost in the move

Compare this with the API you designed and built, and several things changed that shouldn't have:

• The member check is gone. The assistant said so: without your original code, it assumed that sign-ups don't require a club member's email. That was a reasonable flag, and it's the wrong assumption. Anyone could sign up with any email.
• spotsFilled became signupCount. The sign-up page from Lesson 42. A Server with Node and Express reads shift.spotsFilled. With the new name, it would show "NaN spots left." Each half works; together they don't, the lesson from Lesson 23. Building a Browser Extension.
• The data never arrives. The reply creates the tables, but never loads the members and shifts into them.

None of this is carelessness. The request said "the routes and rules stay the same," but the assistant, in a new chat, didn't know what the rules were: your request listed some and not others. When you move code to a new platform, give the assistant the whole thing: the old code, or a complete list of every rule. "The same as before" means nothing to a chat that wasn't there before.

44.3 A Public API Needs Protection

The reply's own warning points to the biggest change of all: on your computer, only you could reach the API; on Workers, anyone on the internet can. That changes what's safe:

• Anyone can cancel anyone's sign-up. DELETE /signups/13 needs nothing but a number, and the numbers go 1, 2, 3. Someone could cancel every sign-up in a minute.
• Anyone can sign up anyone, if they know a member's email.

The second is a real limitation, which a login system would fix, and is beyond this book. The first has a simple fix: when someone signs up, give them a cancel code, a long random string that only they receive, and require it to cancel. A number can be guessed; crypto.randomUUID(), built into Workers and Node, makes a string like 3b9f0c7e-5a8d-4e1f-9c2b-7d4e6a1f8b30, which can't be.

44.4 The Club's Worker

Here's the Worker with everything restored and protected: the member check, the original field names, a cancelCode column, and a cancellation that requires it. The configuration file is wrangler.jsonc:

{
  "name": "garden-signups",
  "main": "src/index.js",
  "compatibility_date": "2026-09-01",
  "d1_databases": [
    {
      "binding": "DB",
      "database_name": "garden-signups",
      "database_id": "paste-the-id-from-wrangler-d1-create"
    }
  ]
}

schema.sql creates the tables, with a cancelCode column added:

CREATE TABLE IF NOT EXISTS members (
  email TEXT PRIMARY KEY,
  firstName TEXT NOT NULL,
  lastName TEXT NOT NULL
);
CREATE TABLE IF NOT EXISTS slots (
  id INTEGER PRIMARY KEY,
  date TEXT NOT NULL,
  task TEXT NOT NULL,
  start TEXT NOT NULL,
  end TEXT NOT NULL,
  capacity INTEGER NOT NULL
);
CREATE TABLE IF NOT EXISTS slotSignups (
  id INTEGER PRIMARY KEY,
  slotId INTEGER NOT NULL,
  memberEmail TEXT NOT NULL,
  cancelCode TEXT NOT NULL,
  UNIQUE (slotId, memberEmail)
);

seed.sql loads the club's data, generated from club-data.json. For the sign-ups that already exist, SQLite makes random cancel codes itself, with lower(hex(randomblob(16))). Here are its first lines:

-- the club data at the start of the season
INSERT INTO members (email, firstName, lastName) VALUES ('maya.thompson@example.com', 'Maya', 'Thompson');
INSERT INTO members (email, firstName, lastName) VALUES ('ava.lopez@example.com', 'Ava', 'Lopez');
...
INSERT INTO slots (id, date, task, start, end, capacity) VALUES (1, '2027-06-05', 'watering', '08:00', '09:00', 2);
...
INSERT INTO slotSignups (id, slotId, memberEmail, cancelCode) VALUES (1, 1, 'maya.thompson@example.com', lower(hex(randomblob(16))));

And src/index.js, the Worker:

// The garden's shift sign-up API, as a Cloudflare Worker with a D1 database.

// sends data as JSON with a status code
function json(data, status = 200) {
  return new Response(JSON.stringify(data), {
    status,
    headers: { "content-type": "application/json" }
  })
}

// the columns anyone may see: no emails, no cancel codes
const SHIFT_QUERY = `
  SELECT slots.id, slots.date, slots.task, slots.start, slots.end, slots.capacity,
         COUNT(slotSignups.id) AS spotsFilled
  FROM slots
  LEFT JOIN slotSignups ON slotSignups.slotId = slots.id`

export default {
  async fetch(request, env) {
    const url = new URL(request.url)
    // "/shifts/6/signups" becomes ["shifts", "6", "signups"]
    const parts = url.pathname.split("/").filter(part => part !== "")
    const method = request.method

    if (method === "GET" && parts.length === 1 && parts[0] === "shifts") {
      return listShifts(env)
    }
    if (method === "GET" && parts.length === 2 && parts[0] === "shifts") {
      return getShift(env, Number(parts[1]))
    }
    if (method === "POST" && parts.length === 3 && parts[0] === "shifts" && parts[2] === "signups") {
      return signUp(request, env, Number(parts[1]))
    }
    if (method === "DELETE" && parts.length === 2 && parts[0] === "signups") {
      return cancel(request, env, Number(parts[1]))
    }
    return json({ error: "Not found" }, 404)
  }
}

async function listShifts(env) {
  const { results } = await env.DB.prepare(`${SHIFT_QUERY} GROUP BY slots.id ORDER BY slots.date, slots.start`).all()
  return json(results)
}

async function getShift(env, id) {
  const shift = await env.DB.prepare(`${SHIFT_QUERY} WHERE slots.id = ? GROUP BY slots.id`).bind(id).first()
  if (shift === null) {
    return json({ error: "Shift not found" }, 404)
  }
  return json(shift)
}

async function signUp(request, env, slotId) {
  const slot = await env.DB.prepare("SELECT capacity FROM slots WHERE id = ?").bind(slotId).first()
  if (slot === null) {
    return json({ error: "Shift not found" }, 404)
  }
  const body = await request.json().catch(() => ({}))
  // emails aren't case-sensitive, so compare them in lowercase
  const email = String(body.email ?? "").trim().toLowerCase()
  if (email === "") {
    return json({ error: "Email is required" }, 400)
  }
  const member = await env.DB.prepare("SELECT email FROM members WHERE email = ?").bind(email).first()
  if (member === null) {
    return json({ error: "That email doesn't belong to a club member" }, 400)
  }
  const { count } = await env.DB.prepare("SELECT COUNT(*) AS count FROM slotSignups WHERE slotId = ?").bind(slotId).first()
  if (count >= slot.capacity) {
    return json({ error: "This shift is full" }, 409)
  }
  // a random code that only the person who signed up receives, needed to cancel
  const cancelCode = crypto.randomUUID()
  try {
    const result = await env.DB.prepare("INSERT INTO slotSignups (slotId, memberEmail, cancelCode) VALUES (?, ?, ?)")
      .bind(slotId, email, cancelCode)
      .run()
    return json({ id: result.meta.last_row_id, slotId, cancelCode }, 201)
  } catch (error) {
    if (String(error.message).includes("UNIQUE")) {
      return json({ error: "You're already signed up for this shift" }, 409)
    }
    throw error
  }
}

async function cancel(request, env, id) {
  const body = await request.json().catch(() => ({}))
  const result = await env.DB.prepare("DELETE FROM slotSignups WHERE id = ? AND cancelCode = ?")
    .bind(id, String(body.cancelCode ?? ""))
    .run()
  if (result.meta.changes === 0) {
    return json({ error: "Sign-up not found, or the cancel code is wrong" }, 404)
  }
  return new Response(null, { status: 204 })
}

Two small new pieces: request.json().catch(() => ({})) reads the body as JSON, or gives an empty object if the body isn't valid JSON, so the checks that follow report "Email is required" instead of crashing. And SHIFT_QUERY holds the part of the query both GET routes share, with each adding its own ending, the same select-only-what's-public query as before.

44.4.1 Running it

In a new folder, with the four files above:

npm install --save-dev wrangler
npx wrangler login
npx wrangler d1 create garden-signups

Copy the database_id that d1 create prints into wrangler.jsonc. Then set up the local database and run the Worker on your computer:

npx wrangler d1 execute garden-signups --local --file=./schema.sql
npx wrangler d1 execute garden-signups --local --file=./seed.sql
npx wrangler dev

wrangler dev runs the Worker at http://127.0.0.1:8787. A test script like the one from Lesson 42. A Server with Node and Express, with the new cancel codes, printed this:

GET /shifts/6 -> 200 {"id":6,"date":"2027-06-19","task":"planting","start":"09:00","end":"11:00","capacity":3,"spotsFilled":0}
POST /shifts/6/signups -> 201 {"id":13,"slotId":6,"cancelCode":"(a random code)"}
POST /shifts/6/signups -> 409 {"error":"You're already signed up for this shift"}
POST /shifts/1/signups -> 409 {"error":"This shift is full"}
POST /shifts/2/signups -> 400 {"error":"That email doesn't belong to a club member"}
DELETE /signups/13 -> 404 {"error":"Sign-up not found, or the cancel code is wrong"}
DELETE /signups/13 -> 204
GET /shifts/6 -> 200 {"id":6,"date":"2027-06-19","task":"planting","start":"09:00","end":"11:00","capacity":3,"spotsFilled":0}

A guessed code is refused, and the right one cancels. When it all works locally, run the same two d1 execute commands with --remote instead of --local, then npx wrangler deploy. Wrangler prints the Worker's public address, ending in workers.dev, and the club's API is online.

44.4.2 One more wrinkle: CORS

If the sign-up page from Lesson 42. A Server with Node and Express stays on the club's website, at a pages.dev address, and calls the API at a workers.dev address, the browser treats that as a request to another site, and applies the CORS rules from Lesson 21. Asynchronous JavaScript. The simplest solution is to have the Worker serve the page too, so both come from the same address, which is where the next lesson begins.

44.5 Your Learner Profile

The new rule captures what went wrong in the move: an assistant can't keep rules it was never shown.

44.6 Summary

Serverless platforms run your code on their computers whenever a request arrives, and Cloudflare Workers does it for free, within limits. A Worker exports a fetch function that receives a standard Request and returns a standard Response, and reaches a D1 database, which is SQLite, through a binding, env.DB. Wrangler creates databases, runs SQL against local and remote copies, runs the Worker locally with wrangler dev, and deploys it. Moving code to a new platform is where rules get lost: give the assistant the old code or every rule, and test against the original design. An API on the internet can be called by anyone, so protect actions such as cancelling with a random token that only the right person has. Next, the page and the API come together in one app.