The Practical Case for TanStack Start on Cloudflare Workers

Summary

I was recently given the challenge of migrating one of my workplace's web applications off of NextJS and explore our platform options.

At Tightknit, we do our best to stay tuned in to the movements that affect the developer community: acquisitions, company mergers, and fat checks supporting open source projects. One such movement causing waves is Cloudflare's explicit support for TanStack to run on their Workers platform. Having long been invested in the Workers ecosystem, it was an obvious combination for us to explore, one that promised to bring competitive advantages to the business.

The first step was to create a proof of concept and, after that, validate the complete solution. The POC itself was quite simple: create a new project and migrate one or two screens. The process was smooth, especially with the support of AI, something we embrace responsibly in our software engineering process. Even within converting just a few files, we began to notice significant differences compared to Next, the most important of which I’ll list below.

Clearer Page Lifecycle

In NextJS, the page lifecycle is not obvious and a serious point of struggle for newcomers. The React lifecycle has gone through many iterations to reach the maturity it has today, and yet… you will encounter obscure boundaries, such as where metadata ends and the page begins, or where files and the router fit into the mix. This is a result of Next’s evolution over time from frontend framework to full stack platform; it’s very difficult to avoid creating these "quirks" along the way.

Enter TanStack. In TanStack, you get much clearer definitions coming straight from the file router, where you can explicitly define things like validations, data loading, what goes in the , what the component is, and more — all hierarchically and type-safe.

Why? Because TanStack is not considered a framework, but rather a collection of libraries that help you build React applications. One of these libraries is the TanStack Router, a file-system-based router that makes everyone’s lives simpler. For those accustomed to NextJS and its directory-based router, you won't have trouble with the TanStack router. It works basically the same way, with some minor syntax differences, mainly in how files are named and how route variables are retrieved.

Vite: A Very Welcome Addition

Another great advantage TanStack brings is the use of Vite. While not directly related to TanStack, it is the build tool of choice in TanStack Start, which is a package of recommended libraries for a project using TanStack—almost a framework.

Vite, when running in the background with npm run dev, allows changes we make to the file structure to be reflected in TanStack's TypeScript immediately. So, for example, if you add a new route file named about.tsx, that route instantly becomes available to be consumed in the code in a completely type-safe way.

It also brings benefits in the reverse direction. For instance, when you create a route file, it handles the scaffolding, filling it with the basics needed to create a new route.

RPC Calls

The biggest surprise benefit was: the ability to make direct calls using Cloudflare Worker service bindings.

In our web app, most pages are rendered using SSR. With TanStack, our actions or data loading are done through calls to server functions, which in turn call Cloudflare workers using RPC service binding calls.

This configuration brought absurd speed to data loading because the RPC protocol is much leaner than the HTTP protocol, not to mention it doesn't carry all the overhead related to NextJS server actions.

P.S. Did you know Next server actions are executed sequentially?

The Weak Points

But it's not all sunshine and rainbows. We had some losses we had to work around when using TanStack.

The biggest one, without a doubt, was losing the image generation offered by Vercel using vercel/og—for Open Graph images, for example. Our solution was to create a new worker dedicated to image generation at the Edge layer of the application, closest to the user.

This is definitely a workaround—a bit of a hack ("gambiarra")—due to the fact that TanStack doesn't bring any first-party library for image generation. However, the workers-og library works very well on Cloudflare, runs on the Edge, and delivers satisfactory image generation results.

Other smaller, though less relevant, drawbacks included having to learn a completely different cache management system, as well as the debugging tool that loads in localhost applications. It works very well and brings different tools, but the keyboard shortcut naturally conflicts with the macOS screenshot shortcut, forcing us to customize the shortcut for a better experience.

Conclusion

The final result is that we now have a much faster application than before and a stack that is much more integrated into the Cloudflare infrastructure.

I have nothing against Vercel or Next.js. Both brought significant improvements to software engineering and the way we build web applications, delivering the most solid developer experience we've seen in recent years.

We simply reached a point as many do where your application grows and as your traffic scales, and it comes time to evaluate vendor lock-in before finding yourself hostage to a single vendor's ecosystem and pricing model. This migration wasn't just a technical swap, it was a strategic move to ensure our stack supports our growth.