Initial run of network layer

[jbaxleyiii]

Initial run of the network layer to allow for remote requests. This interface will be used by the end client API to get the benefits of the caching system and slimmer requests.

[stubailo]

@jbaxleyiii should we be worried about the patent clause in Relay? Might it be worth avoiding taking parts from it? Maybe I'm overthinking it.

@zol looks like the CLA bot is broken, it's reporting not signed even though it is according to the website.

[stubailo]

endpoint

[jbaxleyiii]

@stubailo I'll take a look at the patent. I can make it more generic as well to avoid any complications

[stubailo]

@jbaxleyiii I dunno if the patent thing is a big deal. Maybe I should consult with someone who knows about this stuff to see how much we should care. At the end of the day everyone uses React and it has a similar patent grant.

[jbaxleyiii]

@stubailo that sounds good. Keeping it compatible as a relay network layer would be cool, but I don't know how much value it would add since it this layer will probably stay bare bones. If we don't worry about it, we can change the request object to better suit apollo's needs and add in additional upgrades as needed without concern of breaking relay compatibility.

Along that note, I'd like to keep this PR open until the first run of the actual client API is started. I think the request object will cause some changes to this method. Particularly in how it gets variables / queries /mutations

[stubailo]

Yeah makes sense to me. Ensuring compatibility with the Relay client doesn't sound like a high priority right now because I haven't seen that many libraries written for it yet.

[stubailo]

@jbaxleyiii I think the caching wouldn't be integrated into the request/network layer right?

I'm thinking:

client
- cache
- network layer

Where the cache and network layer are swappable, and the client uses both and mediates the communication. The network layer just does queries when the client wrapper deems it necessary?

[jbaxleyiii]

@stubailo yep! That was what I was going to work on next. That also potentially allows us a few other options:

client
- cache
- network layer 1 (third party GQL endpoint)
- network layer 2 (first party GQL endpoint)
- application state endpoint // this one is probably off spec, but for uniformity I would love to setup my application state to be query-able / modified via query and mutations

My thought was to do a quick first run of the client so the request portion of this can be set, then merge it and start really working on the client in separate PRs

[stubailo]

Yep, sounds good to me. One thing I'm looking into now is the ability to, given a cache and a query, figure out the set of queries needed to fetch the data that isn't in the cache yet. Sounds like that will be useful to avoid fetching data we already have.

application state endpoint

Definitely interested in what this looks like!

[jbaxleyiii]

@stubailo I think the client api is a larger build out than just the network layer. I'm going to refactor this slightly tonight to make it a little cleaner / remove some the relay code. Then we should be good to merge it through and start proper on the client api

[stubailo]

Yep, I completely agree. I don't think this PR should include anything but a network layer implementation. Also we should agree on a design for the client before we start implementing one, since it's kind of what brings it all together.

[jbaxleyiii]

@stubailo this should be good to go code wise. At some point we should run a local server for testing instead of using the swapi graphql.