Application example Bindings

Use D1 in a real application path

D1 is Cloudflare’s serverless SQL database for applications that run on Workers.

This starter example keeps D1 focused on one job: answer a single query and prove the binding works locally.

You do not need a giant ORM story to prove D1 is wired correctly. One table-shaped query is already enough to make the point.

Config focus: Stable database naming
Runtime shape: Prepared statement query in a fetch handler
Best use: Health checks, small lookup routes, and early schema experiments

Start by wiring the binding clearly in config

Minimal D1 config

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'd1-example',

files: {

fetch: 'src/fetch.ts'

bindings: {

d1: {

DB: 'app-db'

}

})

Build the application flow around the binding

Treat this as the app-level D1 path: the route, event handler, or service module receives a real request and uses the binding to do useful work.

Keep product limits, remote ownership, and fallback behavior visible in the code around the binding instead of hiding everything behind a vague utility too early.

You can replace the health query with a real table lookup later without changing the binding shape.
Keep one route like this around if you want a cheap deploy smoke path for D1.

A tiny route that proves the binding works

import { env } from 'devflare/runtime'

export async function fetch(): Promise<Response> {

const row = await env.DB.prepare('select 1 as ok').first<{ ok: number }>()

return Response.json({ ok: row?.ok === 1 })

}

Keep production boundaries visible

Config focus: Stable database naming.
Runtime shape: Prepared statement query in a fetch handler.
Best use: Health checks, small lookup routes, and early schema experiments.

The first example does not need a migration epic

Prove the binding first. Add richer schema setup only after the worker already has one truthful D1 path.

Testing D1

D1 is one of the easiest bindings to test meaningfully with Devflare because the local runtime already speaks the same database API your worker uses.

R2

R2 is straightforward in config and well-supported locally, but browser-facing delivery should usually go through a Worker route instead of assuming bucket URLs.