3 ms·
I think that’s just pretty basic bad design, to be honest.
by HeyHoJoe 6y ago
I think that’s just pretty basic bad design, to be honest.
- diveanon 6y agoThats the whole point, REST facilitates and often encourages bad design.
- berkes 6y agoHow 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 agoI 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 agoThis 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 agoI 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 agoPut differently, Graphql gives good defaults out of the box, and REST bad defaults.
- HeyHoJoe 6y agoApologies for being rude, but that’s just nonsense. What ‘good defaults’ does graphql give you?
- 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.