Live data from Hacker News

Unpkg CDN down causing dependent website outages

github.com

31–39 of 39 posts

Re: Unpkg CDN down causing dependent website outages

#31
post #15

Earlier quoted context omitted.

It is because the data (web logs containing web pages, timestamps, ip addresses, cookies, etc) can be sold.

It's also because the big reputable third party CDNs are more reliable hosts with better uptime and SLAs than many of the sites that use them.

Nonsense. Your site is obviously running if it served the page that wants the fonts, so there's absolutely no way they're more reliable than the site that uses it.

Meanwhile, that third-party is effectively paying your bandwidth bill: You might want to trade some reliability in exchange for a lower bandwidth bill, but you should wonder why exactly that third-party is willing to pay your bandwidth bill at all.

Re: Unpkg CDN down causing dependent website outages

#32

This is one thing I never understood about web development. I would have thought the risks from 3rd party production dependencies would make devs do all in their power to minimize them. But IIUC it's a somewhat common practice. Is there something about the market dynamics that make this a reasonable tradeoff? E.g., the problems are rare and this somehow allows faster time to market? (Asking as a systems programmer, v…

I'd imagine for many developers, the probability of something like Google's Hosted Libraries (https://developers.google.com/speed/libraries) going down or being hacked is far, far lower than the probability of their own site hosting having a problem.

Re: Unpkg CDN down causing dependent website outages

#33
post #22
post #6

Earlier quoted context omitted.

I do both. If you are loading a JS lib then check for its existence on the client. If it's not found load the resource from your server. You could also achieve this on the server side.

1. You realise caches, even for third party assets are partitioned by host domain in most modern browsers now? So you're not getting a benefit that users loaded the script from someone else's site. 2. For saving bandwidth on the server are you using proper cache setup with etags and If-Modified-Since support? It shouldn't have to download a first party asset again if it's in the cache. It's worth pointing out that no…

1) Yes, the other benefit at the time was a browser would only do X number of requests per domain, using the CDN allowed more requests. Also it was a bandwidth issue from the server.

2) Yes. I should also mention at the time mobile browser cache was not consistent/reliable.

3) The "loader script" is a basic if(!lib.func) { do the magic }. Its one extra thing I suppose. For the overall page load there are lower hanging fruit.

Re: Unpkg CDN down causing dependent website outages

#34
post #12
post #11

Earlier quoted context omitted.

In this situation server bandwidth was an issue. Using an available CDN with the fall back was what we decided to do. It's not that complicated, from the client check if the object you expect to exist in the library exists, if not load it from your server.

I’m curious, in what scenario was bandwidth for static resources an issue? It’s one of the most trivial things to serve cheaply.

When the server is behind a pipe of limited size. When most of your new visits happen all at once over a short period of time. When you can't rely on a mobile phones cache like a desktop because 90% of your visitors are using one. A CDN is a easy win to off load resources, even if they are small.

Re: Unpkg CDN down causing dependent website outages

#35
post #34
post #12

Earlier quoted context omitted.

I’m curious, in what scenario was bandwidth for static resources an issue? It’s one of the most trivial things to serve cheaply.

When the server is behind a pipe of limited size. When most of your new visits happen all at once over a short period of time. When you can't rely on a mobile phones cache like a desktop because 90% of your visitors are using one. A CDN is a easy win to off load resources, even if they are small.

> A CDN is an easy win to off load resources, even if they are small.

Yes and setting up your own CDN config (Cloudfront, whatever) is minutes of work and brings all of the benefits you’ve outlined. And costs pennies.

Re: Unpkg CDN down causing dependent website outages

#36
post #6

Earlier quoted context omitted.

I invite everyone (even those not affected in this instance) to consider switching away from relying on random third parties for your hosting. Like wtf how is did this ever become the norm even when there was a slight performance advantage from a shared cache, which doesn't even exist anymore these days.

I do both. If you are loading a JS lib then check for its existence on the client. If it's not found load the resource from your server. You could also achieve this on the server side.

What does that actually mean? How do you check if a JS library exists on the client?

Re: Unpkg CDN down causing dependent website outages

#37
post #33
post #22

Earlier quoted context omitted.

1. You realise caches, even for third party assets are partitioned by host domain in most modern browsers now? So you're not getting a benefit that users loaded the script from someone else's site. 2. For saving bandwidth on the server are you using proper cache setup with etags and If-Modified-Since support? It shouldn't have to download a first party asset again if it's in the cache. It's worth pointing out that no…

1) Yes, the other benefit at the time was a browser would only do X number of requests per domain, using the CDN allowed more requests. Also it was a bandwidth issue from the server. 2) Yes. I should also mention at the time mobile browser cache was not consistent/reliable. 3) The "loader script" is a basic if(!lib.func) { do the magic }. Its one extra thing I suppose. For the overall page load there are lower hangin…

> The "loader script" is a basic if(!lib.func) { do the magic }. Its one extra thing I suppose. For the overall page load there are lower hanging fruit.

That's still a 100-200ms if the user is not on the same continent as your server.

Re: Unpkg CDN down causing dependent website outages

#38

This is one thing I never understood about web development. I would have thought the risks from 3rd party production dependencies would make devs do all in their power to minimize them. But IIUC it's a somewhat common practice. Is there something about the market dynamics that make this a reasonable tradeoff? E.g., the problems are rare and this somehow allows faster time to market? (Asking as a systems programmer, v…

Part of it is just because it's easier. There's a bootstrap theme I've used that relies on a Google font. Rather than package the font, which would require extra work on the webdev's part to serve locally, they just stuck a CDN URL in the css.

But the webfont is not crucial to website UX as a blocking 3rd-party without async/defer in is.

Re: Unpkg CDN down causing dependent website outages

#39
post #3

I invite everyone affected to consider switching to a production focused CDN https://www.jsdelivr.com/ There is also a tool to simplify migration https://www.jsdelivr.com/unpkg

I invite everyone (even those not affected in this instance) to consider switching away from relying on random third parties for your hosting. Like wtf how is did this ever become the norm even when there was a slight performance advantage from a shared cache, which doesn't even exist anymore these days.

A very specific problem with third party hosts : if you use noscript and only allow main domain script as a default, you have to either whitelist those CDN or authorize them on every site using it. Not the best experience. Especially with some sites having dozens of third party scripts so instead of trying to find the right one(s) to authorize you just close the tab and forget about it.
Post reply on HN