Rendering React at the Edge

Running a high-traffic media site quickly forces you into a familiar dilemma. Fully static rendering guarantees fast delivery from a CDN, but every redesign or content change means regenerating the entire site — a non-starter if you have years of archived pages. Fully dynamic rendering on origin servers keeps content fresh but demands expensive infrastructure to handle traffic spikes, and the internal caching layers you'll need to stay responsive risk cascading failures during cache invalidations.

Progressive frameworks like Next.js offer a middle path with static-site generation plus incremental regeneration, but those patterns were built around Node.js HTTP servers. Cloudflare Workers run JavaScript in V8 isolates with a FetchEvent-based model, making it awkward to run a Next.js server directly at the edge. Flareact is an open-source React framework that adapts those familiar patterns for Cloudflare Workers, rendering React applications at the edge instead of on an origin server.

Flareact follows Next.js's conventions: file-based page routing, dynamic page paths, and edge-side data fetching. Pages render on Cloudflare Workers and are cached using the Cache API, so you get fresh responses without worrying about origin load. The Worker runtime has no cold starts, and pages are served from within the datacenter, reducing network round trips.

Getting started uses the standard wrangler generate workflow to scaffold a new project. From there, the developer experience mirrors Next.js closely enough that porting an existing app should be straightforward.

What Flareact Changes

Deploying a React app to Workers Sites isn't new — static exports from create-react-app, Gatsby, or Next.js have worked for a while. The difference is that Flareact renders at the edge, returning HTML markup with initial page content. That's helpful for search crawlers and performance alike. Because responses are cached at the edge, pages can be regenerated selectively when you need freshness.

Flareact borrows the data-fetching shape from Next.js's getStaticProps but adapts it to the edge. Pages export a getEdgeProps function that supplies props to the component, and it can return a revalidate parameter to control how long a cached response lives before regeneration. API Routes also make the transition: they let you write standard Cloudflare Worker scripts directly in your React app.

The Worker and Client Split

Flareact's Worker has three core jobs:

  1. Render the page component into static HTML
  2. Embed the props as JSON in a script tag within that markup
  3. Load the client-side JavaScript and styles needed for interactivity

The bundling challenge is interesting. Webpack targets the webworker output rather than node, and Workers don't have filesystem access, so Flareact can't scan directories at runtime. Instead, it uses Webpack's require.context API during the build to generate a manifest of pages for both the client and worker bundles.

On the client side, Flareact compiles a router and data-fetching layer. The client listens for routing changes, updates the URL via pushState, fetches the new page's props from the Worker over AJAX, and swaps the component tree. Link handling is provided by a flareact/link component. Head management is adapted separately: rather than building custom SSR-aware head handling from scratch, Flareact wraps react-helmet in a flareact/head component.

Local development uses wrangler dev, which tunnels requests from your machine to the Cloudflare edge and back. That loop means you're testing against the real runtime environment rather than a local simulation — a meaningful improvement for serverless development workflows.

Request Handling

At runtime, Flareact inspects each incoming FetchEvent:

  • For page or page-props requests, it checks the Cache API first. Cache misses trigger generation, storage, and return of the response.
  • For API route requests, it passes the full FetchEvent to your function for handling.
  • Static assets are served directly from Workers KV.

If you need scheduled freshness, returning revalidate from getEdgeProps tells Flareact to cache for that many seconds before generating a new response.

Where Flareact Fits

Flareact suits typical Jamstack-adjacent applications like blogs and marketing sites as well as more dynamic workloads with integrated API routes and authentication. High-traffic pages that need dynamic content, such as e-commerce inventory or pricing, benefit from edge rendering without an origin dependency. The Workers platform also opens up KV as a first-class database option inside props or API functions, removing the need for externally hosted storage.

The project is young, but real deployments already exist — the Flareact documentation site runs on the framework, and an example project demonstrates a blog backed by a headless WordPress API.

What's next for Flareact

Building a server-side rendering framework for React from scratch was a challenging undertaking, admits creator Chris Biscardi. The project still has gaps compared to mature frameworks like Next.js, especially around performance tuning and production hardening. The near-term roadmap prioritizes the following:

  • Reducing per-page JavaScript weight through better client bundling and Webpack code-splitting
  • Expanding the client-side router, which currently lacks full feature parity
  • Allowing developers to customize the root HTML document
  • Adding support for CSS-in-JS, Sass, CSS modules, and other styling approaches
  • Stabilizing the local development experience
  • Documenting how to use environment variables, secrets, and KV namespaces
  • Providing guidance for CI/CD deployment via GitHub Actions and similar tools

The project is open source and actively welcoming contributors. Interested developers can find the code and issue tracker on GitHub.