search

jspm / jspm-cli

ES Module Package Manager
https://jspm.org
Apache License 2.0
3.77k stars 274 forks source link

CDN support? #32

Closed bebraw closed 10 years ago

bebraw commented 10 years ago

Hi,

Just thought to point out there's a little API available for some of the most popular JavaScript CDNs at https://github.com/jsdelivr/api . Maybe you can use that somehow (ie. load assets from CDN or something).

guybedford commented 10 years ago

Thank you for posting - this looks very useful for constructing an endpoint on top of a CDN.

I previously did some work on constructing a jspm endpoint on top of cdnJS.

My conclusion though was that we really want everything (github:, npm:, etc) all over a single CDN system / connection, so there is only a single point of failure. Additionally without SPDY push support, the major benefit of using these endpoints in production is lost.

Unfortunately at that moment that leaves jspm.io to become its own CDN, until Nginx can support SPDY push.

Happy to discuss further, but this is the best analysis that I can come up with.

jimaek commented 10 years ago

jsDelivr can do proxy caching if needed. For example: cdn.jsdelivr.net/jspm/ -> jspm.com/files/

Would that solve the first problem?

guybedford commented 10 years ago

Potentially... does this handle cache expiry and ETags? We also have some custom headers as well. Apart from gathering statistics, the server is mostly stateless.

My current plan is simply to start scaling out the server on a GeoDNS with redundancy. Would be a fun ops project :)

jimaek commented 10 years ago

I can configure the proxy to pass all headers. This way you will control cache-expiry and anything else. Its up to you :)

guybedford commented 10 years ago

The only issue with this is that the cache headers need to be handled intelligently by the CDN to ensure adequate revalidation. So if an ETag matches, sending 304 etc. And also then having some control over the CDN cache expiry itself.

In jspm this is all finely tuned to ensure that npm repos are fresh where expected, and cached with far future expires when stable versions are provided.

The argument is that for a system like this, the CDN needs to have a certain level of smarts. And unfortunately, until CDNs provide enough simple hooks into that functionality, it means rewriting this low-level handling is still the best approach.

I think this stuff will converge in time, but right now that puts us in different positions unfortunately.

jimaek commented 10 years ago

Well, as you see fit. Just so you know I would be happy to help. So feel free to ping me if you need anything.

guybedford commented 10 years ago

Sure, and thanks for reaching out. To summarise the features that would need to be supported for this approach to work:

  1. SPDY push support in Nginx, supported through X-Associated-Content header.
  2. Respecting ETags and Cache-Control max age headers for browsers (responding with 304s appropriately)
  3. Respecting s-maxage or Surrogate-Control headers to ensure cache server-level expiry control depending on the resource type.

Perhaps (2) and (3) are already supported today in some form? If the status on the above changes definitely let me know.

guybedford commented 10 years ago

Also if you're interested in getting involved in jspm in other ways definitely let me know - always happy to chat.