Apollo-client: Remove fetch dependency

[helfer]

This would make things like whatwg-fetch (#267) unnecessary. It's only a minor change in the network interface, so it should be easy to do.

Anyone want to take this?

[stubailo]

Yeah this is compounded by the fact that we only use like 1% of the features of fetch.

[jbaxleyiii]

@stubailo @helfer any direction on doing this isomorphically? I'd be happy to rework it but not sure of a solid universal way?

[stubailo]

I know of one that's pretty solid and relatively minimalist... https://github.com/meteor/meteor/tree/devel/packages/http

It's about 400 lines total, so maybe we can polish it up and publish on NPM? Perhaps people are looking for a simple universal HTTP client that doesn't have ten million bells and whistles. It's also ridiculously well tested.

[batjko]

some elaborate fetch issue, which is now resolved
nvm, I just had to add the fetch object to the global namespace, can't be local (i.e. no const), when using in node.

I'd love to get rid of this requirement for people to get their own fetch working.

[helfer]

@batjko Would you be interested in rewriting the meteor package that sashko linked to into a npm package? I think that would do the trick, and we could provide assistance where needed.

[batjko]

@helfer It looks like the HTTP package is just wrapping the npm "request" package under the hood, which, although it's not pretty, could be used instead?.

I wonder if axios or the like wouldn't be better recommendations though? Supporting promises instead of callbacks, even for multiple concurrent requests.

[stubailo]

@batjko we can't use request in the browser though. I was specifically suggesting http as a nice code base that works exactly the same way on client and server, and is super well tested.

[stubailo]

Axiom looks pretty cool - how big is it? Ideally we don't want to increase the size of this library too much.

[batjko]

The downloaded npm package racks up about 270kb. Written in typescript though, if that helps? ;)

[hwillson]

@batjko The minified axios dist is much less, coming in at around 10k.

[batjko]

True. Depends on how you guys import the thing.

[stubailo]

10k still seems overwhelmingly large just to make an http request with a promise. All of Apollo client is like 25k or something.

[batjko]

Ah, makes sense then.
I don't think I can do the conversion of that HTTP package though, I don't know the first thing about how npm or meteor packages are built.
I should really read into that sometime.

[kamilkisiela]

What do you guys think?

https://github.com/kamilkisiela/httpcall

Basically it the same implementation as in https://github.com/meteor/meteor/tree/devel/packages/http

Should I add tests and keep working on it?

[batjko]

@kamilkisiela Yea tests are missing. If a big project like Apollo were to depend on this, it better be plastered with code coverage.

Edit: Looks nice and clean btw :+1:

[stubailo]

Wow awesome @kamilkisiela! I was going to put it together but you beat me to it :)

[kamilkisiela]

@stubailo I have one question.

While I was creating this I saw that there is a escape variable inside of it.

From where it come from?

[hwillson]

@kamilkisiela It's actually the JS standard library escape function (now deprecated). String.replace can accept a function as its second parameter, that can be called to create the new substring.

[kamilkisiela]

@hwillson Didn't know, thanks!

I added few tests and created a build process with continuous integration. If someone wants to help with moving tests from meteor package it would be amazing! :)

@stubailo Do you guys want to have it under apollostack or meteor organisation or something?

[helfer]

@kamilkisiela Under apollostack would be good.

[kamilkisiela]

@helfer You can create the repository for it and I will do transfer.

[helfer]

@kamilkisiela I've created a repo called http, you have write access (as soon as you accept the team invitation), so you can push your initial commits to it without making a PR.

[kamilkisiela]

@helfer Done :+1:

[abhiaiyer91]

Alright so is this still an issue?

[stubailo]

Yeah, definitely!

[helfer]

I don't think it's necessary to track this here, as it's on our medium-term roadmap now.

[pleunv]

Perhaps relevant? https://github.com/developit/unfetch

[calebmer]

@pleunv we thought about it, but it is still too early: https://github.com/apollographql/apollo-client/pull/1320. Mainly unfetch doesn’t have CORS or cookie support which are two very important HTTP network features for Apollo Client.

In the future we are interested in moving towards a world where the user defines their own GraphQL execution function. It’s only a few lines in the user’s code for a lot of benefits. We currently have abstractions around middleware that we just wouldn’t need if the user was in control of query execution. At that point you can decide whether or not you want to use unfetch 😊