Architecture

Edge Kit brings your public website, customer application, and backend into one project. You build the interface with React and deploy the application to Cloudflare Workers. Authentication, billing, data access, and background processing share that deployment and its configured services.

Understanding the boundaries between these pieces makes it easier to add a feature without rebuilding the infrastructure around it.

Application layers

TanStack Start provides the full-stack application framework. TanStack Router connects URLs to layouts and pages, while server functions give the browser a typed way to request private backend work.

The project structure groups the code by responsibility. Routes describe the page or endpoint, feature modules hold product behavior, and shared integrations connect the external services.

Rendering and navigation

On an initial page request, the Worker can render React into HTML before sending it to the browser. The browser then attaches the interactive behavior needed for forms, menus, and subsequent navigation. These stages are server-side rendering and hydration: the first delivers the page content, and the second makes it interactive.

Later navigation can happen through the router without a full document reload. The kit connects routing to TanStack Query so page data can be loaded ahead of navigation and reused by the interface. Data fetching explains freshness and updates after a customer changes something.

Shared page code must work in both environments. A component that needs a browser API should use it during a browser interaction or effect. Database bindings and credentials belong behind the server boundary.

Request lifecycle

A typical customer action, such as saving a document, follows the same flow across features:

1. The interface collects input and displays validation feedback.
2. A server function receives the request and validates the submitted data.
3. Server-side checks identify the customer and verify ownership or paid access.
4. The operation reads or changes the appropriate Cloudflare resource.
5. The server returns a result suitable for the interface.
6. The client refreshes affected data and shows the completed state.

The kit supplies the connections between these layers. Your feature defines its data, business rules, and presentation. The feature recipe follows this flow for a small customer-owned resource.

Routes and layouts

The starting application has public marketing pages, authentication screens, a customer dashboard, and HTTP endpoints. Shared layouts provide the surrounding navigation and providers, so individual pages can focus on their content.

The dashboard layout checks the session before showing its pages. Each private server operation also checks access independently. A redirect is useful for the navigation experience; authorization at the operation protects the underlying data.

The router generates its route tree from source files. New pages belong in the source routes, while the generated tree is maintained by the tooling. Navigation covers menus, layouts, and new destinations.

Persistent state

A Worker handles requests without requiring you to maintain a traditional application server. Durable product state belongs in the services connected to it:

• D1 stores structured records and their relationships, such as customers and product resources.
• R2 stores file contents, such as attachments and generated reports.
• KV stores values that benefit from distributed reads, such as cached public data or application settings.
• Queues carry work to process separately from the customer's request.

These services solve different problems. A document can have its ownership and title in D1, its file in R2, and a processing task delivered through a queue. Each guide above covers the corresponding infrastructure and its use in your product.

Keep customer state out of shared module variables. A value in server memory is neither a durable database record nor a safe place to store another customer's request context.

Bindings and environments

A binding is the connection between the Worker and a Cloudflare resource. Your application uses the binding name; Wrangler determines which database, bucket, or queue it connects to in the current environment.

Local development simulates supported services and keeps their state separate from production. Services configured for remote access, including AI and feature flags, use your Cloudflare account during development. Wrangler configuration describes each binding and its setup.

Public build settings and private runtime secrets also have different lifecycles. A changed public URL may require a new build, while a Worker secret is configured for the deployed application. Follow environment variables when preparing another environment.

Feature boundaries

Keep related validation, server operations, query definitions, and interface components together as a feature grows. Share a utility when multiple features need the same behavior, such as authenticated file delivery or email rendering.

This preserves a direct path from a customer interaction to the rules that implement it. You can extend an existing feature or add a new one while continuing to use the same authentication, configuration, logging, and testing infrastructure.