3 ms·

Often what gets lost in these kinds of discussions is the difference between what is theoretical and what is practical. Yes, you can have a perfectly designed R

Often what gets lost in these kinds of discussions is the difference between what is theoretical and what is practical. Yes, you can have a perfectly designed REST API which has all of these features. What happens, though, when you want a new piece of data? Do you redesign the API to fit this new piece of information into it or do you make a new endpoint? What if the new piece of data doesnt actually belong with `friends` but if you do the fetch for friends and this new piece of data at the same time you can get a performance boost? Do you make a new endpoint `friendsandfamily`? Now, what if you want to migrate all calls over to that endpoint, you now need to figure out if any of your frontend code or legacy systems are still using that old endpoint before you remove it. The maintenance of that system is much higher because you've conflated what data you want with how you want to get it.

riffraff 10y ago
how is this solved by GraphQL though? You still need to add a new edge `friendsandfamily` (same as adding to a new endpoint) or add a new a field to the existing object (same as adding a new field to the existing endpoint). What am I missing?
- paulddraper 10y ago
  (1) GraphQL returns only what the client asks for. No need to worry that adding to an existing resource will increase response times or bloat the response for existing queries. (2) If you decide to go the friendsandfamily route, you'll just be adding `family`. You won't have `friends` endpoint and `family` endpoint and `friendsandfamily` endpoint. A GraphQL schema doesn't increase combinatorially in size; rather the possible compositions increase combinatorially.
  - riffraff 10y ago
    for 2) isn't this the same as adding an optional "include=family" to the existing friends endpoint? This is what the JSONAPI spec suggest too.
    - paulddraper 10y ago
      Yep. You can use query parameters to fix 1) and 2). Go down the rabbit hole a little bit further, and you have GraphQL (if you're lucky....if not, you'll just have a mess).

riffraff 10y ago

how is this solved by GraphQL though? You still need to add a new edge `friendsandfamily` (same as adding to a new endpoint) or add a new a field to the existing object (same as adding a new field to the existing endpoint). What am I missing?

paulddraper 10y ago
(1) GraphQL returns only what the client asks for. No need to worry that adding to an existing resource will increase response times or bloat the response for existing queries. (2) If you decide to go the friendsandfamily route, you'll just be adding `family`. You won't have `friends` endpoint and `family` endpoint and `friendsandfamily` endpoint. A GraphQL schema doesn't increase combinatorially in size; rather the possible compositions increase combinatorially.
- riffraff 10y ago
  for 2) isn't this the same as adding an optional "include=family" to the existing friends endpoint? This is what the JSONAPI spec suggest too.
  - paulddraper 10y ago
    Yep. You can use query parameters to fix 1) and 2). Go down the rabbit hole a little bit further, and you have GraphQL (if you're lucky....if not, you'll just have a mess).