Hacker News Reader

Comment by tjpnz | Hacker News Reader

>1. Fewer API round trips compared to REST. 2. Clients only download the data they need. No more REST silly patterns like BFF trying to support multiple client needs.

In most cases a thoughtfully designed REST API built according to HATEOAS shouldn't exhibit these problems. I've seen too many teams with a flawed understanding of both viewing GraphQL as some kind of silver bullet. Instead of stopping to consider their architecture they just rush out and implement GraphQL only to find themselves having significantly worse performance issues than they were having before.

View on HN

My understanding of the advantage of GraphQL is that it allows you to load a structure like

    user {
      groups(first: 10) {
        posts(first 1) {
          content
          author {
            name
            address {
              state
            }
          }
        }
      }
    }

and have all the round-trips take place within a datacentre, instead of needing to query

    /user 
    /user/12/groups?limit=10
    /groups/34/posts?limit=1
    /posts/56
    /users/78
    /users/78/address

and without having to write a separate

    /top_posts_view

endpoint.

I don't understand from the description "a thoughtfully designed REST API built according to HATEOAS" what your proposal to solve this problem is.

A quick search suggests that GraphQL should usually cause one client -> server -> SQL-server query - i.e. only one network round trip. No?

I've only used it to aggregate backend services rather than as an SQL query builder, and this is also how it's used at Facebook.

I'd have concerns about writing business logic in resolvers. If I was using it with a single SQL db I'd probably write a separate non-GraphQL layer for business logic and keep the resolvers thin.

Can you expound on the concerns?

Client-API round trips matter, because the latency is very high. API-DB latency will be much lower, so the number of round trips there is less important. GraphQL allows you to query any nested structure in one Client-API round trip, but there may be many API-DB round trips per query.

It is better to have the resolver aggregate data, than to have multiple calls from the client to do it. The earliest uses of GraphQL was as a service aggregater. I'd be curious to know where you are seeing this "advice".

REST works, but it forces you to use a single endpoint at a time.

For example, let's say you have have two endpoints /albums/1/ and /users/2/ and want to query them both at the same time.

They're unrelated data, so following REST best practices would make them separate endpoints.

With GraphQL, they're seperate resolvers but you can write

   {
     albums { get(id: 1) { .... } }
     users { get(id: 2) { .... } }
   }

And combine them those two calls into a single query. Maybe this is also possible via REST, but I haven't seen it.

Oh! This is interesting. I didn’t know I could do this too. That’s a bit nicer even than only the combining of nested calls that I was aware of.

If the endpoints are unrelated and you know them both before querying either, you can certainly query them concurrently from nearly any client language.

GraphQL can do it, but I don't think that's a big strength, compared to the dependent queries it can do. Using the results from one query to drive a further query without going back to the client will save a bunch of time if the client is far from the server.

Sure you can make two queries concurrently, but does the server know you are doing that? With GeaphQL the server sees both queries at once, and can potentially optimize over that once someone notices that in their logs. And it expresses itself as a single network connection.

I do agree though with your point about dependent queries, though I have only used GraphQL for internal apis so my experience doesn’t include that sort of problem.

Reply on news.ycombinator.com