GraphQL Mesh


108 points | by diggan 179 days ago


  • beders 178 days ago

    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

    • diggan 178 days ago

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

    • aplummer 178 days ago

      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.

      • shanemhansen 178 days ago

        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.

        • TurningCanadian 178 days ago
          • aplummer 177 days ago

            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?

          • abhorrence 178 days ago

            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

            • wongarsu 178 days ago

              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.

              • robjan 178 days ago

                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.

                • eyelidlessness 178 days ago

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

            • cameronfraser 178 days ago
              • AzzieElbab 178 days ago

                About time, very cool

                • viveknidhi 178 days ago


                  • barnyfried 178 days ago

                    GraphQL is crap. I dont want a mesh of crap.