6 ms·

As something of a war-weary veteran - I disagree. It's a good instinct to be suspicious of new technology. But I have personally seen, many times, what REST AP

by sho 6y ago

As something of a war-weary veteran - I disagree. It's a good instinct to be suspicious of new technology. But I have personally seen, many times, what REST APIs can grow into - unless you are very, very careful, "get user/1" can turn into god objects with every field under the sun, non-optional. I've seen `users/l` be over a megabyte with (eg) comments, friends, comments of friends, likes, likes of friends, and every other thing the front end team ever asked for. GraphQL solves that. Yes, it can be avoided with strict, diligent design. But it often isn't. GraphQL solves the whole class of problem. And that's why I like it, despite my mistrust of "new hotness" technology.

HeyHoJoe 6y ago
I think that’s just pretty basic bad design, to be honest.
- diveanon 6y ago
  Thats the whole point, REST facilitates and often encourages bad design.
  - berkes 6y ago
    How does it encourage this, and how does graphQL discourage this? I've always held a strict rule where The R in REST stands for Resource (which isn't true). There's a user, an Invitation (and not an invite action on user, nor a state:invited or invited_at on user). there's a Session. There's links that clients follow, and everything is as small as possible. I really don't see how REST encourages God objects.
    - diveanon 6y ago
      I have seen many people try to solve the "too many requests" problem by slowing expanding rest responses into "god" objects. GQL solves this problem elegantly by allowing you to specify the data that you need in a single request. That is just one example, there are many many others that you can google if you are actually interested.
      - HeyHoJoe 6y ago
        This is just going around in circles. “This thing is bad practise”. Ok, don’t do that thing. This is not an argument against rest or for graphql.
        filoleg 6y ago
        I think the point the parent reply is trying to make is not that you cannot follow good practices with REST and that you somehow magically get it with GraphQL. I think their point is that GraphQL makes it much easier for devs to follow good practices and with less resistance.
        pookeh 6y ago
        Put differently, Graphql gives good defaults out of the box, and REST bad defaults.
        HeyHoJoe 6y ago
        Apologies for being rude, but that’s just nonsense. What ‘good defaults’ does graphql give you?
        pookeh 6y ago
        You no longer have to code data selectors explicitly for each endpoint.
        dosethree 6y ago
        You can do a lot of the things that Graphql does bu just a regular old JSON HTTP API. It's just not automatic and you will have to choose your own conventions
      - berkes 6y ago
        > I have seen many people try to solve the "too many requests" problem by slowing expanding rest responses into "god" objects. Fair point. But I ask my question again, differently worded: how does Graphql solve this? Why does GraphQL solve "many requests" and why can't you solve or avoid this in REST.
ldiracdelta 6y ago
My REST endpoints allow a `fields` parameter that specifies the requested fields of the endpoint. Even if you do have a huge object, you can pare it down. To get only `id` and `first_name` on a `User` endpoint, you do `.../rest/User/fields={"id"=true,"first_name"=true}` . Non-standard, but effective. The backend doesn't retrieve or send the un-needed fields.
- ehutch79 6y ago
  This. My endpoints also have fields that will only be sent if you specifically request them.
