a920604a Labs: A Dual-Cloud Full-Stack Playground Integrating Four Tools with a pnpm Monorepo

Picture this: you've got four little side projects rattling around in your head. A to-do list. A habit tracker. An ebook reader. And — this one's my favorite — a resignation stamp collector, where you literally stamp a grid every time you fantasize about quitting your job. Four separate apps. And the tempting thing to do is spin up four separate repos, and reimplement login four times, reimplement your UI shell four times, and slowly lose your mind.

a920604a Labs takes the opposite bet. It folds all four into a single pnpm monorepo, and the whole point of the project isn't the features — it's the carving. How do you slice up a monorepo so that four apps genuinely share their authentication and their design system, while still being developed independently? And how do you let each one pick the backend that actually fits it, instead of forcing them all into the same box?

Let's start with the structure. The repo has three layers: apps, packages, and workers. Under apps you've got a folder called root, plus the four feature modules. Under packages you've got two shared libraries — auth and ui. And under workers you've got a Cloudflare Worker for the ebook API.

Now here's the key design decision, and it's a clever one. Apps slash root is the *only* build entry point for the entire single-page app. And root itself is almost embarrassingly thin — it does three things. First, a main file that boots up Firebase and wraps everything in the Chakra UI provider and the auth provider. Second, an App file that sets up routing, defines the navigation config for the modules, drops in the global shell, and wires up the four module routes. And third, a hub page — the home screen, with a little time-of-day greeting and four cards, one per tool. That's it. That's root.

So then what are the four feature modules? Here's the trick: they're library-only. Each one exports a single entry file — basically "here's my App component, take it" — and, crucially, none of them has its own Vite config. They don't build themselves. Root's Vite reaches out through pnpm's workspace symlinks and bundles all four in one shot. So instead of building four apps separately and gluing them together afterward, the modules get *assembled into* root. They all share one build config, one set of providers — but inside their own folders they're free to define their own sub-routes, components, and hooks. Independent development, unified assembly. That's the heart of it.

Okay, the two shared packages. Authentication lives in the auth package, and it deliberately exposes just a handful of things: initialize Firebase, get the auth instance, get the Firestore instance, an auth provider for React, and a hook called useAuth. That hook hands you back the current user, a loading flag, a sign-in-with-Google function, and a logout function. And that's the whole contract. Any module that needs to know who's logged in just calls useAuth — it never touches the raw Firebase SDK. One place owns the messy stuff.

The ui package is built around something called GlobalShell — a sidebar layout modeled on Apple's macOS design guidelines. And the important detail here is that GlobalShell hardcodes nothing. Its entire navigation is driven by a modules prop that the caller passes in — a list of items with a path, a label, an optional icon, optional sub-items, and so on. So the shell doesn't know or care what apps exist; you tell it. On desktop you get a fixed sidebar on the left and a top bar with that frosted-glass blur effect. On mobile it collapses into a hamburger menu that slides a drawer out from the left. And the active item gets that filled, rounded highlight, very Finder-like. The package also ships a login page, a nav bar, and a themed palette with Noto Sans TC as the font.

Quick tour of the four tools themselves. The to-do list syncs in real time through Firestore, with due-date alerts, tag categories, three different views — list, stats, and calendar — and rich-text notes powered by Tiptap. The habit tracker does daily check-ins, streak counting, and achievement badges, with a stats page that draws line charts, heatmaps, and bar charts of your check-in rates, plus browser notifications and PDF export. The ebook reader lets you upload a PDF, caches it locally in the browser's IndexedDB, and simultaneously syncs it up to a Cloudflare Worker backed by D1 — it remembers your reading progress and gives you a categorized library. And the resignation stamp: a hundred-cell grid where each click stamps a cell and logs your reason, with a progress bar, badges, a daily maxim, and — the finishing touch — a one-click generated PDF "resignation certificate." Cathartic software. I respect it.

Now here's the part actually worth writing home about: the backend strategy. Because a920604a Labs does *not* force every module onto the same backend. It mixes and matches based on what each one genuinely needs.

Let me paint the flow. The user hits the single-page app, which is served as static files from Cloudflare Pages. Login goes to Firebase Auth via Google Sign-In. For the to-do and habit modules, the frontend talks directly to Firestore through the SDK — that's where their data lives, and Cloudflare is doing nothing but hosting static files for them. The ebook module is the heavyweight: it calls a Cloudflare Worker, passing along the user's Firebase ID token, and that Worker uses the full stack — D1 for the database, R2 for storing the actual PDF files. And the resignation stamp talks to its own Worker that taps into Workers AI.

So if you laid it out as a grid: all four use Pages for hosting. Ebook and resignation stamp both use Workers. But only the ebook module reaches for D1 and R2. To-do and habit? No Workers, no D1, no R2 — just Firestore and static hosting. Simple things stay simple; only the module that needs relational data and file storage pulls in the heavy machinery.

And that raises an interesting question — if login is handled by Firebase, but the ebook data lives in Cloudflare's D1, how do the two clouds trust each other? That's the real integration point. Every endpoint on the ebook Worker demands an Authorization header carrying the Firebase ID token. Before the Worker touches D1 — before it lists your books, adds one, deletes one, or updates your reading progress — it *verifies* that token against Firebase. So the identity Firebase issued on the frontend gets carried all the way through to Cloudflare's backend for authorization. Firebase issues the identity, D1 stores the data, and each cloud does the job it's best at. That's cross-cloud auth done cleanly.

On the stack itself, briefly: React 19 with TypeScript, Chakra UI for components, React Router 7, Vite with SWC for builds, pnpm workspaces plus NX for the monorepo, Firebase for both auth and Firestore, IndexedDB for local storage, and Cloudflare Workers and D1 on the backend. Deployment runs through GitHub Actions — push to main, and two jobs fire automatically: one builds root and ships it to Cloudflare Pages, the other deploys the ebook Worker. All the secrets come from GitHub Secrets.

So let me leave you with the three ideas actually worth taking away from this.

One: a single build entry point plus library-only modules. Root is the only thing that builds; the four apps are just libraries that get assembled into it. That's what makes sharing feel natural instead of forced — one build config, one set of providers, four independently-developed tools.

Two: pick a backend per module, not per project. Don't over-engineer in the name of uniformity. Simple stuff goes straight into Firestore. Only the module that truly needs relational data and file storage brings in Workers, D1, and R2. Resist the urge to make everything consistent just for consistency's sake.

And three: identity and data don't have to live in the same cloud. Firebase can issue the login, Cloudflare can hold the data, and a verified ID token is the bridge between them.

Honestly, the rarest skill on display here isn't any single piece of technology — it's proportion. Share what should be shared, isolate what should be isolated. That sense of restraint is worth more than piling on tools, and it's exactly what most personal projects are missing.