Migrate from create-react-app to rsbuild & vitest, use cloudfare worker to server render meta

[yaodingyd]

Three major changes:

1. replace create-react-app with rsbuild
2. replace jest with vitest
3. add cloudflare worker to do server render with site specific meta info

The current app architecture is still the same, when testing frontend changes, we can still use surge to deploy static asset and verify. The change to production is instead of using firebase hosting for static asset, we use a cloudflare worker to serve and pre-render meta info, if applies.

The workflow change is instead of deploy to firebase, we will deploy the CF worker. I think we also need to wire up the domain.

This is very preliminary that CF worker will fetch and render everything. We could fetch all sites info, store them in KV (which also have free-tier and more than enough for under 100k read/write per day) so meta info is cached.

For reviewing: majority change is in snapshot. The part needs review is mostly worker.ts and all new config files

Feature highlights

• No app architecture change, still running as SPA
• No build step change
• One single server function (worker.ts) which reads index.html, replace meta info and serve it
• Minor change to deployment process

Testing

Testing url: https://aqualink.yaodingyd.workers.dev/sites/2919

Cost

The major cost would be requests for worker, and free tier has 100k per day, 1k per minute limit.
The static assets are free and unlimited.

So that means if the sites has under 100k page visit per day, we are good to stay in free tier and no cost added.

[ericboucher]

Thanks a lot! This is great work and we do need to move away from create-react-app

@K-Markopoulos actually started a transition to nextJS because we had the call to add page specific metadata. But he was hitting a few blockers. Do you have some thoughts on the matter? Happy to discuss over slack or email.

See #1085 and #1093

And the issue we'd like to resolve at the same time - #641

[github-actions]

Build succeeded and deployed at https://aqualink-app-1102.surge.sh
(hash e8d57ec deployed at 2025-03-01T23:12:46)

[yaodingyd]

First of all K-Markopoulos is doing an amazing migration work! However I'm wondering to use next.js just for its SSG output, considering the cost of allover architecture change, is the good fit here. Since we are not on Vercel, and I have no intention to migrating to, we cannot take advantage of incremental build, so each SSG is a fresh build for all pages. In that case, using a build tool (rsbuild/rspress) and keeping current architecture might be simpler.

Furthermore, I'm wondering if using SSG is good here, since we will regenerate all pages on every change and with sites increasing, the build job will also scale up. What if we use a cloud function to just replace the meta info in generated html? that way each specific page is only partially pre-rendered and that's the only change we need. We can only keep the staging preview functionality, only output one single build output index.html.

I'll try to test this hypothesis and update here with more results.

[yaodingyd]

https://aqualink.yaodingyd.workers.dev/sites/2919

Since I have no access to firebase and more familiar with cloudflare worker, I'll use CF worker as example, but totally transferable to firebase cloud function.

https://github.com/yaodingyd/cf-worker-aqualink/tree/master

It's pretty simple underneath but the main/sole function is this single one https://github.com/yaodingyd/cf-worker-aqualink/blob/master/src/index.ts and aims to serve static asset with pre-render headers meta info.

I think with this approach, we keep the current app architecture the same, and just add one function (might as well use CF worker to keep frontend and backend separated 😂 ?) to serve assets

let me know what you guys think

cc @ericboucher @K-Markopoulos

[ericboucher]

@yaodingyd I like it, and it looks pretty straightforward. Let's try it. Should we transfer the worker repo to the Aqualink app, or should I start an empty one? Let me know how you would like to proceed.

[yaodingyd]

I can move the worker setup into packages/website so they are colocated. I'll update this PR to have everything

[yaodingyd]

@ericboucher this is ready for final review