-
-
Save mikeal/8150724 to your computer and use it in GitHub Desktop.
| https://twitter.com/izs/status/416635696367951873 | |
| let's talk here, we have commments with mor ethan 140 characters! |
The only difference would be that the fallback would not work with an offline copy of R2....
I’m not sure if I am making things more or less complicated now.
Yes, I <3 you, but now you are definitely making things more complicated :)
That fallback is written in VCL, and exists only on the Fastly CDN config. From the outside, if you're not looking at the http headers, you wouldn't know that npm wasn't fetching from Manta, or through a CDN. npm-the-client just fetches $registry/$pkg, and then follows the dist.tarball url in the doc, and expects it to be a tgz file matching the dist.shasum in the doc. It is completely server-architecture agnostic, other than that. (As proof: this is how it already works, and has for days now, and you're totally ok with it :)
The bottom line of this inquiry seems to be that I can do exactly what I want, and it's just going to cost me having a second DB setup so that replication users can keep doing their thing. Also, either the current isaacs.iriscouch.com/registry couch can be the canonical R2, or can replicate from it, and no one will even notice the change.
How about a plain HTTP/FTP folder, with tarballs having redirects and the json of the couchdb dumped into a 'json' folder? Then it's just a plain sync and script to read in the json (or another non-couch server to serve up the info).
That's roughly what's sitting in Manta under /isaacs/public/npm. You can even mount this with NFS, I'm told, though I haven't tried myself, and a folder with >52,000 entries might be rough on some systems :)
The format is:
/isaacs/public/npm
+-- $package_name
| +-- doc.json - The same as the couchdb document
| `-- _attachments
| +-- $package_name-$version.tgz - Tarball attachments
| `-- more tarballs...
`-- more packages...
@isaacs Along with what @konobi said — how feasible are static files which I can use as a local registry? I'd like to mimimize my operational overhead. On my end, something like nginx which serves all the files from a directory. For upstream, ppl can wget on a regular basis which would make running mirrors a lot, lot easier as well
Also, I've never heard of Manta — what exactly is this? Joyent's version of S3? Also, is there anything to see yet and try?
Manta is http://www.joyent.com/products/manta. There's an SDK and docs. Because the files are in my public storage location, you can read them, link them to your space, run jobs over them, etc.
This much is already done. As of this moment, tarballs are being served through Fastly from Manta, not from CouchDB. They still are in CouchDB as attachments, but unless you're hitting the CouchDB endpoint directly (or if Manta doesn't have the file yet), you will be getting them from Manta.
It's probably not trivial to use static files as a local registry, at least, not one that you could write to. I haven't explored that.
How about a plain HTTP/FTP folder, with tarballs having redirects and the json of the couchdb dumped into a 'json' folder? Then it's just a plain sync and script to read in the json (or another non-couch server to serve up the info).