- saberdancer 6y ago
  And you can extend this pattern it by allowing "includes" which would signal to the backend to load and deliver the relations listed in the includes part of the query. This alone makes it impossible to get backend to return god entities with dozens of relations without explicitly specifying them.
  - ldiracdelta 6y ago
    I accomplish this with the same `?fields` query param and it is fractal. You can specify which _fields_ of the relations below the User you also want. If `User` had `groups` and `groups` had `permissions`, then I can do: let results = await fetch('/rest/Users/?fields=' + JSON.stringify( { id: true, first_name: true, groups: { name: true, permissions: { name: true } } }); My system has its limitations however. It can't do relational constraints like GraphQL or renaming of fields, but it is likely the 20% that gets you 80% of the way.
    - andrewingram 6y ago
      To be honest, once you can traverse relationships like this, you've basically just got GraphQL in disguise and might as well be using it. You're going to have all the same difficulties as GraphQL in making it perform well, but don't have the elegant (IMO) query language -- and lose some of the expressivity of fields/relations being able to accept arguments.
013a 6y ago
We have a `user` GraphQL type. It has 200+ fields and resolvers into other data. Fortunately, clients don't need to pull everything. Well, within one of our frontend apps, someone wrote a "GetUser" query fragment, wrapped it in a react hook to make it easy to use, and now anytime anyone anywhere wants to get a user, even with one field, they're getting 100+ fields they don't want. Anytime someone needs a new field on a user, they don't create a new query; they just add the field to that "GetUser" query. Now, I've told several GraphQL advocates that setup (in our local community and online), and unfailingly they balk at it. Well, you're doing GraphQL wrong, everyone makes mistakes, you should be more selective, etc etc etc. I think that's fair; being more specific sounds like a good pattern. Except, we are not certain the performance wouldn't suffer should we move everything to more selective queries. The issue is caching. If you have ten queries each requesting one field, the cache can't saturate until after ten network requests. But, one mega query, and now the remaining nine queries can just pull from the cache. Sure, the mega query takes longer than one mini-query, but its not longer than ten mini-queries. I only outline this to say: GraphQL is not a magic bullet. Every single thing you can do which would ruin a REST API is also possible in GraphQL. REST API responses naturally evolve into god objects. GraphQL APIs solve the god object issue server-side by saying "god objects are fine", then push the responsibility of not abusing it onto the client (and it should be obvious, the client is the worst place to solve almost every problem, but that's another topic). GraphQL is easier and better for some things, far harder for other things. At the end of the day, its no worse than REST. I don't recommend it, but that's only just because its new; unless a new technology offers some very easy to express, tactile benefits for your business, just wait for it to mature. When you get down to it, GraphQL's benefits are definitely not tactile, but they're still there, and I think over time it will evolve into something very interesting.
- filoleg 6y ago
  I agree with your point about caching, except, i think, it is missing one important detail that makes your argument less one-sided against GraphQL. What you described is absolutely correct, except it is only the case if we cache by query. If we cache by objects and fields, none of those issues you described become relevant, and caching by object/field (as opposed to caching by query) in general seems like a better practice imo, aside from certain very specific scenarios. In fact, it seems like the official GraphQL docs recommend that approach as well [0]. 0. https://graphql.org/learn/caching/ https://graphql.org/learn/caching/
goostavos 6y ago
Meh, people have been selling "technology-X" using this exact same argument since the beginning of time. You could swap out the "GraphQL" in your final sentence for "micro-services" and it'd swear that I've seen it in another thread ^_^ The existence of a God Response / God Object / or just a generally horrific and coupled system strikes me as a particularly human induced problem which no specific technology can actually fix.
s1k3s 6y ago
I disagree. Where I work (and for some reason I expect this is the case in plenty of other places), APIs don't grow into being shit because the programmer doesn't know that "returning comments on the response of GET user/1" is bad, but because their manager asks them to implement that feature as fast as possible. Given that requirement, of course the guys will just throw the comments in that already existing endpoint instead of building "GET comments?user=John", right? I'm a big fan of the saying "complexity has to live somewhere" and I think that's exactly what GraphQL is doing: moving the complexity to another layer.

by sho 6y ago

HeyHoJoe 6y ago

I think that’s just pretty basic bad design, to be honest.

diveanon 6y ago
Thats the whole point, REST facilitates and often encourages bad design.
- berkes 6y ago
  How does it encourage this, and how does graphQL discourage this? I've always held a strict rule where The R in REST stands for Resource (which isn't true). There's a user, an Invitation (and not an invite action on user, nor a state:invited or invited_at on user). there's a Session. There's links that clients follow, and everything is as small as possible. I really don't see how REST encourages God objects.
  - diveanon 6y ago
    I have seen many people try to solve the "too many requests" problem by slowing expanding rest responses into "god" objects. GQL solves this problem elegantly by allowing you to specify the data that you need in a single request. That is just one example, there are many many others that you can google if you are actually interested.
    - HeyHoJoe 6y ago
      This is just going around in circles. “This thing is bad practise”. Ok, don’t do that thing. This is not an argument against rest or for graphql.
      - filoleg 6y ago
        I think the point the parent reply is trying to make is not that you cannot follow good practices with REST and that you somehow magically get it with GraphQL. I think their point is that GraphQL makes it much easier for devs to follow good practices and with less resistance.
      - pookeh 6y ago
        Put differently, Graphql gives good defaults out of the box, and REST bad defaults.
        HeyHoJoe 6y ago
        Apologies for being rude, but that’s just nonsense. What ‘good defaults’ does graphql give you?
        pookeh 6y ago
        You no longer have to code data selectors explicitly for each endpoint.
        dosethree 6y ago
        You can do a lot of the things that Graphql does bu just a regular old JSON HTTP API. It's just not automatic and you will have to choose your own conventions
    - berkes 6y ago
      > I have seen many people try to solve the "too many requests" problem by slowing expanding rest responses into "god" objects. Fair point. But I ask my question again, differently worded: how does Graphql solve this? Why does GraphQL solve "many requests" and why can't you solve or avoid this in REST.

