4 ms·

> a REST endpoint can return whatever you want. If you only want a subset of that graph, make an endpoint around that subset. So we have to make endpoints arou

> a REST endpoint can return whatever you want. If you only want a subset of that graph, make an endpoint around that subset. So we have to make endpoints around every possible subset? > You want to avoid large object graphs anyway, for two reasons. Returning coarse-gained chunks of data tends to work against effective caching strategies, whether you're using REST, Relay, or anything else. You have to cache the whole chunk or nothing. I thought the whole point of Relay et al. was that it would cache the union of the chunks, such that when I request more data, it can download only the exact pieces I need?

jerf 11y ago
"So we have to make endpoints around every possible subset?" No, you use the query in querystring. One way or another you're offering a query interface. A lot of REST is just about how you offer the same interfaces you were planning on offering anyhow. Which is probably a source of a lot of the frustration REST advocates experience. If you're genuinely doing something that REST can't do very well, OK then, but if you're doing something that HTTP can already do, why layer something else on top of HTTP that HTTP is already doing? (Sometimes there are good answers to that question, though.)
- thomasahle 11y ago
  > No, you use the query in querystring. Ok, but doing that straight on top of HTTP, will only cache queries that are exactly equal to previous ones. Not queries that are a subset of previous queries.
  - pbhjpbhj 11y ago
    If the [data returned following a] query is a subset [of data points already returned] why do you need to get it again; if you actually need to re-retrieve it then it being cached is no use unless you dumped it from local cache mistakenly - that shouldn't be an often enough occurrence to need to cache the data. Or did I miss something?
    - thomasahle 11y ago
      I'm thinking about the case where you have a cache between you and the server, shared by multiple users. I imagine this is useful at facebook, for example for loading parts of public peoples pages, etc. You are right, that if the data is only used by you, you can just have an advanced cache in the client, sorting it out for you.
  - jerf 11y ago
    I think you have to be careful not to be too cavalier with the word "cache" there. While REST is sort of vaguely concerned with the ability to cache in the general sense, in real life we have to be specific about what is doing the caching. This is the sort of dynamic query you'd normally tell intervening proxies not to cache anyhow, so now we can reduce our concerns to the client and the server specifically. On the client, if it asked for a big chunk of the graph and now need to operate on a smaller on, I'd suggest that if the client does not want to incur another round trip, it would be incumbent on the client not to ask another question. (This is further backed up by a consistency concern; if I ask again, I may get a different answer because it has actually changed in the meantime. You may be better off with your code not even looking at the changes.) On the server, caching technologies can easily be arranged (if the server cares) to cache more granularly than is necessarily reflected in the answers. (In fact most of my "cloud" caches I'm currently responsible for do that all the time.) I actually don't deny there's a use case here necessarily, but it may not be all that large, even to Facebook.
    - thomasahle 11y ago
      I was thinking of a large graph, where everybody wanted different parts. Then a cache somewhere in the middle could work, even if nobody wanted exactly the same parts. However I guess you could achieve the same by sending many parallel requests.
michaelmior 11y ago
s/catch/cache/ ?
- thomasahle 11y ago
  Thank you.
Cakez0r 11y ago
> So we have to make endpoints around every possible subset? Pretty much. GraphQL is conceptually the same as just letting your clients send an SQL query to your API. Relay seems a short step away from having a graph database engine running client side, a storage engine on the server and a remoting layer to glue them together.
SideburnsOfDoom 11y ago
> So we have to make endpoints around every possible subset? No, you make endpoints for what clients actually need and use. qyv has it right https://news.ycombinator.com/item?id=10413950 https://news.ycombinator.com/item?id=10413950 - responses are UI models and when you "model the problem domain of the UI layer" you're asking "which chunks of data do clients really need?" If you really have clients that ask for "every possible subset" then this is a requirement that is completely unrelated to REST. i.e. you can try at solving it with REST, or without REST. The article actually says that: "If you're requesting some subset of a complicated object graph, and constantly re-negotiating which particular subset, then you have a problem which has nothing to do with REST."
mistermann 11y ago
> So we have to make endpoints around every possible subset? As I was reading this I was trying to figure out how he missed the point so badly, I think your point does a good job of that. The OP might benefit from adopting the strategy of when you see someone saying something crazy/stupid, stop and think before writing an inflammatory blogpost.

jerf 11y ago

"So we have to make endpoints around every possible subset?" No, you use the query in querystring. One way or another you're offering a query interface. A lot of REST is just about how you offer the same interfaces you were planning on offering anyhow. Which is probably a source of a lot of the frustration REST advocates experience. If you're genuinely doing something that REST can't do very well, OK then, but if you're doing something that HTTP can already do, why layer something else on top of HTTP that HTTP is already doing? (Sometimes there are good answers to that question, though.)

thomasahle 11y ago
> No, you use the query in querystring. Ok, but doing that straight on top of HTTP, will only cache queries that are exactly equal to previous ones. Not queries that are a subset of previous queries.
- pbhjpbhj 11y ago
  If the [data returned following a] query is a subset [of data points already returned] why do you need to get it again; if you actually need to re-retrieve it then it being cached is no use unless you dumped it from local cache mistakenly - that shouldn't be an often enough occurrence to need to cache the data. Or did I miss something?
  - thomasahle 11y ago
    I'm thinking about the case where you have a cache between you and the server, shared by multiple users. I imagine this is useful at facebook, for example for loading parts of public peoples pages, etc. You are right, that if the data is only used by you, you can just have an advanced cache in the client, sorting it out for you.
- jerf 11y ago
  I think you have to be careful not to be too cavalier with the word "cache" there. While REST is sort of vaguely concerned with the ability to cache in the general sense, in real life we have to be specific about what is doing the caching. This is the sort of dynamic query you'd normally tell intervening proxies not to cache anyhow, so now we can reduce our concerns to the client and the server specifically. On the client, if it asked for a big chunk of the graph and now need to operate on a smaller on, I'd suggest that if the client does not want to incur another round trip, it would be incumbent on the client not to ask another question. (This is further backed up by a consistency concern; if I ask again, I may get a different answer because it has actually changed in the meantime. You may be better off with your code not even looking at the changes.) On the server, caching technologies can easily be arranged (if the server cares) to cache more granularly than is necessarily reflected in the answers. (In fact most of my "cloud" caches I'm currently responsible for do that all the time.) I actually don't deny there's a use case here necessarily, but it may not be all that large, even to Facebook.
  - thomasahle 11y ago
    I was thinking of a large graph, where everybody wanted different parts. Then a cache somewhere in the middle could work, even if nobody wanted exactly the same parts. However I guess you could achieve the same by sending many parallel requests.

michaelmior 11y ago

s/catch/cache/ ?

thomasahle 11y ago
Thank you.

Cakez0r 11y ago

> So we have to make endpoints around every possible subset? Pretty much. GraphQL is conceptually the same as just letting your clients send an SQL query to your API. Relay seems a short step away from having a graph database engine running client side, a storage engine on the server and a remoting layer to glue them together.

SideburnsOfDoom 11y ago

> So we have to make endpoints around every possible subset? No, you make endpoints for what clients actually need and use. qyv has it right https://news.ycombinator.com/item?id=10413950 https://news.ycombinator.com/item?id=10413950 - responses are UI models and when you "model the problem domain of the UI layer" you're asking "which chunks of data do clients really need?" If you really have clients that ask for "every possible subset" then this is a requirement that is completely unrelated to REST. i.e. you can try at solving it with REST, or without REST. The article actually says that: "If you're requesting some subset of a complicated object graph, and constantly re-negotiating which particular subset, then you have a problem which has nothing to do with REST."

mistermann 11y ago

> So we have to make endpoints around every possible subset? As I was reading this I was trying to figure out how he missed the point so badly, I think your point does a good job of that. The OP might benefit from adopting the strategy of when you see someone saying something crazy/stupid, stop and think before writing an inflammatory blogpost.