What is edge side scripting?

Most CDNs have either launched or are working on edge-side script projects. But what is it and why does it matter?

If you follow the CDN landscape, there is a lot of buzz around deploying functions as a service that run on the edge servers… at a CDN point of presence. So rather than having to go back to the origin to run logic, it can do it right from there.

At first that might not sound that important, but through the course of this article I hope to explain it better and why it matters. But first let’s start by how a CDN operates.

This is what a normal request looks like without a CDN. The user traverses across the internet (a bunch of hops) to finally get to the server that has the file they are requesting. The server then responds with the file and it traverses back across that path back to the user.

This distance between the user and the server causes latency. The user notices it by a little sluggishness of your site. Your server notices it because it’s gotta handle all of the requests from each and every user.

If we get a CDN involved, they have servers all across the world. These are called PoPs (points of presence) or edge servers. They will cache your content on the edge, which will be closer to the user.

The first request for a given file doesn’t really help us out much. The request still has to go back to your server (called the “origin”) because the edge doesn’t yet have a copy of it (this is called a “cache miss”). Then the file is cached on the edge before ultimately being returned to the user.

However, the second request for that file looks like this…

That same user or a different user requesting that same file, now only has to get to the edge server. The edge says “oh I already have a copy of that!” (this is called a “cache hit”) and can respond with it immediately.

The user notices a significant speed-up of your site. Your server is happy because it notices a significant decrease in the number of requests it needs to handle. Sweet!

The problem is traditionally that CDN edge is just a dumb cache layer. It just determines if it has the file or not. It will give it to the user if so, or go back to the origin to request it if not.

This works fine for static files like CSS, JS or images where you are going to serve up the same file to the user regardless. But what if you need to customize the response or need to implement security on it. Some users should be able to access the file and some should get access denied.

So for those non-static type files you still need to have your server shoulder those requests. The user has a slower experience and your server continues to get clobbered. Bummer!

Because if we don’t do that, one user may have access to the file. It gets cached at the edge and next user (who shouldn’t have access) will just get a copy of it. That’s no good.

Or inversely, the first user to request it gets an access denied response. The edge caches that… and your valid user now gets rejected! Now they’re calling you all pissed off and ain’t nobody got time for that nonsense!

Wouldn’t it be beautiful if you could run just a little bit of your site’s logic at the edge server? That would solve all of our problems. Then you could still get the benefits of caching that file in the CDN layer, but still run those checks to protect your content.

Ahhh…. see now you’re starting to get it! That is just what this edge side scripting allows you to do, but that’s just the start.

Before we continue, someone’s going to argue CDNs have had some rule engines for a long time. That’s true but these rule engines have been limited and cumbersome. They might let you do some logic on a small set of pre-defined rules through their user interface… but you couldn’t actually run your own logic or do things more advanced (or it was really hacky and ugly to do).

Usually that content protection involved going to your server’s API, getting a token, returning that to the user, and then requesting the actual file you want with that token. This still requires a trip to and from your server AND then a follow up request after that to get the content. Not my idea of efficient.

So that’s why you want to be able to do it inline with the request for the content. It will simplify your site’s logic too + better separation of concerns.

These edge side scripting services allow you to run that logic at various points in the request life cycle. Above you see we are running the request as it comes into the CDN. This is where I find is most often the place you want it.

Running it here allows you either modify the request before it looks for the file. Alternately (as in our content permissions example earlier), this let’s you enforce authentication on the file. You can intercept that request to return a 403 immediately for non authorized users, but allow authorized users to continue on to get the file.

So this script sits between the user and the edge.

You can also run the logic between the edge and the origin. This script would only execute on a cache miss. If the CDN already had a copy of the file, it would just return it. But if it doesn’t and needs to fetch it from the origin this would engage right before it actually does that fetch. So you have a chance to modify that request first.

To me this use case is arguably the least useful. But I’m sure there are situations where it would be valuable. Maybe you are actually storing the file at a different path from where the user is requesting it, so this can be kind of a router layer to change the request path to the origin.

Next up, you can run the logic between the origin and the edge. So this will be after the origin responds with the file, but before the CDN actually saves it into cache. This would let you modify the response that gets stored at the edge. This is another one that I don’t find exceptionally useful, but I’m sure there are times when it makes sense.

Finally, you can run the logic between the edge and the user. This is your final chance before the response is sent to the user. It is already cached on the edge server, but you can modify it before the user sees it.

This could potentially make sense if there are some custom variables that you want to replace for that specific user. Maybe you have a section with the user name if they’re logged in or “Click here to login” if not. You could potentially do some replacement on that response body for that specific user, while the CDN caches the generic copy.

Because on the next request, the CDN will already have it and can respond right away… and yet you can still make changes to it before the user gets it.

There may be other times when you want to cache a generic full copy of the file on the CDN edge based on the path… but based on the query string, you might actually want to filter some of the response. You can do that!

The three best CDNs with this capability today are Amazon’s Lambda@Edge, StackPath’s EdgeEngine, and Cloudflare’s Workers. With all of those you can use Node scripts. You can somewhat do this with Fastly, but you will be limited to Fastly’s Varnish Configuration Language (VCL).

I hope this helps. Now start imagining all the potential use cases. Have fun!