Week notes: one request instead of twelve, and throwing things away

I opened the network tab, clicked into my own club house, and counted the requests. A dozen-ish. Tasks, morale, standings, matches, finance, press, staff, cup context — each one a polite little GET, fired every single time anyone visits the page they visit most.

On a laptop next to the server you don't really notice. On a Raspberry Pi serving someone on a phone in another country, you notice. And a club house that shrugs and sends twelve requests teaches the wrong thing about how much care went into the rest of it.

So desktop gets one bootstrap response with all of it in it. Mobile keeps its own leaner bootstrap, because a phone doesn't render half those widgets and shouldn't pay for them. Then the same treatment for the other heavy areas — finances, transfers, tactics, training, staff, squad — one route-level call each instead of a fan of them.

On top of that, stale-while-revalidate, wired consistently through the HTTP cache, the store persistence, and nav prefetch. Coming back to a page you were on ten seconds ago should feel instant, and it does. But it revalidates behind the scenes rather than trusting itself indefinitely, because a cache that never refreshes isn't fast, it's just confidently wrong.

The trap with this pattern is drift. A bootstrap that returns its own bespoke shape for, say, a match will eventually disagree with the shape the list route returns, and then a widget explodes on a field that's spelled differently in two places. So the bootstrap match payloads map to the exact shapes the list routes already use. It means the bootstrap contract has to change whenever a widget grows a field, and I'd rather pay that than debug a page that only breaks on Sundays.

Also spent a chunk of the week deleting. A dead-code pass across the inventory, removing what was verified unused — with the ops and API surfaces I actually intend to keep left alone, even where nothing currently calls them. Anything merely suspected dead stayed. Deleting on suspicion is how you create a support ghost for yourself six months later, and there's nobody else here to ask.

And then some access-control and public-surface tightening. Ownership boundaries, what one manager can learn about another, ops endpoints that had no business being reachable. Less accidental omniscience.

That's as much as I'm going to say about it, on purpose. This diary is a public site. A write-up that lists which endpoints were open and what they leaked is more useful to someone probing the game than to anyone reading for the engineering, so the outcome is the whole report: it's quieter now.

Which leaves a much better stage for the youth work I've been circling for weeks — richer pages I can afford to build, because navigating no longer charges rent.

Till next time,

Oladapo.