Application example Bindings

Use Services in a real application path

Service bindings let one Worker call another Worker without routing through a public URL.

A real Services application path with config and runtime code kept side by side.

Use this as the application-focused Services example before you add feature-specific abstractions around the binding.

Config focus: Explicit wiring
Runtime shape: One env service call from the gateway worker
Best use: Internal APIs and worker-family boundaries

Start by wiring the binding clearly in config

Gateway config with a service ref

import { defineConfig, ref } from 'devflare/config'

const mathService = ref(() => import('../math-service/devflare.config'))

export default defineConfig({

name: 'gateway',

files: {

fetch: 'src/fetch.ts'

bindings: {

services: {

MATH_SERVICE: mathService.worker

}

})

Build the application flow around the binding

Treat this as the app-level Services 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.

Once this tiny path works, adding named entrypoints becomes an incremental extension, not a different architecture.
Keep one simple service example like this around if you want a smoke check for multi-worker wiring.

Use the service in the gateway worker

import { env } from 'devflare/runtime'

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

const result = await env.MATH_SERVICE.add(4, 5)

return Response.json({ result })

}

Keep production boundaries visible

Config focus: Explicit wiring.
Runtime shape: One env service call from the gateway worker.
Best use: Internal APIs and worker-family boundaries.

Testing Services

Service bindings are one of the clearest Devflare wins in multi-worker apps: you can keep the real worker boundary and still prove it through the default local harness.

AI

Devflare makes Workers AI usable by keeping the binding tiny in config, the worker call obvious, and the remote smoke test explicit instead of fake.