Hacker News Reader

Comment by merb | Hacker News Reader

> The need to do multiple round trips to fetch data required by a view: With GraphQL, you can always fetch all the initial data required by a view with a single round-trip to the server.

I'm not sure what's different. You can actually implement the same with plain old http api's, also.

View on HN

Especially since avoiding n+1 query situations involves hand optimizing a lot of stuff anyways. In my experience it's not really any less work than just aggregating stuff in a regular HTTP API, but it does seem to give a better developer experience on the frontend. At a certain scale, I think it could be worth the investment, but I don't think it really lives up to the hype.

well maybe on the frontend it looks good, but on the backend? meh parsing such a query is not painless. and maybe "simple" queries are looking good and simple, complex and bigger queries and big schema's are really really akward to implement.

Readily available packages in most languages can parse graphql queries for you.

> Especially since avoiding n+1 query situations involves hand optimizing a lot of stuff anyways.

Rarely. Assuming the GraphQL server is using REST endpoints behind the scenes, i'm yet to find a request waterfall that required manual rather than automatic optimizations. I'm assuming there are cases where a manual path is faster, but they're less common that you'd think.

Not sure how magical your automatic optimizations are - but my experience does not at all mirror yours. i've certainly had to hand-optimize queries to improve performance, on top of the query already being automatically optimized. Removing unused data, tying across custom relations and moving things into different forms of caching are all quite manual efforts I've done plenty of. So, not sure how "less common than you'd think" holds up to scrutinization. I'm just one counterpoint.

Mostly i'm referring to the methodology I followed here: https://dev-blog.apollodata.com/optimizing-your-graphql-requ...

I haven't looked into optimising other types of architecture (eg GraphQL server talking directly to the database), but there seem to be plenty of solutions that people are happy with.

That doesn't touch upon the N + 1 query problem at all.

Can you tell me which particular problem you're talking about? When people talk about GraphQL and the n+1 problem, they're typically talking about the problem which Dataloader solves, and this is the problem this article builds upon.

The N + 1 at the database level implies that for every object's remote relations you have to do another query instead of subsuming the object in a large invididual SQL query.

Right but then you have to build a custom http api for each and every new view. Oh, and now you altered the view a tiny bit and need some more fields? Add yet another api. Oh, you did a redesign and you only need a tiny bit of data now? Either add another api again, or deal with the fact that you're wasting bandwidth by sending a bunch of unnecessary data.

or you can pass the fields you want in your request, and then realizing it would be simplier to fetch all your data in only one endpoint to avoid multiple roundtrips, create a giant request-parsing-data-fetching logic to respond with some kind of nested data, yeah GraphQL is useless because we can build a new one from scratch for each of our projects ;)

...at which point you reinvented the wheel and it's very likely that the GraphQL library for your language works better and maybe faster.

<winks>

You can but you have to write all the allowed query combinations. Graphql is more flexible. It's also declarative, so you can provide a widget with the schema it needs.

Another benefit of graphql is that is a "lingua franka", you can use it internally, between microservices, etc.

Indeed, some of the points which I loved the most when I started using it was how it allows to avoid writing any serialization method, how it helps centralize permissions, and, as said in the article, the simplicity it adds if you want to add fields in your queries.

The difference is that in pure RESTful APIs you don't have that ability anymore. So, when all you know is RESTful design, GraphQL is solving a problem. But in the end you'll still implement a "plain old http" API when interfaces have stabilized and performance matters.

Until then, what you gain is "only" a completely decoupled backend that will accommodate frontend developers work in exchange for more generic logic in the backend. Not necessarily a bad thing, if this is how your shop works.

But you have to do it manually. GraphQL removes that pain (or at least that's my understanding:.

It removes the API design, versioning, etc. pain which is probably huge in an organization as large as facebook.

But there's still going to be a decent bit of backend tuning which in my experience is the hard part (unless the organization is so dysfunctional new API version design meetings descend into a hostage exchange).

Yes, that's true. But I don't think that's legit within the technical and absolute definition of REST. Perhaps they used that strict definition in order to differentiate the product?

Like PostgREST does :)

I love me some complex async/await chains!

Reply on news.ycombinator.com