5 ms·

Why is this a problem? If you add fields on a REST endpoint, you're going to have to change the client too to deal with those new fields.

em-bee 2y ago
depends. i'd be writing the client such that it just lists all the fields, and then add special handling for the fields that need it. when the backend adds new fields, they will just show up and i just need to fix the formatting. with graphql i'd have to ask for those new fields, and thus make changes in two places. and in addition the backend team has to tell the frontend team about the new fields (instead of letting the api speak for itself), making it easier to accidentally skip a field.
chasd00 2y ago
If new fields show up in a json response just ignore them. Why would you need to change the client if new fields show up in the response?
- tossandthrow 2y ago
  Indeed, this is what graphQL solves. Are you proposing just to add new field to a JSON response, even though they are not needed?
  - eatsyourtacos 2y ago
    >Are you proposing just to add new field to a JSON response, even though they are not needed? That is exactly what OP is proposing and it makes total sense. More data != bad. Just ignore if you don't need it. For 99.999% of cases the bandwidth of extra data is entirely negligible. For business cases you just want to get things done. If the server has added more data, which is obviously relevant in some regard, you can see it and might want to use it etc. With GraphQL you are completely stuck without SPECIFICALLY requesting it. That means every client needs to know about the new data and specifically request it. In theory that might sound like it makes sense, but in practice this is virtually never the case. Give me all the data and I'll use what makes sense.
    - tossandthrow 2y ago
      What decides what data to include? Or are you just sending all data the client cloud possibly see over?
      - scubbo 2y ago
        The data related to the object being returned. This sounds like a facetiously-simple answer, but it's entirely earnest. If the data properly belongs as a property of the object, return it in the object's representation. If the "data" is actually an ID of a related object, return that id (or, better yet, the URL at which to find information about that object) as a link. Domain-Driven Design is much over-hyped, but on this they were right on the money. ("But then you have to make multiple requests to gather information which crosses the boundaries of many objects". Yes. And? Beyond a reasonable point, latency is nowhere near as important as many developers like to think it is, especially when compared with a simple and straightforward API - and if this is one of those rare cases that is on the critical path, you _can_ add a dedicated getFooWithAdditionalBars endpoint to your REST API)
  - scubbo 2y ago
    GraphQL "solves" the ability to ignore an unneeded field in a response? Revolutionary.
    - dclowd9901 2y ago
      Even in REST, I’m sure you don’t use every field from every request? In fact, such tight coupling between FE and BE in REST is strongly advised against. And “wasted fields” was never a problem graphql was trying to solve.
      - scubbo 2y ago
        We are in complete agreement - I was criticizing the implication that it was impossible to ignore fields in a REST response.
- wruza 2y ago
  Because receiving unexpected data is a signal you rarely want to ignore in programming. Doesn’t matter whether you’re gonna use it or not.
  - finack 2y ago
    No, that's an important facet of compatibility. If a change is purely additive, existing clients will keep working, something the industry has basically forgotten all about, it seems.
    - wruza 2y ago
      I think I have to agree with this correction in general, but don’t take one commenter for a whole industry please. I’m not even remotely representative of it.
      - finack 2y ago
        I'm not, I'm using my decade of experience and nascent alcoholism.
  - int_19h 2y ago
    In OOP, the equivalent - getting an object of some more specific type than the one you asked for at API level - happens all the time.
nevir 2y ago
One problem is performance. (Most) GraphQL clients are optimized for relatively small/simple objects being returned, and you typically pay a cost for every single edge (not node) returned in a response / cached in memory. It can quickly get to the point where your project is spending more time per frame processing GraphQL responses & looking data up from the cache than you spend rendering your UI
culi 2y ago
it sounds like they are just dumping every field to somehow show the user without any validation/specific rendering logic for each field

em-bee 2y ago

depends. i'd be writing the client such that it just lists all the fields, and then add special handling for the fields that need it. when the backend adds new fields, they will just show up and i just need to fix the formatting. with graphql i'd have to ask for those new fields, and thus make changes in two places. and in addition the backend team has to tell the frontend team about the new fields (instead of letting the api speak for itself), making it easier to accidentally skip a field.

chasd00 2y ago

If new fields show up in a json response just ignore them. Why would you need to change the client if new fields show up in the response?

tossandthrow 2y ago
Indeed, this is what graphQL solves. Are you proposing just to add new field to a JSON response, even though they are not needed?
- eatsyourtacos 2y ago
  >Are you proposing just to add new field to a JSON response, even though they are not needed? That is exactly what OP is proposing and it makes total sense. More data != bad. Just ignore if you don't need it. For 99.999% of cases the bandwidth of extra data is entirely negligible. For business cases you just want to get things done. If the server has added more data, which is obviously relevant in some regard, you can see it and might want to use it etc. With GraphQL you are completely stuck without SPECIFICALLY requesting it. That means every client needs to know about the new data and specifically request it. In theory that might sound like it makes sense, but in practice this is virtually never the case. Give me all the data and I'll use what makes sense.
  - tossandthrow 2y ago
    What decides what data to include? Or are you just sending all data the client cloud possibly see over?
    - scubbo 2y ago
      The data related to the object being returned. This sounds like a facetiously-simple answer, but it's entirely earnest. If the data properly belongs as a property of the object, return it in the object's representation. If the "data" is actually an ID of a related object, return that id (or, better yet, the URL at which to find information about that object) as a link. Domain-Driven Design is much over-hyped, but on this they were right on the money. ("But then you have to make multiple requests to gather information which crosses the boundaries of many objects". Yes. And? Beyond a reasonable point, latency is nowhere near as important as many developers like to think it is, especially when compared with a simple and straightforward API - and if this is one of those rare cases that is on the critical path, you _can_ add a dedicated getFooWithAdditionalBars endpoint to your REST API)
- scubbo 2y ago
  GraphQL "solves" the ability to ignore an unneeded field in a response? Revolutionary.
  - dclowd9901 2y ago
    Even in REST, I’m sure you don’t use every field from every request? In fact, such tight coupling between FE and BE in REST is strongly advised against. And “wasted fields” was never a problem graphql was trying to solve.
    - scubbo 2y ago
      We are in complete agreement - I was criticizing the implication that it was impossible to ignore fields in a REST response.
wruza 2y ago
Because receiving unexpected data is a signal you rarely want to ignore in programming. Doesn’t matter whether you’re gonna use it or not.
- finack 2y ago
  No, that's an important facet of compatibility. If a change is purely additive, existing clients will keep working, something the industry has basically forgotten all about, it seems.
  - wruza 2y ago
    I think I have to agree with this correction in general, but don’t take one commenter for a whole industry please. I’m not even remotely representative of it.
    - finack 2y ago
      I'm not, I'm using my decade of experience and nascent alcoholism.
- int_19h 2y ago
  In OOP, the equivalent - getting an object of some more specific type than the one you asked for at API level - happens all the time.

nevir 2y ago

One problem is performance. (Most) GraphQL clients are optimized for relatively small/simple objects being returned, and you typically pay a cost for every single edge (not node) returned in a response / cached in memory. It can quickly get to the point where your project is spending more time per frame processing GraphQL responses & looking data up from the cache than you spend rendering your UI

culi 2y ago

it sounds like they are just dumping every field to somehow show the user without any validation/specific rendering logic for each field