Application example Bindings

Use Analytics Engine in a real application path

Analytics Engine lets Workers write structured data points for later querying and operational analysis.

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'

}

})

Build the application flow around the binding

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

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.

Write one analytics point in the worker

import { env } from 'devflare/runtime'

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

env.APP_ANALYTICS.writeDataPoint({

indexes: ['search'],

blobs: ['devflare query']

})

return new Response('recorded')

}

Keep production boundaries visible

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

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.