Provide isomorphic implementation of WHATWG fetch() API.

[benjamn]

As described in my talk about Meteor 1.7's modern/legacy bundling system (relevant slides), the WHATWG fetch() API is a great example of a feature that requires a totally different implementation in modern browsers, legacy browsers, and Node.

The fetch() API is already widely used in the JavaScript community, and I suspect it will eventually replace the core Meteor http package for most HTTP request needs, especially since it is essentially free in modern browsers.

[benjamn]

Need more tests, obviously!

[hwillson]

No way - I like how manageable these tests are ... 🙂.

[benjamn]

If anyone else wants to help replace HTTP with fetch in Meteor core packages, just comment here first, and then open a PR targeting the isomorphic-fetch branch.

[hwillson]

Woohoo! This is great @benjamn - so far so great!

[hwillson]

No way - I like how manageable these tests are ... 🙂.

[sebakerckhof]

@benjamn what would the strategy be for replacing server-side calls that are now synchronous because of fibers. Just Promise.await the fetch?

And what about error handling? HTTP package will throw if the status code is >= 400 (see https://github.com/meteor/meteor/blob/devel/packages/http/httpcall_server.js#L119 and https://github.com/meteor/meteor/blob/devel/packages/http/httpcall_client.js#L180), fetch will not do this.
So I don't think the places where you already replaced it have the same behavior as before.

[benjamn]

what would the strategy be for replacing server-side calls that are now synchronous because of fibers. Just Promise.await the fetch?

This PR is part of a longer-term plan to encourage developers to move away from fibers and towards existing web standards. So I would honestly recommend actually awaiting the fetch in an async function, or working with the Promise API explicitly, though fibers will of course still work.

So I don't think the places where you already replaced it have the same behavior as before.

Thanks for pointing that out! I don't consider fetch() a drop-in replacement for HTTP by any means, though perhaps we should be clearer about the differences.

[sebakerckhof]

My questions were a reply to #10029 (comment). So in the context of replacing HTTP in the current core packages, are those also the recommendations? Because awaiting in an async instead of relying on fibers would be a backwards incompatible change for end-users, which Meteor usually tries to prevent.

Same thing for the errors. I agree that fetch shouldn't be a drop-in replacement for HTTP. Rather the opposite and it should just follow the fetch-spec. But handling errors differently might brake existing core packages. E.g. when they rely on a 404 throwing an error or something.

[jamesmillerburgess]

I will replace HTTP in bundle-visualizer since I'm already touching it in another PR.

[benjamn]

In light of @sebakerckhof's astute feedback, and in order to make this package available for use with the bundle-visualizer (and other packages where it makes sense), I think we should try to publish the initial version of fetch soon (maybe after adding more tests), without fully migrating away from (or deprecating) http just yet.

Let's make fetch() happen!

[abernix]

LGTM. Additional fetch tests seem like a good idea, and I agree with getting this out sooner rather than later, but I think we can also probably relish in certain (test) benefits we're gaining thanks to the existing tests that whatwg-fetch and node-fetch have to offer!