By “everything important”, I mean hitting APIs. It’s not that I don’t think it’s a neat idea to pre-build and CDN-serve an HTML shell page and then make a fetch request for data that you then template and render (it’s kinda neat, good job kids). But don’t fool yourself into thinking you’re really a CDN-hosted site and you’re being as fast as you can be worldwide. Your Australian users are still hitting some server in metaphorical-Oregon (US-WEST-2 or whatever) for the data-that-matters and it will be slow.
Can you build APIs that are multi-region? Sure! I mean, you can, I can’t. It’s hard and it’s pretty far outside my wheelhouse. But as things tend to do in developer land, hard things tend to get easier and cheaper over time. We’re at a point where doing actual multi-region work is getting cheap and easy, and it’s largely being ushered in by Edge Functions. Andrew Walpole has a nice recent blog post about what (and where) they are right now.
I tried to put a point on this in a recent talk:
So lemme make the point again with my slides. Here’s me in… the Yukon Territory apparently. And there’s Paul Hogan down under. Here is a super cliche stock photography example of a CDN. Look! There are servers all around the world that are geographically close to large populations! Thanks, Shutterstock.
If you completely fully statically render a website, like you might with a blog or documentation site, then probably yes, your site can be entirely CDN hosted and fast-in-Australia.
But Jamstack, to me, pretty much implies that APIs are involved. The “a” in Jamstack (the first one, sickos) use to mean that back when it was an acronym but we stopped using JAMstack because it was cheezy and not helpful. But anyway. Jamstack = doing more than just pre-building only.
And APIs are more often than not “single-origin”. Like good coffee and scotch, they come from one place. So here we’re both getting content-that-actually-matters from like some server in Amsterdam or whatever. Not actually close to either of us, like we would want from a CDN. Content delivery network, smh.
S0ОଠＯOOＯOОଠଠOoooᵒᵒᵒᵒᵒᵒᵒᵒᵒ, what?
How do we get that content to edge nodes? I don’t know really. That’s where you come in. Invent stuff, please. Or tell me about things that already exist. I do know about one thing that exists: Cloudflare K/V. K/V means Key/Value, so it’s not like a full-on relational database or whatever, but I imagine you can make a K/V store do a lot of work if you had to. The magic of it is that K/V data is somehow instantly replicated on every Cloudflare edge node. So the data is actually geographically close to Paul Hogan and other Austrailians.
But speaking of Cloudflare, I also like using their Cloudflare Workers product, because it’s capable of running JavaScript at edge nodes also. You gotta use them anyway to get your hands on that K/V data. But say you don’t actually wanna keep your data in K/V, you just need to keep it on your sad little Amsterdam single-origin server. You can still use the Cloudflare Worker to do the fetch to that single-origin server for you. I’m going to repeat that: you can still use the Cloudflare Worker to do the fetch to that single-origin server for you.
Why does that matter? It matters because rather than your dinky little computer making an HTTPRequest for the content on your dinky little internet connection in bumbleweeds Australia, you’re making superservers on the world’s fattest internet pipes do it for you. Then you’re injecting the content into HTML before it even arrives at the browser for the first time, so there is no janky-ass Cumulative-Layout-Shitting garbage that happens.
So instead of solving the problem via data replication (which might be a little wasteful tbh), you are solving it by making bigger computers do work for you. It is pretty cheap too.
That’s my whole point, enjoy.
