CDN types and setting them up (Vue, React)

By Karolis Rusenas · Aug 27, 2020

CDN

What is CDN? Cloudflare has a nice explanation here: https://www.cloudflare.com/learning/cdn/what-is-a-cdn/

In short:

A content delivery network (CDN) refers to a geographically distributed group of servers that work together to provide fast delivery of Internet content.

In this article we will have a quick look into several CDN types and potentials pros/cons that you might encounter when setting one up yourself.

Cloudflare is one of the best CDNs out there and we are using it for our landing pages and numerous other projects. It’s a great DNS configuration service too that provides rich APIs. However, it’s good to understand what other types of CDNs are out there and which suits you best.

CDN types

All CDNs have different pros and cons and all solutions are trying to achieve the same thing: load content faster.

Reverse proxies with caching

Some of the CDN types you will encounter in the wild:

  • Cloudflare type proxies that forward all incoming traffic to your origin servers and cache as much as possible.
    Pros:
    • Ease of use. Your application doesn’t have to be aware of the CDN itself. If you are using Cloudflare as a DNS provider you just click on the button and their servers start intercepting all traffic and caching it. On top of that, they offer a bunch of other useful services like firewalls, “page rules” that can redirect
      Cons:
    • Can be caching too much (you don’t see updates once you push because index.html is also cached).
    • Since they are terminating connections, if they go down together with your DNS control, it becomes harder to recover.
    • Lack of control from your side and potential security implication of allowing 3rd party to terminate TLS for you.

Push CDN

Push CDN

Push CDN is a setup where you upload your assets to a server (or a group of servers). An example of such CDN is Google Cloud CDN. In this setup, you will have to create a load balancer and a storage bucket and upload your content assets as part of the CI/CD pipeline where you build your frontend app. In this setup, you will need to create a new domain such as cdn.example.com that points to your CDN storage location.

Pros:

  • You remain in control of TLS termination and have a better understanding of what content is presented when. If your frontend app uses unique IDs for the static assets, for example /js/chunk-2d22502a.0844b32d.js.
  • Main file index.html is served by your server so it can always point to the most up-to-date js/css files.
  • You can know exactly what’s pushed to the CDN.

Cons:

  • You get a new step in your CI/CD pipeline that can fail. If your frontend is deployed but assets failed to sync, your users might get a lot of errors. You also need to ensure that the CDN static files are not simply overwritten (as you might overwrite them while the old frontend app is still using previous files).

No CDN

No CDN, just cache control headers on your web server. This option might work for many cases, however, the first load can be painful if the user is far from your server location and you have a lot of static assets.

Pull CDN

Pull CDN

CDNs like BunnyCDN (affiliate link, great service) pull from your origin server but don’t try to proxy all your traffic. In this scenario, you serve your index.html that then loads assets through the CDN domain instead of your own. Similarly, as with the “Push CDN” type, you will have to either serve assets from cdn.example.com, or if you have a fancy global load balancer, you can configure that certain paths load files directly from CDN servers.

Pros:

  • Ease of use. It feels like Cloudflare from the “setup” perspective. You only need to provide it with the address of your web server and then optionally configure your domain. It will pull assets and show nice stats.
  • Pricing. It seems like it’s a lot cheaper than other CDNs while providing an excellent service. They have some comparison info on their pricing page: https://bunnycdn.com/pricing, however you would need to test it for yourself as it may well depend on your content.

Cons:

  • Need to ensure that your assets have unique build IDs baked into the filenames so you don’t serve stale content. Fortunately, most modern javascript transpilers do this by default so in my case with Vue.js I didn’t have to do anything on this front.
  • If CDN would go down, even though your index.html loads, your assets would fail anyway. However, in this case, you would still be able to quickly change the assets domain to your main web server.

Setting up BunnyCDN (Pull CDN) in a SPA

I couldn’t immediately spot the docs but if you are doing this not for the first time, it’s quite straightforward:

  1. Create a “pull zone”. You will get your pull zone domain which is a reverse proxy to your origin web server:

Pull zone config

  1. (Optional but recommended) Create a CNAME from your domain to the allocated pull zone domain (in our case it’s cdn.webhookrelay.com -> webhookrelay.b-cdn.net). This enables you to load assets from your domain name.
  2. Update your webpack config to add asset file prefix. Example for vue.config.js would be:
module.exports = {
  publicPath: process.env.NODE_ENV === 'production' ? 'https://cdn.your-domain-here.com/' : '/',
}

If you are using React, check out “Public Folder” docs here: https://create-react-app.dev/docs/using-the-public-folder/.

That’s it, generated assets will all have the prefix to load through the CDN. If you are using Nginx to serve your app, ensure that you are providing correct headers for js and css files. For example:

location ~* \.(?:css|js)$ {
          expires 1y;
          add_header Cache-Control "public";
          access_log off;
        }

I hope you will find this useful whenever you decide to add CDN for your website!