-
Notifications
You must be signed in to change notification settings - Fork 33
Fallback for CDN libs #11
Comments
Lots of people have been complaining about random 404 and 503 unpkg responses recently. You can always use jsDelivr instead, which works in a similar way but is more reliable: https://cdn.jsdelivr.net/npm/react@15.4.2/dist/react.min.js |
Solution from ☝️ works on heroku as well: app.css.config.serve_locally = True
app.scripts.config.serve_locally = True |
Yeah, a fallback seems like a good idea. |
Some users reporting another issue with
However, the issues have not lasted for a long time, so perhaps just a simple fallback to local would suffice for now. |
@chriddyp switching to jsDelivr is definitely a good idea, we built it specifically for production usage with multiple failover levels (unpkg wasn't built to be used in production although some people started using it as such). I'd also advise against rolling your own solution with S3 - it most likely wouldn't be more reliable than unpkg. |
We experienced the issue for more than 12 hours before rolling out a fix as mentioned in the forum: If unpkg was never meant to be used in production, I would also go for a different default CDN like cdnjs or cdn.jsdelivr. |
Closing as we merge this repo with the main dash repo. Anyway in dash 1.0 the default will change to I have no strong feelings about any of the CDNs mentioned here vs unpkg, but if anyone would like to make a clear case for a different one - and accompany it with a PR to the main repo after the dash+renderer merge - we'd be be more than happy to switch! |
The versions hosted on CDNJS seem fine:
Maybe it's a good idea to do a HEAD request on the CDN libs at app initialization & fall back to an alternate CDN or local versions of the files if they're not found?
The text was updated successfully, but these errors were encountered: