Content delivery network (CDN) is my recommended way of serving statics because of :
1. Separation of concerns
Meat of the app is on the main example.com, assets are on a subdomain like cdn.example.com.
2. Cookie-less domain
Asset domain remains cookie-less, e.g. cookie based authentication only bloats domain.com requests === faster response times. With the use of http2, and lately http3, header compression comes in play. Worrying about cookie-less domain is not that important like before. If your site is behind Cloudflare, it already benefits header compression using hpack.
3. Faster delivery of assets
Cdn delivers your assets faster, as it functions like a network of servers all around the world, where the nearest one serves the response. If your site is behind Cloudflare, it already benefits from asset caching .
4. Beanstalk rebuilds
This reason is specific to my nextjs apps hosted on elastic beanstalk. Every nextjs build creates new hashes for statics. Every beanstalk version deployment clears old files. And that leads to 404 when search bots or visitors request old files (e.g. browser caching). I’d like to avoid that with cdn over s3 caching. If not for anything, because I hate to see ugly 404 logs on webmasters search console.
How do Cloudflare and Cloudfront differ?
Talking about one or the other, they sound too similar. Why not just pick one then?
How I see it, Cloudflare’s primary focus is to be a reverse proxy for your domain server, hiding your server’s real ip. Then it can protect it from various kind of attacks, most common ones are DDoS. It offers a secure and fast delivery of your content to the final consumer. You can configure it to cache your assets, and caching is enabled by default. Due to caching and some other optimizations like hpack compression, Cloudflare delivers results really fast. Well, Cloudflare currently offers much more than just being a reverse proxy.
On the other hand, Cloudfront is a CDN, but just a traditional CDN. It can be configured as reverse proxy to your origin server. You’d just configure dns records to point your www and root domain CNAME records to the Cloudfront domain. Primary focus is fast delivery of assets in same logic as Cloudflare, with the help of multiple datacenters around the world. Nearest one to you delivers the content. And you know how latency is important if you’ve played video games.
I’d use them together – Cloudflare for security/dns mapping/firewall/proxy and Cloudfront as a traditional cdn.
Again, separation of concerns and I’m already using aws stack.
Is Cloudfront Push or Pull Cdn?
I can see some of the sources state Cloudfront can be configured to push the resources to it.
I’m not sure it’s like that. When you request a resource from Cloudfront then:
- if resource exists, Cloudfront delivers it from cache
- if resource doesn’t exist, Cloudfront asks origin server, where origin server pushes response to Cloudfront, and Cloudfront caches and delivers it.
New resource can be requested only if caching expires or you explicitly request Cloudfront resource invalidation.
Cloudfront Origin Server
Most used recipe for Cloudfront cdn is with S3. Data from origin server pushes the data to S3, Cloudfront requests the new data from S3 and delivers to the consumer.
But you don’t have to use S3. You can directly point Cloudfront to your origin server.
I’d still stick to S3 for resilience. What if your server’s down, and again, separation of concerns. Push static data to S3, business logic on server.
Now that I shared my point of view, would you pick both Cloudflare and Cloudfront, just stick with one, am I overengineering?
0 Comments