How front-end, back-end and DB connect

Almost every web app is made of three jobs: showing things to a person, running logic and rules, and remembering data. On Cloudflare those three jobs map to three pieces — the browser (front-end), a Worker (your back-end API), and a database (D1, KV, R2, or Durable Objects). This guide gives you the mental map for how they connect.

Front-end means the part that runs inside the user's browser — the HTML, CSS and JavaScript they actually see and click. Back-end means code that runs on a server (here, a Worker) which the user never sees directly; it does the thinking and talks to the database. A database is just where data is stored so it survives after the request ends.

Notice two different arrows leaving the browser. One loads the static files that make up the page (the look). The other is an API call that asks the Worker for fresh data (the content). Keeping these separate is the heart of the whole model.

Each layer has one clear job. Mixing the jobs up is the most common beginner mistake (for example, putting your database password in front-end code, where anyone can read it). Keep the responsibilities separated like this:

The fastest way to understand a full-stack app is to trace a single click. Imagine a page with a "Load todos" button. Here is exactly what happens, step by step, when the user presses it.

What each step means

• Click: the browser's JavaScript reacts to the button press and calls fetch().
• fetch GET /api/todos: an HTTP request leaves the browser and is routed to your Worker.
• SELECT ...: the Worker asks the database for the rows it needs.
• rows: the database hands the matching data back to the Worker.
• JSON response: the Worker turns that data into JSON (a simple text format) and replies.
• render: the browser receives the JSON and updates the page — no full reload needed.

A Worker doesn't connect to a database with a password and a connection string the way old servers did. Instead you declare a binding — a named, secure connection that Cloudflare wires up for you. In your code the binding appears as a property on the env object, like env.DB.

Here is the smallest possible version of all three layers working together: a front-end that calls fetch, a Worker that returns JSON from D1, the wrangler.toml that binds them, and the SQL that creates the data. Copy these into one project and you have a real full-stack app.

1. 1. The front-end (runs in the browser)

   Plain JavaScript that calls your API on click and paints the result. No framework needed to understand the idea.

   htmlcontent_copyCopy

   <!-- public/index.html -->
   <button id="load">Load todos</button>
   <ul id="list"></ul>
   
   <script>
     async function loadTodos() {
       // Ask the Worker (back-end) for data
       const res = await fetch("/api/todos");
       const todos = await res.json();
       // Paint the result into the page
       document.querySelector("#list").innerHTML =
         todos.map((t) => `<li>${t.title}</li>`).join("");
     }
     document.querySelector("#load").addEventListener("click", loadTodos);
   </script>

2. 2. The back-end Worker (returns JSON)

   It serves static files for normal paths, and for /api/todos it reads D1 via env.DB and replies with JSON. Notice the user's request never touches the database directly — only the Worker does.

   jscontent_copyCopy

   // src/index.js
   export default {
     async fetch(request, env, ctx) {
       const url = new URL(request.url);
       if (url.pathname === "/api/todos") {
         // env.DB is the D1 binding from wrangler.toml
         const { results } = await env.DB
           .prepare("SELECT id, title FROM todos")
           .all();
         return Response.json(results);
       }
       // Everything else is served as a static asset
       return env.ASSETS.fetch(request);
     },
   };

3. 3. The wrangler.toml (wires the binding)

   This config file tells Cloudflare your Worker's entry file, where the static files live, and which database to expose as env.DB.

   tomlcontent_copyCopy

   name = "my-fullstack-app"
   main = "src/index.js"
   compatibility_date = "2025-01-01"
   
   # Serve the front-end from ./public, exposed as env.ASSETS
   [assets]
   directory = "./public"
   binding = "ASSETS"
   
   # Bind a D1 database; reach it in code as env.DB
   [[d1_databases]]
   binding = "DB"
   database_name = "my-app-db"
   database_id = "<paste-your-database-id>"

4. 4. The data layer (create the table)

   Run this SQL once to create the todos table and add a couple of rows, so your /api/todos endpoint has something to return.

   sqlcontent_copyCopy

   CREATE TABLE IF NOT EXISTS todos (
     id INTEGER PRIMARY KEY,
     title TEXT NOT NULL
   );
   
   INSERT INTO todos (title) VALUES
     ('Learn the full-stack model'),
     ('Wire a Worker to D1');

5. 5. Run it, then deploy

   wrangler dev starts everything locally at http://localhost:8787. When it looks good, wrangler deploy puts all three layers live on Cloudflare's global network in one shot.

   bashcontent_copyCopy

   npx wrangler d1 execute my-app-db --local --file=./schema.sql
   npx wrangler dev
   npx wrangler deploy

Things beginners trip over

• CORS errors: if your front-end and API are on the same Worker, you usually avoid them entirely — serving both from one origin is the simplest setup.
• Forgetting await: fetch() and D1 queries are asynchronous; always await them or you'll get a Promise instead of data.
• Returning HTML when you meant JSON: use Response.json(data) so the front-end can call res.json() cleanly.
• Binding name mismatch: the name in wrangler.toml must match what you read on env (env.DB needs binding = "DB").
• Editing local vs remote DB: --local touches your machine's copy; drop it (or use --remote) to change the deployed database.