/ Case Study

Why jsDelivr Uses 2 DNS', 4 CDNs, and Fly

jsDelivr is free multi-layered CDN that specializes in delivering static assets for open-source projects to users all around the world. If you have assets on GitHub, NPM, or Wordpress, you need only construct a URI to serve them securely from a fast, multi-layed, global network. Fly has teamed up with jsDelivr.com, a network that services 19 billion HTTP requests every month.

Progressively Redundant

To grasp the reliability of jsDelivr, let's walk through the life of an asset request. Depending on where the request is made from, your data may travel between one of 832 Points-of-Presence -- whoa! First, though, let's look at how it works.

If you have an asset hosted on GitHub, NPM, or Wordpress.org, you can CDN-ify it by appending the information you need within an jsDelivr URI.

// load any project hosted on npm
https://cdn.jsdelivr.net/npm/package@version/file

// load any GitHub release, although npm is recommended where it applies
https://cdn.jsdelivr.net/gh/user/repo@version/file

// load any plugin from the WordPress.org plugins SVN repo
https://cdn.jsdelivr.net/wp/project/tags/version/file

When you request one of these files, the first thing that happens is the DNS look-up. If you're constructing an uber-reliable network, this is the first layer you'd want to have fast connections and redundacy. That's just what jsDelivr has done. They have not one but two DNS providers to process the initial handshake.

Afterwards, DNS requests are routed to a Cedexis global load balancer then distributed to Content Delivery Networks' PoPs based on performance and uptime of the user's access service network and region, choosing between CloudFlare, Fastly, StackPath, or Quantil. Each one has 22, 48, 116, and 600+ PoPs, respectively. If the assets don't exist within the CDN, they're summoned from the core.

At the center of the redundant layers is the core, the heart; the jsDelivr applications. The jsDelivr applications live on a co-located Docker cluster hosted within Paris, France and Amsterdam, Netherlands. The servers keep cached copies of assets which are kept in-sync with Amazon S3.

If either server does not have the assets that the CDNs need in cache, they'll request them from Amazon S3. In this way, assets are kept up accessible and up to date, even if they're modified or removed from the source.

"The application itself is built using Node.js and does everything jsDelivr supports, like downloading and extracting npm packages, resolving version aliasing, combining files, minifying files and more."- jsDelivr

What if Amazon S3 bites the dust? If you're using GitHub or NPM then the assets are fetched direct from their source. There are an unfathomable number of permutations available when users request assets through jsDelivr. It's an impressive piece of multi-layered and highly available distributed engineering.

jsDelivr has an excellent infographic that you can look at to see the entire flow.

What - Exactly - Would You Say You Do, Here?

With four Content Delivery Networks, two DNS providers, a global software load balancer, and Amazon S3 backed caches, why is jsDelivr connecting their applications to Fly? With all the content delivery heavy weights threaded together to achieve maximum reliability and performance, what, exactly, is Fly doing?

the-bobs

"We use CleverCloud to host our website. Instead of deploying our website as a node.js app, like we used to do, we switched to deploying a Docker image. This allows us to install and use the wormhole app by Fly that automatically registers our app into the system." - jsDelivr

Fly is an Application Delivery Network, a bit of all those things; a CDN, a reverse proxy, a global load balancer; where it uniquely excels, though, is giving developers direct control of these underlying edge-server technologies.

Once a site has been attached to Fly, you can mount a growing number of secure applications, backends, and services, and attach them anywhere upon your hostname. Once connected, you have full control over routing and an ample library of useful Middleware for logging, server-side metrics, serverless functions, and more.

"This means that we are no longer relying on CleverCloud's native
load-balancing between instances of the apps and that traffic flows only to
alive instances." - jsDelivr

By applying our open-source utility Wormhole to their containers, jsDelivr spawns an encrypted tunnel between two end-points: the Fly PoP the client has reached and their applications. When two end-points are connected, the Wormhole session will allow traffic to flow from one end to the other.

If the session is in an error state, the connection to the end-point will desist. When that happens, traffic will flow to your other end-points without a hitch. With HTTPS securing traffic from client-to-edge, Wormhole keeps things secure and sane from edge-to-application.

The jsDelivr Dockerfile that they use to build their front-ends is public. It explains how they assemble their containers with Wormhole for immediate discovery and load balancing within Fly:

FROM node:8-alpine
ADD https://s3.amazonaws.com/flyio-wormhole-builds/0.5.35/pkg/wormhole_linux_amd64 /wormhole
RUN chmod +x /wormhole
RUN apk update && apk add git
ADD package.json /app/package.json
RUN cd /app && npm install --production
COPY . /app
WORKDIR /app
ENTRYPOINT ["/wormhole"]
CMD [ "node", "src" ]
EXPOSE 8080

Today, containers on CleverCloud. Tomorrow? Heroku, or perhaps something so nifty we can't yet fathom. Flexibility is paramount when you're building dynamic applications. If it's time to change services, Fly users need only add the new application, backend, or service, then direct their traffic where they see fit -- perhaps it's to a sub-folder on your hostname or a pre-defined trigger that enables Middleware to wake-up cloud functions or direct to new routes based on custom HTTP header values.

"This system allows us to run the website app anywhere we want and have Fly load-balance it correctly among CleverCloud, Heroku or local Docker hosting if we wanted to. We use Fly on our website and blog. It helps us handle 2million+ requests every month." - jsDelivr

Open-Sourcerer

jsDelivr is a project for the open-source community that was created by Dmitriy Akulov, who resides in Poland. Open-source projects are a ton of work. To help keep useful free services like jsDelivr running, developers rely on sponsorships and the talent of the global open-source community. Fly is proud to partner up with Dmitriy and jsDelivr. What are some of the best things about using Fly, we asked?

"Free SSL, unique load-balancing using a local agent to register, stats and
lots of config options." - jsDelivr

You can learn more about how you, too, can have One Hostname to Rule Them All by reading here. Fly is free to sign up, as are your first 2,000,000 requests and 100GB of transfer every month.

An example screenshot of one hostname with multiple backends on Fly

Kellen Evan Person

@thegoodroot

Kellen Evan Person

A polite, forest-dwelling Canadian who enjoys coding and writing. He's spent near two decades building web applications and strives to keep development fun and light-hearted.

North Vancouver, Canada