Build static site at the edge to dramatically speed up build latency

[mb21]

This may sound like a crazy idea, and I haven't found anybody doing this on the internet. Perhaps my google-foo is failing me, or perhaps it's just a stupid idea. If so, I'd be very interested in knowing why.

I was reading this Deno Deploy post where they advertise how great their v8 isolates are because they're already running and how most other CI systems (like GitHub Actions) spend most of their time starting the Docker image and downloading dependencies, and not on doing the actual build. This makes a lot of sense to me.

But while that post seems to advertise this approach for dynamic edge functions (e.g. Deno Fresh), surprisingly there is nowhere a mention of building a static site (e.g. with Lume). More googling brought up Static Files on Deno Deploy, but there they are using GitHub Actions again to call deployctl to upload the files to their CDN (because while you can use Deno.readFile etc. to read from the Deno CDN, you apparently cannot write to it that way). Thus you pay the VM startup time again.

Hence my question: has anybody tried building a static site at the edge (e.g. in a CloudFlare worker) and then upload the artefacts to a CDN? Potential obstacles:

• lack of a normal filesystem (but could use a virtual one like the Origin private file system)
• lack of official REST API for uploading to CloudFlare CDN, but perhaps there are other CDNs that have one?

Perhaps the static site generator would need to be rewritten a bit to work on the virtual file system. But assuming that would work: any other show stoppers? Would we really get static site deployments in the one-digit seconds?

Posting this here, as I thought this crowd might have thought about these things already. But happy to be pointed to a place that fits the question better.

[oscarotero]

I'm not sure to understand.
The edge is just a marketing term to define a CDN that not only serve static files but also run some code on the server. Like a CDN, it requires different replicas or nodes around the world in order to process your request as close as possible to your location. This is why Deno Deploy cannot write on the disk, because it would write only in the disk of the current node, but the other nodes wouldn't have these changes. And syncinc changes between all nodes is hard (they have Deno KV for that).

For static sites, the build process is not important, because it's run only once. Then, the static site is replicated in different nodes and this is what make them so fast.

In my experience, services like netlify are more performant than Deno deploy if you only have static files, because are specific for this. Only if you need some server-side processing (like providing an API or handle form submits) you need to use "the edge" (and Deno Deploy is a good option here).

[mb21]

Thanks for the reply!

The edge is just a marketing term to define a CDN that not only serve static

Right. And I'm not talking about using "the edge" to serve dynamic responses. I'm talking about abusing an "edge" function to run a static build and then upload the output of that to the traditional (static) part of a CDN.

My goal would be to decrease deploy latency to something like a few seconds. Currently, it takes around 1-5min to build something on Netlify for me (mostly waiting until a VM is available and started up).

[oscarotero]

Ah, got it.
A step of the build process that takes some time is the installation of the dependencies. Using a cache layer helps a lot. I've been using it in Netlify and GitHub Actions successfuly.

Waiting for a VM is more difficult. Probably a paid tier give more priority and builds starts sooner. I don't know.

Local build + rsync is probably the fastest way to deploy but I guess you're looking for something more automatic. Maybe you can use a webhook to trigger the build + deploy from a server you own.

I don't think the edge (specially Deno Deploy's, I don't know others) can help here. The Deno's version of Deno Deploy works differently than your local Deno CLI. Deno Deploy must know in advance all dependencies and all files that your app needs, and with this info it creates a snapshot with all these files precompiled and ready to run. If you have imports that cannot be analyzed statically, they won't be included in the snapshot and your app won't work on Deno deploy. For example:

import(`./folder/${filename.toLowerCase() + ".ts"}`);