Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Running React Applications at the Edge with Cloudflare Workers - Q&A with Josh Larson

Running React Applications at the Edge with Cloudflare Workers - Q&A with Josh Larson

Key Takeaways

  • Server-side rendering and pre-rendering techniques have become more popular in a bid to shorten the time users have to wait for pages to be displayed, especially on low-end mobile devices. A few frameworks have appeared to cover that need while simultaneously providing good developer experience. They are generally tied to a front-end framework (e.g., Next.js for React, Nuxt.js for Vue, Sapper for Svelte)
  • Running applications at the edge has the potential to shorten further the latency observed by users of web applications. Some vendors have introduced offers that allow developers to deploy a static web site on the edge (e.g., Cloudflare's Workers Sites)
  • Flareact is an edge-rendered React framework that renders web applications at the edge. Flareact is built for Cloudflare Workers and inspired by Next.js
  • Flareact currently supports file-based page routing, dynamic page paths, API routes, cache policy configuration, and edge-side data fetching APIs
  • Flareact is still being actively developed and seeks to progressively close the feature gap with Next.js (open-sourced more than 4 years ago)

Josh Larson recently released Flareact, an edge-rendered React framework built for Cloudflare Workers. Flareact is inspired by Next.js, a React framework that features hybrid static and server rendering. While Next.js optimizes React applications for production deployments, (e.g. pre-rendering, optimized pre-fetching, automatic code-splitting), Cloudflare Workers allows running code on the edge quickly, efficiently, and at scale. Flareact seeks to replicate the advantages brought about by Next while adding the benefits of edge-side rendering and caching. Flareact currently supports file-based page routing, dynamic page paths, API routes, cache policy configuration, and edge-side data fetching APIs.

Flareact is open-source software released under the MIT license. Further information can be found on the documentation website. Feedback is welcome and can be directed to Flareact’s GitHub project.

InfoQ interviewed Larson about the motivation behind Flareact, the corresponding use cases, and the future roadmap.

InfoQ: Can you tell our readers about you?

Josh Larson: I’m currently a lead engineer at Vox Media where I work on revenue products powering the Concert ecosystem, a premium advertising network for publishers. I live in Iowa in the United States with my wife, newborn son, and two dogs. This summer, I built a side project called Flareact, which is an experiment for rendering React on the edge in Cloudflare Workers.

InfoQ: What are Cloudflare Workers? How are they useful? How are they used?

Larson:  Cloudflare Workers are a cool technology introduced by Cloudflare a couple of years ago. Normally, you might have a server living in a data center somewhere in the world. You’ll likely put a CDN in front of that to handle caching and manage the load. But imagine having the power of a server directly inside your CDN’s data center. This is what Cloudflare Workers offers —a way to execute code directly at the edge of the CDN. 

This is a really powerful way to manage and modify requests going to and from your origin server—but it also opens up a whole new set of possibilities: instead of paying for and managing your own server, you can use Cloudflare Workers as your origin. This means lightning-fast responses directly at the edge without a round trip to another data center.

InfoQ: What is Flareact and what drove you to write it?

Larson:  Flareact is an edge-rendered React framework built for Cloudflare Workers. It is inspired by Next.js, a terrific and popular React framework built by Vercel. Next.js has grown into a mature framework the past few years—and in the process, the folks building it have proven out some nice patterns for page-based routing and data fetching.

These patterns are what inspired Flareact. Cloudflare Workers offers a Workers Sites feature that allows you to host a static site on top of Cloudflare Workers, with assets stored in a KV [Key/Value] store at the edge. This, combined with the underlying Workers dynamic platform, seemed like the perfect use case for Next.js. 

However, due to technical constraints, it proved too difficult to get Next.js working on Cloudflare Workers. So I set out to build my own framework modeled after Next.js. This experiment ended up working, much to my surprise! And it seems like it might have a few cool use cases.

InfoQ: What are the use cases where Flareact’s edge-side rendering would shine vs. alternatives?

Larson:  Flareact’s edge-side rendering capabilities are really handy for computing quick responses directly at the edge without requiring an origin. This is useful if you need to build a dynamic site with a custom API or with lots of endpoints. 

Using the Cloudflare Cache API, Flareact also caches your pages at the edge along with a revalidation configuration. This means you could build a news site or a blog that fetches posts from a headless API, cache the output once it’s generated, and regenerate it every hour, for example. This greatly reduces the calls against your backend services making it cheaper altogether to host your site.

One key difference between Flareact and Next.js is that Next.js generates statically-rendered pages at build or deploy time rather than at the edge during an initial request. This isn’t necessarily good or bad—though you could imagine you might feel more secure generating a static page upfront with Next.js rather than at the first request with Flareact. However, Flareact is also much quicker to deploy since it doesn’t need to generate all of the initial pages you’ve defined.

InfoQ: You mentioned that (until now) frameworks like Next.js and Cloudflare Workers wouldn’t mesh well due to technical constraints? What are those technical constraints? How did you work around them?

Larson:  Cloudflare Workers executes scripts in V8 Isolates runtime. This means you have access to a handful of common JavaScript utilities to generate a response. One missing library, though, is the filesystem utility. This prevents you from building and deploying a framework like Next.js directly within Workers Sites without major modifications because it depends so much on inspecting the local filesystem on the server at the time of a request.

I’m using some fancy Webpack utilities to pass the context of the user’s source code to the Worker script so the correct page can be served at request time.

InfoQ: How does the current Flareact compare to Next.js?

Larson:  Flareact’s cache strategy is slightly different than the approach Next.js takes. You can imagine there are benefits to initially generating static pages in Next.js instead of relying on the first visitor to generate the static page within Flareact. Additionally, Flareact’s cached page response still counts as an invocation of a Worker, so it is billable to Cloudflare (if you have a hugely-popular site). You can read more about the specific differences here. Finally, it’s important to remember that while Flareact is modeled off of Next.js, it’s still missing years of optimization and polish contained within Next.js.

InfoQ: How much of Flareact is specific to React? Can we imagine in the future the same APIs with other front-end frameworks (e.g. Svelte/SapperVue/Nuxt)?

Larson:  It’s not terribly specific to React, so any framework could be adopted and built for Cloudflare Workers. One thing to watch out for, though, is the file system caveat mentioned above: some server-side rendering implementations of frameworks like Vue have required a local file system utility in the past. This is something that could definitely change, so keep an eye out for Flareact alternatives!

InfoQ: What is next for Flareact? What do you have in priority on the roadmap?

Larson:  Since this is an experimental project, I don’t have a long-term roadmap for Flareact just yet. I’ve been working on improving the client-side bundling to make it more performant. There’s also some work to do to make the developer experience a little better, like deploying to preview environments, managing environmental variables and secrets, and more.

I’d love to spin up some cool demo apps with Flareact using the KV store or durable objects. You could implement your own CMS, live blog, or chat service at the edge. You could even build your own self-hosted Instagram clone with Cloudflare Stream! The possibilities are endless, but free time is not. We’ll see what I come up with.

About the Interviewee

Josh Larson is a software engineer living in Des Moines, Iowa with this wife and son. He's currently a lead engineer at Vox Media working on the Concert Platforms team. He enjoys solving complex problems and experimenting with new technologies.

Rate this Article