Relay Modern: Simpler, faster, more extensible

Re:Relay Modern: Simpler, faster, more extensible by marcosscriven on Wednesday April 19, 2017 @04:27PM (#14151441)

But I thought the headline feature of GraphQL was that the client could choose the shape of the response, hence all those properties. Even then, ten thousand properties seems a huge amount, even for a rich single page app.

If you end up putting that on the server anyway, you're back to fixed responses, no better than a REST API.

[ Parent | on HN ]

Re:Relay Modern: Simpler, faster, more extensible by acjohnson55 on Wednesday April 19, 2017 @05:51PM (#14152131)

I guess you mean like a RESTish "super-endpoint", that aggregates a whole bunch of data? Because operationally, it would be really different than making a thousand idiomatically REST queries over a hypermedia API.

If so, there's still a huge difference. In the REST super-endpoint world, you have to modify your API service to suit the desires of individual clients. In GraphQL, the client controls the shape of the query. The detail that the client is sending that query at deploy-time, instead of request-time, doesn't change that.

This also recognizes that queries tend to be parametric, but not fully dynamic. That's kind of built-in to Relay, since the fragments are statically attached to React components.

It's more akin to HTTP caching, to me.

[ Parent | on HN ]