As you may already know, the first app to be released to the Edge Network was CDN, a web service written in Node.js which predates the network in its current form, and that has been used in production for over five years by a wide range of content providers, from low traffic microsites to international publishers. It's easy and quick to configure and comes packed a wide range of modifiers that provide comprehensive *just in time* asset manipulation, as well as CSS and JS compression. Its ability to rapidly crop, resize, compress, and reformat images and quickly serve cached resources made it ideal for an increasingly mobile consumer that expects high quality visuals with minimum delay.

When we first rolled it out into the network there was very little to change. It already had multi domain support, meaning a single instance could exist on each Host but be configured to support each domain slightly differently, with different sources, caching, and header configurations. CDN originally required its config to be stored on disk, so we added an endpoint that allowed it to be configured without a restart. If you've been running a Host in the last year, you've been successfully running a very powerful app that we are hugely proud of.

Those of you that have been paying close attention to the impact on your system may have noticed one rather glaring problem with CDN: it's huge. Well, that's not strictly true. It's ~500mb on disk, which isn't aggressively large, and certainly doesn't affect operations when running on a single machine, however in a network where a high level of distribution is required, and where available disk space per device is relatively low, it can become a limiting factor.

When we release a new build of CDN, 390+ devices globally all need to pull a 0.5GB docker image. That's 190GB from the registry for every release, and that just doesn't scale. And on a 16GB machine that's ~3% of the entire volume just for a single application. Those who have followed the more technical posts from the team will know that the network applications are primarily written in Go, and those that have been following the project since the early days may remember that the original prototype for the network was actually written in Node.js. Switching to Go wasn't a difficult choice. It's stricter, faster and more efficient than Node, and the resulting binary is far smaller.

Much of the logic from the Node.js build of CDN was so clearly written that the run up to rebuilding it in Go was far less daunting than we originally expected.

Feature migration

The Node.js build of CDN was built for a very different production environment, so migrating to Go was the perfect juncture to take stock of which features to carry over and which to drop. Here's a short breakdown.