"You should not use this as a substitute for an actual GraphQL server for accessing a remote backend."

[zuhair-naqvi]

This this because the client would be making N requests rather than the server?

[taion]

Right, you lose all the benefits of request aggregation you'd get with a GraphQL server.

[zuhair-naqvi]

That's true. However in case of React Native, if you use the schema with the app and back it by https://github.com/facebook/dataloader (persist cache to disk) you could potentially deliver an offline first experience.. And the aggregation trade off might be acceptable given most of the queries would be resolved locally by the dataloader (depending on the use case) and only the ones not cached will actually go over the network. I'd be keen to hear your thoughts on this

[taion]

It's not the same because you're still resolving waterfalled loads locally rather than remotely, and end up with multiple WAN round-trips rather than data-center-internal round-trips.

[josephsavona]

This seems like a reasonable warning to have to encourage most people to use a GraphQL server, but @zuhair-naqvi's approach is interesting and totally worth exploring. You're both right! ;-)

[taion]

It still seems less than ideal to use data loader from the client-side, though - you still end up with waterfalled requests, no?

[josephsavona]

@taion context is facebook/relay#676 (comment)