Hacker News new | past | comments | ask | show | jobs | submit login
GraphQL Mesh (github.com)
107 points by diggan 3 days ago | hide | past | web | favorite | 13 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.

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.



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?


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.


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.

> 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.



About time, very cool

Awesome



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: