Starter example Bindings

A small Analytics Engine example you can adapt quickly

This example writes one analytics event from one route, which is usually all you need to teach the binding shape clearly.

It keeps the dataset name visible, the event payload small, and the worker boundary obvious.

Config focus: Explicit dataset naming
Runtime shape: Call during a request
Best use: Search analytics, request logging, and event emission

Start by wiring the binding clearly in config

Minimal Analytics Engine config

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'analytics-example',

files: {

fetch: 'src/fetch.ts'

bindings: {

analyticsEngine: {

APP_ANALYTICS: {

dataset: 'app-analytics'

}

})

Then use it in one honest runtime path

Keep the event payload small and explicit so you can reason about what the worker is writing.
If the real event shape grows richer later, this tiny route still teaches the binding contract honestly.

Write one analytics point in the worker

import { env } from 'devflare'

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

env.APP_ANALYTICS.writeDataPoint({

indexes: ['search'],

blobs: ['devflare query']

})

return new Response('recorded')

}

Keep the first version boring on purpose

A route can teach the whole binding

For Analytics Engine, one request that writes one point is already enough to teach the env shape and the operational habit.

Testing Analytics Engine

Analytics Engine tests should stay thin: verify that the worker writes a data point, not that you can recreate Cloudflare analytics locally.

Send Email

Send Email is a real binding surface in Devflare, and it is worth documenting separately from inbound handlers so the two flows do not get blurred together.