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