framework-guides

313 notes in this subject, read out of this brain and free to use. This is page 3 of 6.

RedwoodSDK routing with defineApp

RedwoodSDK uses the `defineApp` function which accepts an array of route definitions. Routes are defined using the `route` function from `rwsdk/router`, which takes a path and a handler function. Route handlers can return JSX directly, which is rendered on the server as React Server Components and sent as HTML to the client.

RedwoodSDK local development server

Run `npm run dev` (or equivalent with other package managers) in the project directory to start the local development server. The development server runs on `http://localhost:5173` by default.

RedwoodSDK entry point file

The entry point of a RedwoodSDK application is `src/worker.tsx`. This file uses the `defineApp` function from `rwsdk/worker` to handle requests and return responses to the client.

Create new RedwoodSDK project

To create a new RedwoodSDK project, run the command `create-rwsdk my-project-name`, replacing `my-project-name` with your desired project name.

RedwoodSDK framework overview

RedwoodSDK is a framework for building server-side web applications on Cloudflare Workers. It is a Vite plugin that provides SSR, React Server Components, Server Functions, and realtime capabilities.

Creating a new Vike app with Cloudflare support

Use vike.dev/new to scaffold a new Vike app that uses vike-photon with @photonjs/cloudflare. Alternatively, use the CLI: npm create vike@latest --react --hono --drizzle --cloudflare

Vike custom server for advanced features

By default, Photon uses a built-in server supporting basic features like SSR. For additional server functionalities such as file uploads or API routes, you must create your own server by following the vike-photon documentation.

Vike framework support on Cloudflare Workers

Vike is a Next.js/Nuxt alternative powered by a modular architecture. All app types (SSR/SPA/SSG) are supported when deployed to Cloudflare Workers using the Vike extension vike-photon.

Automatic Vike project configuration with Wrangler

Running `wrangler deploy` in a Vike project without a Wrangler configuration file will automatically detect Vike, generate the necessary configuration, and deploy the project.

Vike integration packages for Cloudflare

To add Vike to an existing app for Cloudflare Workers deployment, install three packages: wrangler, vike-photon, and @photonjs/cloudflare.

Vike config extension with vike-photon

In pages/+config.ts, import vikePhoton from 'vike-photon/config' and extend the default export to include vikePhoton in the extends array.

Vike package.json scripts for development and deployment

Vike projects should include these npm scripts: 'dev' running 'vike dev', 'preview' running 'vike build && vike preview', and 'deploy' running 'vike build && wrangler deploy'.

Deploying Vue projects to Cloudflare Workers

Run 'npm run deploy' to build and deploy the Vue project. Projects can be deployed to a *.workers.dev subdomain, a Custom Domain, from your own machine, or from CI/CD systems including Cloudflare's own CI/CD.

Vue deployment with Workers Assets

Vue applications can be deployed to Cloudflare Workers using Workers Assets. Use the create-cloudflare CLI with the command: npm create cloudflare@latest my-vue-app --framework=vue

Vue project structure with Workers Assets

A Vue project created with create-cloudflare includes: src/App.vue (Vue app), server/index.ts (Worker backend), index.html (entry point), vite.config.ts (build config using Cloudflare Vite plugin), and wrangler.jsonc (Wrangler configuration file).

Cloudflare Vite plugin in Vue projects

vite.config.ts is configured to use the Cloudflare Vite plugin. This runs the Worker in the Cloudflare Workers runtime during local development, ensuring the local environment matches production as closely as possible.

Vue backend API in default project

The default project setup includes a Worker backend at server/index.ts with a single endpoint /api/ that returns a text response. The Vue app calls this endpoint to retrieve a message.

Local development with Vue and Wrangler

Run 'npm run dev' to start a local development server. This uses Vite for local development with hot module replacement (HMR) and the Cloudflare Vite plugin, which runs the application in the Cloudflare Workers runtime and enables access to local emulations of bindings.

TanStack Start custom server entrypoint example

Example custom server entrypoint with Durable Objects, Queues, and Cron Triggers: import handler from "@tanstack/react-start/server-entry"; export { MyDurableObject } from "./my-durable-object"; export default { fetch: handler.fetch, async queue(batch, env, ctx) { for (const message of batch.messages) { console.log("Processing message:", message.body); message.ack(); } }, async scheduled(event, env, ctx) { console.log("Cron triggered:", event.cron); }, };

TanStack Start automatic configuration with wrangler deploy

Running wrangler deploy in a TanStack Start project without a Wrangler configuration file will automatically detect the framework, generate necessary configuration, and deploy the project.

TanStack Start automatic configuration details

