GraphQL Performance Monitoring Is Hard

Re:GraphQL Performance Monitoring Is Hard by strken on Saturday July 27, 2019 @04:32AM (#20541055)

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.

[ Parent | on HN ]

Re:GraphQL Performance Monitoring Is Hard by JoachimSchipper on Saturday July 27, 2019 @05:23AM (#20541171)

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

[ Parent | on HN ]

Re:GraphQL Performance Monitoring Is Hard by biggestdecision on Saturday July 27, 2019 @05:51AM (#20541234)

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.

[ Parent | on HN ]

Re:GraphQL Performance Monitoring Is Hard by jeremyjh on Saturday July 27, 2019 @10:06AM (#20542087)

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

[ Parent | on HN ]

Re:GraphQL Performance Monitoring Is Hard by strken on Saturday July 27, 2019 @05:46AM (#20541223)

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.

[ Parent | on HN ]

Re:GraphQL Performance Monitoring Is Hard by vmasto on Saturday July 27, 2019 @08:29AM (#20541719)

Can you expound on the concerns?

[ Parent | on HN ]