GraphQL Mesh | Hacker News Reader

GraphQL Mesh

github.com

108 pointsdiggan13 comments

In the Clojure world, Pathom scratches the same itch and seamlessly connects different domains that can then be queried together.

It uses EQL behind the scenes and also converts to GraphQL

That's very interesting and something I've been looking for the past months, so thank you for sharing!

This is an open question to the comment community, is anyone here making tradeoffs between GraphQL and using HTTP2 for these existing APIs? I'd be really interested to know which way people landed and why.

HTTP2 and GraphQL solve different problems. HTTP2 solves the connection per concurrent request problem of HTTP. GraphQL solves for lower overall request count.

With “just” HTTP2, you’d be doing one of the following:

- creating bespoke endpoints

- creating an adhoc GraphQL-like API

- introducing latency equal to the round trip latency multiplied by the number of layers the query is deep

If your problem is that getting the data from the API is slow, both GraphQL and HTTP2 solve your problem: HTTP2 allows you to send REST requests faster, both more concurrently and with faster round trip; GraphQL instead allows you to combine all your requests into a single request that takes a single round trip.

GraphQL obviously provides a more complete solution (one request is better than many), but at the cost of a lot of complexity.

> one request is better than many

This is plainly not true. Web servers are designed to serve concurrent requests. So are databases. HTTP2 drastically improves the networking part of this. GraphQL offers a unified request-response object without needing to combine responses. It provides no guarantees about improved performance, particularly when the solution is automated and there's no way for a requester to reason about the performance implication of the queries they're issuing. It almost certainly provides worse performance than well designed RESTful endpoints requested concurrently.

GraphQL also moves the N+1 problem (data fetching being dependent on other data that you are fetching) to the server side where latencies should theoretically be lower.

Well a regular http API is going to be better for caching. Right now I'm only aware of one product that supports caching in graphql but there are hundreds of thousands of CDN nodes around the world that will cache the result of 'GET /product/5'

HTTP2 is great if you have independent requests and want to avoid head of line blocking. I'm not aware of any sort of streaming/partial result capabilities for graphql.

Graphql is great if you want to give a trusted client a richer API and/or if your infrastructure has good ways of handling abusive API users.

https://www.apollographql.com/docs/link/links/http/#options

useGETForQueries

Couldn't you achieve marginally identical performance with PUSH on HTTP2, plus the independent requests using the same connection?

And I do understand the advantage of a single request, but the _tradeoff_ in backend development time does seem extreme.

Keen to know if you can expand on trusted client _a richer API_ - what's richer than building your on request from many small endpoints?

Posted previously: https://news.ycombinator.com/item?id=22665276

About time, very cool

Awesome

Reply on news.ycombinator.com