Automatic configuration for TanStack Start in wrangler.jsonc sets main to .output/server/index.mjs, assets directory to .output/public, includes nodejs_compat compatibility flag, and enables observability.

Create new TanStack Start project for Cloudflare Workers

Create a new TanStack Start application pre-configured for Cloudflare Workers using: npm create cloudflare@latest my-tanstack-start-app -- --framework=tanstack-start

TanStack Start vite.config.ts configuration

Configure TanStack Start with Cloudflare by adding @cloudflare/vite-plugin to vite.config.ts. The plugin order should be: cloudflare (with viteEnvironment name 'ssr'), tanstackStart(), then react().

TanStack Start wrangler.jsonc configuration

Basic wrangler.jsonc configuration for TanStack Start requires: main set to @tanstack/react-start/server-entry, compatibility_date, compatibility_flags including nodejs_compat, and observability.enabled set to true.

TanStack Start package.json scripts

TanStack Start package.json scripts should include: dev (vite dev), build (vite build), preview (vite preview), deploy (npm run build && wrangler deploy), and cf-typegen (wrangler types).

TanStack Start custom server entrypoint

Create a custom server entrypoint (e.g., src/server.ts) to add Queues, Cron Triggers, Durable Objects, and Workflows to TanStack Start. Import the default handler from @tanstack/react-start/server-entry and add queue(), scheduled(), and other Workers handler exports.

Test TanStack Start scheduled handler locally

Test scheduled handlers locally using curl to the /cdn-cgi/handler/scheduled endpoint: curl "http://localhost:3000/cdn-cgi/handler/scheduled?cron=*+*+*+*+*"

TanStack Start Workflow example

Export a Workflow class from custom entrypoint extending WorkflowEntrypoint. Example: import { WorkflowEntrypoint, WorkflowStep, WorkflowEvent } from "cloudflare:workers"; export class MyWorkflow extends WorkflowEntrypoint<Env> { async run(event: WorkflowEvent<{ input: string }>, step: WorkflowStep) { const result = await step.do("process data", async () => { return `Processed: ${event.payload.input}`; }); await step.sleep("wait", "10 seconds"); await step.do("finalize", async () => { console.log("Workflow complete:", result); }); } }

TanStack Start Workflow wrangler configuration

Add Workflow configuration to wrangler.jsonc with workflows array containing name, binding, and class_name properties.

TanStack Start Service Bindings configuration

Add service bindings to wrangler.jsonc in a services array with binding name and service name properties to call another Worker's RPC methods.

TanStack Start access service binding in server function

Access service bindings in server functions using the env object imported from cloudflare:workers. Example: const result = await env.AUTH_SERVICE.verify(token);

TanStack Start access bindings via env

Access Cloudflare bindings in TanStack Start server-side code by importing env from cloudflare:workers. Access bindings like env.MY_KV, env.MY_BUCKET, env.AI, etc.

Generate TypeScript types for TanStack Start bindings

Generate TypeScript types for bindings based on wrangler.jsonc configuration using: npm run cf-typegen

TanStack Start R2 bucket configuration

Add R2 bucket binding to wrangler.jsonc in r2_buckets array with binding name and bucket_name properties.

TanStack Start R2 file operations example

Example TanStack Start server functions for R2 upload and download: const uploadFile = createServerFn({ method: "POST" }) .validator((data: { key: string; content: string }) => data) .handler(async ({ data }) => { await env.MY_BUCKET.put(data.key, data.content); return { success: true }; }); const getFile = createServerFn() .validator((key: string) => key) .handler(async ({ data: key }) => { const object = await env.MY_BUCKET.get(key); return object ? await object.text() : null; });

TanStack Start static prerendering configuration

Enable static prerendering in vite.config.ts by adding prerender: { enabled: true } to the tanstackStart plugin options. Requires @tanstack/react-start v1.138.0 or later.

TanStack Start prerendering uses local environment

Static prerendering at build time uses local environment variables, secrets, and bindings storage data. To prerender with production data, use remote bindings.

TanStack Start prerendering in CI environments

In CI environments where environment variables or secrets may not be available during build, set CLOUDFLARE_INCLUDE_PROCESS_ENV=true and provide required values as environment variables. If using Workers Builds, update build settings in the configuration.

Review and test AI-generated Workers code before deploying

AI models may generate invalid code, configuration, or other errors when creating Workers applications. Review and test all generated code before deploying it to production.

Adding Workers context to Windsurf

Use the @-mention command in Windsurf to include a file containing the Workers system prompt to your Chat.

Adding Workers context to Zed

Use the /file command in Zed to add a file containing the Workers system prompt to the Assistant context.