ldiracdelta 6y ago

My REST endpoints allow a `fields` parameter that specifies the requested fields of the endpoint. Even if you do have a huge object, you can pare it down. To get only `id` and `first_name` on a `User` endpoint, you do `.../rest/User/fields={"id"=true,"first_name"=true}` . Non-standard, but effective. The backend doesn't retrieve or send the un-needed fields.

ehutch79 6y ago
This. My endpoints also have fields that will only be sent if you specifically request them.
saberdancer 6y ago
And you can extend this pattern it by allowing "includes" which would signal to the backend to load and deliver the relations listed in the includes part of the query. This alone makes it impossible to get backend to return god entities with dozens of relations without explicitly specifying them.
- ldiracdelta 6y ago
  I accomplish this with the same `?fields` query param and it is fractal. You can specify which _fields_ of the relations below the User you also want. If `User` had `groups` and `groups` had `permissions`, then I can do: let results = await fetch('/rest/Users/?fields=' + JSON.stringify( { id: true, first_name: true, groups: { name: true, permissions: { name: true } } }); My system has its limitations however. It can't do relational constraints like GraphQL or renaming of fields, but it is likely the 20% that gets you 80% of the way.
  - andrewingram 6y ago
    To be honest, once you can traverse relationships like this, you've basically just got GraphQL in disguise and might as well be using it. You're going to have all the same difficulties as GraphQL in making it perform well, but don't have the elegant (IMO) query language -- and lose some of the expressivity of fields/relations being able to accept arguments.

013a 6y ago

We have a `user` GraphQL type. It has 200+ fields and resolvers into other data. Fortunately, clients don't need to pull everything. Well, within one of our frontend apps, someone wrote a "GetUser" query fragment, wrapped it in a react hook to make it easy to use, and now anytime anyone anywhere wants to get a user, even with one field, they're getting 100+ fields they don't want. Anytime someone needs a new field on a user, they don't create a new query; they just add the field to that "GetUser" query. Now, I've told several GraphQL advocates that setup (in our local community and online), and unfailingly they balk at it. Well, you're doing GraphQL wrong, everyone makes mistakes, you should be more selective, etc etc etc. I think that's fair; being more specific sounds like a good pattern. Except, we are not certain the performance wouldn't suffer should we move everything to more selective queries. The issue is caching. If you have ten queries each requesting one field, the cache can't saturate until after ten network requests. But, one mega query, and now the remaining nine queries can just pull from the cache. Sure, the mega query takes longer than one mini-query, but its not longer than ten mini-queries. I only outline this to say: GraphQL is not a magic bullet. Every single thing you can do which would ruin a REST API is also possible in GraphQL. REST API responses naturally evolve into god objects. GraphQL APIs solve the god object issue server-side by saying "god objects are fine", then push the responsibility of not abusing it onto the client (and it should be obvious, the client is the worst place to solve almost every problem, but that's another topic). GraphQL is easier and better for some things, far harder for other things. At the end of the day, its no worse than REST. I don't recommend it, but that's only just because its new; unless a new technology offers some very easy to express, tactile benefits for your business, just wait for it to mature. When you get down to it, GraphQL's benefits are definitely not tactile, but they're still there, and I think over time it will evolve into something very interesting.

filoleg 6y ago
I agree with your point about caching, except, i think, it is missing one important detail that makes your argument less one-sided against GraphQL. What you described is absolutely correct, except it is only the case if we cache by query. If we cache by objects and fields, none of those issues you described become relevant, and caching by object/field (as opposed to caching by query) in general seems like a better practice imo, aside from certain very specific scenarios. In fact, it seems like the official GraphQL docs recommend that approach as well [0]. 0. https://graphql.org/learn/caching/ https://graphql.org/learn/caching/

goostavos 6y ago

Meh, people have been selling "technology-X" using this exact same argument since the beginning of time. You could swap out the "GraphQL" in your final sentence for "micro-services" and it'd swear that I've seen it in another thread ^_^ The existence of a God Response / God Object / or just a generally horrific and coupled system strikes me as a particularly human induced problem which no specific technology can actually fix.

s1k3s 6y ago

I disagree. Where I work (and for some reason I expect this is the case in plenty of other places), APIs don't grow into being shit because the programmer doesn't know that "returning comments on the response of GET user/1" is bad, but because their manager asks them to implement that feature as fast as possible. Given that requirement, of course the guys will just throw the comments in that already existing endpoint instead of building "GET comments?user=John", right? I'm a big fan of the saying "complexity has to live somewhere" and I think that's exactly what GraphQL is doing: moving the complexity to another layer.