Feedback on Cloudflare integration

[alexturpin]

Hey folks,

I'm really excited for Waku as a minimal React framework, especially in the context of Cloudflare Workers. The existing solution in my mind (Next.js and Remix) are either too heavy or too opinionated (or both!). Every other framework under the sun has a lightweight solution that deploys well to Cloudflare, and I'm hoping Waku is going to be it for React.

I was discussing the latest release with Daishi on reddit, and how I was waiting for API routes to adopt it for my project. However, upon reading the internals of the Cloudflare plugin and learning that it uses Hono, I want to say that I'd be more than happy to just leverage the Hono router for my API routes if I had this option with Waku. I imagine this would mean also seeing the routes that render React via Waku in my router, and I'm okay with that too, I appreciate that level of control and it's reminescent of vite-plugin-ssr / Vike, only with a bit more clean of an API.

I have to admit this is similar to this thread #847 but wanted to still chime in with my perspective.

[dai-shi]

Hi, thanks for opening up a discussion. Tagging people who might be interested: @jkhaui @rmarscher @dario-piotrowicz

just leverage the Hono router for my API routes

If you can clarify your requirement, that would be helpful.
I'm planning to work on #329 in a couple of months, but this is will be endpoint inside Waku (and its router), which is not tied to Hono.

If you want to use Hono router, it's technically possible already as of now, because Waku is essentially just one Hono middleware.

waku/packages/waku/src/cli.ts

Lines 150 to 166 in 49d1ae7

	const loadEntries = () =>
	import(pathToFileURL(path.resolve(distDir, DIST_ENTRIES_JS)).toString());
	const app = new Hono();
	app.use(contextStorage());
	if (values['experimental-compress']) {
	app.use(compress());
	}
	app.use('*', serveStatic({ root: path.join(distDir, DIST_PUBLIC) }));
	app.use('*', runner({ cmd: 'start', loadEntries, env: process.env as any }));
	app.notFound((c) => {
	// FIXME better implementation using node stream?
	const file = path.join(distDir, DIST_PUBLIC, '404.html');
	if (existsSync(file)) {
	return c.html(readFileSync(file, 'utf8'), 404);
	}
	return c.text('404 Not Found', 404);
	});

(Maybe we can consider config.unstable_honoMiddleware to inject custom hono middleware.)

[rmarscher]

Yes, there are some new capabilities to extend Hono coming in the next release of Waku. It looks like it should be released to npm soon 🤞

There is a new unstable_honoEnhancer option coming for waku.config.ts. I'm using that to add bindings via wrangler/miniflare during local development. See the linked gist at https://github.com/dai-shi/waku/blob/main/docs/guides/cloudflare.mdx#setting-up-local-development

You can test your builds locally with wrangler pages dev dist too which is useful.

I need to update the guide on how to access hono/context-storage. That just changed in - #914. You can use service buildings and invoke them from your server components to access other cloudflare workers without an API - just using React 19. I've been trying to build my new apps that way. We aren't exposing the website API as a product. I can deploy a separate API via a dedicated Cloudflare Worker and use a service binding to my Waku project and invoke it from server components / server actions.

It would be nice to have something like unstable_honoMiddleware too -- but maybe we just need to add unstable_honoEnhancer support to the deploy plugins? I haven't tried that yet.

Overwriting the handler entirely with a custom function can be useful to access the entire capabilities of Cloudflare Pages. https://developers.cloudflare.com/workers/runtime-apis/handlers/

The output for the cloudflare deploy adapter has a dist/_worker.js/index.js file that looks like this:

import server from './serve-cloudflare.js'

export default {
  ...server
}

It is feasible after running waku build --with-cloudflare to overwrite that file with your own Cloudflare Pages handler and import the default fetch handler from ./serve-cloudflare.js. We could also export app from serve-cloudflare.js so you could import that from your custom handler and adjust the hono app. Or maybe export the waku middleware runner so it could be created and attached to routes in another Hono app.

[rmarscher]

^ you could also use something like sed or ast-grep or another tool to patch your serve-cloudflare.js file after the build and switch const app = new Hono(); to export const app = new Hono(); - or just inject your own code. With the caveat that this all could likely change rapidly before v1... if you open dist/_worker.js/serve-cloudflare.js, you will see it is pretty straightforward and not hard to patch for now.

[dai-shi]

It would be nice to have something like unstable_honoMiddleware too -- but maybe we just need to add unstable_honoEnhancer support to the deploy plugins?

Hm, actually, the current unstable_honoEnhancer is capable of appending middleware. The only missing case is to prepend middleware. I think I would like to tweak unstable_honoEnhancer instead of introducing something new.

[dai-shi]

👉 #919

[rmarscher]

I added a bit more here #923 - I'm trying to get it to work when deployed to Cloudflare.

[alexturpin]

Thanks for all the feedback folks. My requirements aren't particularly special; I just want to be able to have routes that run code and return arbitrary responses instead of rendering React. To that end, Waku's own implementation of API routes might be more than sufficient. However, I do already use Hono in the project I want to convert to Waku, and so when I heard of the Cloudflare integration using it under the hood that just felt like an easy solution. Of course this won't help anyone deploying elsewhere, so I understand the approach of prioritizing the framework's own API routes.

The only advantage to leveraging a Hono middleware for me would be to keep full control over my worker's script / rendering loop, which is appealing but maybe more for feelings reasons than anything else, especially if it's possible to do middlewares and such otherwise. I'm a big fan of the Cloudflare infra but sometimes it requires patching in things like how Rob is implying for bindings, and that full control is always nice in those cases when it isn't natively supported by the framework. Sounds like you guys are on top of it though and intending to be a good home for React on Cloudflare.

I should also note that Hono is trying to have its own React renderer as well, and my last attempt was to use that so that may be why I have a bias towards a solution that integrates with Hono. I couldn't get it working with react-three-fiber however, which I need in another project, and the development over here seems much more active.