On my servers I do away with either. Instead client submits JSON object and gets JSON answer. Simple HTTP based RPC. But my servers of course are not some generic storage of knowledge for mining. Instead they're doing some particular processing and administration. So clients are not given as much freedom as in GraphQL. And I am free from headache of implementing some generic backend query service for no benefit.
REST vs. GraphQL – A search for evidence on which is better
151–160 of 243 posts
Re: REST vs. GraphQL – A search for evidence on which is better
#152Earlier quoted context omitted.
I think he is saying graphql doesn't have recursion.
Well yes, that would be a better way to say it, no recursively nested objects, there is a Github discussion about it here: https://github.com/graphql/graphql-spec/issues/91 And if someone else is interested to take a look at my clone project (it's in Clojure), for the GraphQL issue you can search for "request recursively nested objects". https://www.giovanialtelino.com/project/hacker-news-graphql/
Thanks! That is really good to know. I wasn't aware of that limitation.
Re: REST vs. GraphQL – A search for evidence on which is better
#153Out of all the API implementations I've created in my career I've had the most success implementing BFF (Backends for Frontends) with simple RPC'ish endpoints. Everything else never quite fit right and wasted so many hours. https://samnewman.io/patterns/architectural/bff/
Isn't that effectively what GraphQL is supposed to be?
Not specifically but it can could be used for it. GraphQL just a message spec (like dare I say, SOAP). But if you use it with BFF then the value of the dynamic query aspects seems less valuable. With a BFF your App/UI and endpoints can be tightly coupled. If a specific page/component/action needs data structured in a specific way then you just make the endpoint do exactly that. You can accomplish this over GraphQL but it seems like an unnecessary extra layer at that point.
Re: REST vs. GraphQL – A search for evidence on which is better
#154Earlier quoted context omitted.
The idea is that there is a sort of contract between the backend and the frontend. If I conscientiously create an API endpoint that allows you to fetch articles with their comments, I'm gonna craft that query to avoid the N+1 problem. So when someone uses it, perf isn't scaling linearly. With GraphQL, you can have a frontend person add comments without anyone from the backend team modifying anything. They say "yay it…
> With GraphQL, you can have a frontend person add comments without anyone from the backend team modifying anything Well, they can do that with REST as well. They will just make a bunch of requests. That is what usually happens in the real world. However, the difference is that with REST, it all just looks like isolated independent requests. With graphQL it becomes more clear that someone wants to query all comments…
I don't know, I still think you're much more likely to have a frontend dev get annoyed by having to kick off 20 requests (and seeing that perf impact in their own devtools) and ask backend to give them an endpoint that can get all the content in one go.
Re: REST vs. GraphQL – A search for evidence on which is better
#155Earlier quoted context omitted.
> With GraphQL, you can have a frontend person add comments without anyone from the backend team modifying anything Well, they can do that with REST as well. They will just make a bunch of requests. That is what usually happens in the real world. However, the difference is that with REST, it all just looks like isolated independent requests. With graphQL it becomes more clear that someone wants to query all comments…
I don't know, I still think you're much more likely to have a frontend dev get annoyed by having to kick off 20 requests (and seeing that perf impact in their own devtools) and ask backend to give them an endpoint that can get all the content in one go.
Maybe, but is it really a good idea to rely on the laziness of developers and hope they give you feedback? I've not seen this work out well so far.
Re: REST vs. GraphQL – A search for evidence on which is better
#156Earlier quoted context omitted.
REST endpoints typically return data I don't need. For example, the twitter REST API `/1.1/users/show.json?screen_name=twitterdev` it will show me the last tweet for the user. Presumably this involves perhaps waiting for tweet service when the client may not even want the tweet. A GraphQL client can be more explicit about what edges to select.
There are specs like jsonapi that solve this problem. I’ve never been entirely convinced that GraphQL is better than actual REST, even if it’s better than most of the APIs people call RESTful
JSON:API provides some of the same functionality as GraphQL, like specifying which fields and nested resources you want, but at that point you’re going to have the same problems with ensuring good performance with any combination of included fields and relationships.
Re: REST vs. GraphQL – A search for evidence on which is better
#157Earlier quoted context omitted.
I do not think that XML is a hypertext. So I agree with you. HTML is a hypertext. Yes, Github probably has one of the most as-REST-like-as-possible JSON apis, and it's mostly wasted effort. It would be just as usable, as an API, without all that stuff, since it is consumed by code, not a browser/human.
What does HTML have that XML doesn't have? Isn't XML a superset of HTML?
Maybe the following links can help in understanding hypertext/hypermedia?
Re: REST vs. GraphQL – A search for evidence on which is better
#158Earlier quoted context omitted.
What's the difference between "losing it" and "it doesn't remain"? I didn't say GraphQL lost the feature, I said it lost the advantage. I see also the paper says, in bold, "it is unfair to attribute the gains observed with GraphQL only to the IDE", but elsewhere they trumpet the ability of the IDE to interpret and enforce the schema as significant. And again, we can accept that the feature is useful without conceding…
You said "benefit", not advantage.
I did not, I was paraphrasing the paper.
"By triangulating the results of RQ1 and RQ2, it is clear that the avaliability of a type system — expressed as a schema — is one of the key benefits provided by GraphQL, in terms of reducing the effort to implement queries, when compared to REST."
The paper itself was using the word benefit in comparison to REST.
Re: REST vs. GraphQL – A search for evidence on which is better
#159Earlier quoted context omitted.
I don't know, I still think you're much more likely to have a frontend dev get annoyed by having to kick off 20 requests (and seeing that perf impact in their own devtools) and ask backend to give them an endpoint that can get all the content in one go.
Maybe, but is it really a good idea to rely on the laziness of developers and hope they give you feedback? I've not seen this work out well so far.
To my mind, a system architecture that does not take into account is the flawed one, not the other way around.
Re: REST vs. GraphQL – A search for evidence on which is better
#160Earlier quoted context omitted.
This is the strange thing about GraphQL, it shifts the work to someone else so you'll end up with people teams that benefit and teams that don't. You also need opt in from both the client and server. I wish there was a client side library that implemented GraphQL as an abstraction over REST, GraphQL or other backend APIs. It would be nice to use some of the GraphQLs query/join features across several backend services…
There’s actually nothing server specific about GraphQL. The specification makes no mention of transport layer, it’s simply a type system + query executor. You can pretty easily (if you have experience with the GraphQL reference implementation in JavaScript) create a GraphQL layer that sits inside of the browser, with a schema created by the UI team, that executes calls to REST APIs to resolve the data. You could thin…
I don't think #2 is that big of a deal if all requests happen async, which they should with a client side ORM, and if you're using http2.
I think the bigger problem there is how those multiple REST calls map to your data stores. Very rarely will there be clean separation of data between endpoints, and the stateless nature of REST makes it harder to optimize each call -- meaning, there will almost certainly be redundant queries.
That said, with GraphQL, your front end dev may not realize they are executing the equivalent of many REST calls, which is another problem :) I wouldn't say it's harder to optimize if you look at the application as a whole, though.