Adding Workers context to Claude Code

Add the Workers system prompt to your CLAUDE.md configuration file after running /init to include best practices to a Workers project.

Adding Workers context to Cursor

Add the Workers system prompt to your Project Rules in Cursor to provide context about Workers APIs and best practices.

Adding Workers context to GitHub Copilot

Create a .github/copilot-instructions.md file at the root of a project and add the Workers system prompt to include best practices for a Workers project in GitHub Copilot.

AI editor support for Workers documentation

AI-enabled editors Cursor and Windsurf can index documentation. Zed and Windsurf can use llms-full.txt files for comprehensive documentation context. All of these editors support adding Workers prompts and documentation for context during development.

Cursor includes Cloudflare docs by default

The Cursor editor includes Cloudflare Developer Docs by default and provides the @Docs command to access them during coding.

Workers documentation indexing URLs

The following URLs provide Workers documentation in machine-readable formats for AI indexing: https://developers.cloudflare.com/workers/llms-full.txt for comprehensive offline indexing, and https://developers.cloudflare.com/workers/llms.txt for online context. Complete Cloudflare documentation is available at https://developers.cloudflare.com/llms-full.txt and https://developers.cloudflare.com/llms.txt.

AI agents for creating Workers

Cloudflare Workers applications can be created using AI agents and editors including Cursor, Windsurf, VS Code, Claude Code, Codex, and OpenCode by providing simple prompts.

MCP server for Workers documentation

The cloudflare-docs MCP (Model Context Protocol) server at https://docs.mcp.cloudflare.com/mcp can be connected to AI agents to teach them about Workers. This server is available at https://github.com/cloudflare/mcp-server-cloudflare/tree/main/apps/docs-ai-search.

Accessing JavaScript globals in Python Workers

Python Workers can access JavaScript globals in two ways: using the workers module (recommended, part of workers-runtime-sdk package) for a more Pythonic interface, or directly importing from the js module. For example, Response can be imported from js and called as Response.new().

Python to JavaScript type conversion utility

Example helper function for converting Python objects to JavaScript: ```python from js import Object from pyodide.ffi import to_js as _to_js from workers import WorkerEntrypoint, Response # to_js converts between Python dictionaries and JavaScript Objects def to_js(obj): return _to_js(obj, dict_converter=Object.fromEntries) ```

Python Workers FFI access to JavaScript

Python Workers can access JavaScript APIs, bindings, and globals through Pyodide's Foreign Function Interface (FFI). This enables Python code to use Cloudflare Workers bindings, JavaScript globals like Request, Response, and fetch(), and the full feature set of Cloudflare Workers by writing exclusively Python code.

Converting Python objects to JavaScript

Pyodide provides a to_js function to convert Python objects to JavaScript. The to_js function can convert Python dictionaries to JavaScript Objects using Object.fromEntries. For complete details, see the pyodide.ffi.to_js documentation.

Importing JavaScript Response in Python Worker

Example of using JavaScript Response in a Python Worker: ```python from workers import WorkerEntrypoint from js import Response class Default(WorkerEntrypoint): async def fetch(self, request): return Response.new("Hello World!") ```

Python Workers development environment setup

To set up a Python Workers development environment, first ensure uv and Node are installed. Then run: uvx --from workers-py pywrangler init. This creates a pyproject.toml file with workers-py as a development dependency and a wrangler config file.

Initialize Python Worker project with templates

When you initialize a new Python Worker project using pywrangler, you can select from many templates by running: uv run pywrangler init. Alternatively, you can clone the examples repository at https://github.com/cloudflare/python-workers-examples to explore more options.

Python Worker main entry point structure

The main entry point for a Python Worker is the fetch handler that handles incoming requests. In a Python Worker, this handler is placed in a Default class that extends the WorkerEntrypoint class, which is imported from the workers SDK module.

Python Workers first-class experience features

Cloudflare Workers provides a first-class Python experience including fast-booting packages like FastAPI, Langchain, and Pydantic, a foreign function interface (FFI) that lets you use JavaScript objects and functions from Python including Runtime APIs, and an ecosystem of services accessible via bindings.

Minimal Python Worker example

A Python Worker can be implemented with this example: from workers import WorkerEntrypoint, Response class Default(WorkerEntrypoint): async def fetch(self, request): return Response("Hello World!") This shows a basic Worker that returns a simple text response.

pywrangler CLI tool for Python Workers

pywrangler is the CLI for Python Workers used to run a Python Worker locally, install packages, and deploy it to Cloudflare. It is available at https://github.com/cloudflare/workers-py.

Give your agent this brain