Starter example Bindings

A small Hyperdrive example you can adapt quickly

This example keeps Hyperdrive focused on one thing: prove the binding exists and expose the connection information your app will need next.

That is a better first example than a giant database abstraction because it teaches the actual runtime contract the repo proves today.

Config focus: Stable Hyperdrive naming
Runtime shape: Read connection information from the binding
Best use: Health checks and first integration wiring

Start by wiring the binding clearly in config

Minimal Hyperdrive config

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'hyperdrive-example',

files: {

fetch: 'src/fetch.ts'

bindings: {

hyperdrive: {

DB: 'app-postgres'

}

})

Then use it in one honest runtime path

Once this route works, the next step is usually a targeted integration with the actual PostgreSQL driver and database path you plan to use.
This example is intentionally smaller than D1 because the repo evidence for Hyperdrive local ergonomics is also smaller.

Expose the binding shape you will use later

import { env } from 'devflare'

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

return Response.json({

hasBinding: Boolean(env.DB),

hasConnectionString: Boolean(env.DB?.connectionString)

})

}

Keep the first version boring on purpose

A smaller example is a more truthful example

The point here is to show the real binding contract the worker receives, not to imply more local guarantees than the repo currently proves.

Testing Hyperdrive

Hyperdrive testing should start smaller and more cautiously than D1 testing: prove the binding exists, then add targeted integration where the real database path matters.

Browser Rendering

Devflare supports Browser Rendering, but the docs should say the quiet part out loud: there is exactly one browser binding today, and the best-supported local story lives in dev-server and integration flows.