Teammates: Frontend libraries: reduce dependency on CDN

Created on 20 Apr 2017  路  10Comments  路  Source: TEAMMATES/teammates

One of the frontend libraries, https://unpkg.com/[email protected]/js/jquery.guillotine.min.js, can't be accessed from the build environment, causing our recent streak of AppVeyor build failures. It looks like a bug in unpkg: https://github.com/unpkg/express-unpkg/issues/70

This bug has the potential to affect all our users based in the same geographical location as the AppVeyor servers (seems to be U.S. based on their build environment IP). The effect for now is small (unable to edit profile pictures using the web UI), but it does raise the question of whether we've become over-reliant on CDNs (or rather, a single CDN) since #6346 (#6373).

Possible fix: failover to local copy?

a-FaultTolerance c.DevOps p.Medium

Most helpful comment

@amarlearning I would highly recommend against using npm-cdn, the reason being:

  • It it not a well-known package (only 18 stars on GitHub)
  • It is maintained by a single person, instead of a company, which is very likely to go abandoned in the future and on one is going be held responsible (I am already seeing this issue with datamaps that we are using, which is not good)
  • It was explicitly mentioned in the README.md that:

This is a proof of concept app. It works, but it's experimental. It's running on a single Heroku dyno so it won't scale. To become a real thing it will need to sit behind a CDN.

Edit: Didn't see the comment by wilson above, he already covered some of the reasons.

All 10 comments

Good work in following up with unpkg guys @whipermr5 馃憤

Now that we have Webpack, we can consider using it to bundle all the necessary dependencies. That way, we get the best of both worlds:

  • [x] Not reliant on any CDN; can develop/test offline
  • [x] Performance boost: bundled libraries can (1) lead to less HTTP requests, and (2) be cached, much like bundled JS
  • [x] Can automate the dependency resolution
  • [x] No need to "host" the library files locally (they will be in node_modules, so does not count as hosting locally)

Although with a minor upset: adding a new library (if necessary) will not be as simple as before. Need to make sure that the new library works well with Webpack.

Happened again on the qunit library on Travis, but it's enough to fail builds now (check all the builds from 9080 until the time of writing, they all fail on AllJsTests. I can submit a quick fix for the current setback, but perhaps we really need to consider Webpacking everything in order to prevent this problem for good.

It has struck again, this time for bootstrap, making it a major issue: https://github.com/unpkg/unpkg-website/issues/41#issuecomment-322737546

Instead of unpkg.com we can use this:

https://npm-cdn.herokuapp.com/{packageName}@{packageVersion}/{filePath}

I know this is not one of the best ways to resolve this error, but until the time we are looking for a better solution, we can use this. Everything looks good to me :+1:

And this won't require much change, just the base URL needs to be changed.
https://unpkg.com TO https://npm-cdn.herokuapp.com

Reference Link

@amarlearning thanks for your input; we are already switching to jsDelivr in live site and master branch should follow soon. Besides, "the entire package tarball has to be fetched" and "It's running on a single Heroku dyno so it won't scale. To become a real thing it will need to sit behind a CDN." look like good reasons not to use npm-cdn.

On that topic, @whipermr5 if jsDelivr is as reliable as they claim to be, it looks like I can just discontinue my PR?

@wkurniawan07 The datamaps aren't available in jsDelivr though. I still like the idea of webpacking everything.

https://teammatesv4.appspot.com/usermap.jsp is giving errors due to the issue that @whipermr5, maybe open a separate issue to fix that?

@amarlearning I would highly recommend against using npm-cdn, the reason being:

  • It it not a well-known package (only 18 stars on GitHub)
  • It is maintained by a single person, instead of a company, which is very likely to go abandoned in the future and on one is going be held responsible (I am already seeing this issue with datamaps that we are using, which is not good)
  • It was explicitly mentioned in the README.md that:

This is a proof of concept app. It works, but it's experimental. It's running on a single Heroku dyno so it won't scale. To become a real thing it will need to sit behind a CDN.

Edit: Didn't see the comment by wilson above, he already covered some of the reasons.

Resolved in V7.

Was this page helpful?
0 / 5 - 0 ratings