[gvand]

Nice project.

As an aside, I genuinely wonder under which circumstances a CDN will be useful for a static website nowadays. I have a static website that has been on the HN homepage a few times and got picked up by the Chrome mobile recommendations and a nginx/https with slightly tweaked configuration never had a problem handling the traffic even on the smallest DO droplet.

Edit: Thanks for these replies.

[Xylakant]

The CDN makes the site load faster by caching the content on edge nodes close to the client. It’s not for taking load off the origin, but purely for network latency.

[toredash]

And by caching it you will reduce traffic to origin.

[Xylakant]

Certainly, but for static pages the traffic to the origin is not a primary concern except for really large amounts of traffic.

[zachruss92]

What I like about static sites is that you can serve the site in its entirety from a CDN. So you can literally just CNAME www.yoursite.com to yoursite.gitlab.io (or w/e static site host you use). This dramatically cuts down on latency worldwide. It also removes your web server as a single point of failure for short-term outages.

[dvfjsdhgfv]

> you can literally just CNAME www.yoursite.com to yoursite.gitlab.io

After so many years I still can't really understand how easily people hand over almost complete control over their site to someone else, just because everyone else does. It's like handing over your e-mail account passwords when LinkedIn started. Yes, CloudFlare, Google and others are helping you, but there is a price to pay that might not be immediately visible.

[acdha]

It seems pretty different from a password because you're not giving control of your domain: if they broke their contract, you could take it back at any time.

That's the other odd part about this complaint: you're trusting a company like GitLab not to break their terms of service, which is a potential factor to consider but also one where they'd have severe negative outcomes to their business if they went rogue. Since you're already trusting a number of other parties, why is this one so much scarier?

[nybble41]

> It seems pretty different from a password because you're not giving control of your domain: if they broke their contract, you could take it back at any time.

You are giving them everything they'd need to obtain a DV certificate for your domain, though. You can stop them from using it at any time just by changing the DNS records, but you'd need to wait at least two years (825 days for maximum TLS certificate duration) before you could be certain any certificates they had been issued before that point had expired.

[cortesoft]

How would you do it without trusting a third party?

[donmcronald]

You can get some nasty cold starts though. Here's a domain I have that doesn't get any traffic (literally zero):

https://imgur.com/a/dVPQYKC

The first hit is brutal. I won't say the CDN since I'm not an expert, but it doesn't take long to go cold (minutes) and once it's cold even the cached hits are 400ms.

Is 400ms really a dramatic reduction in latency?

[tedshroyer]

The technical reason to use a CDN with aws s3 is so that you can have a custom domain name with https. s3 will do http custom domains, but to get https you proxy it. In this case, you can think of Cloudfront as the proxy.