GraphQL Performance Monitoring Is Hard

I always thought it was a bit crazy to let the client control the computational complexity of a query (to a certain degree) as it makes query optimization really difficult.<p>A few years back I designed a REST API and made the mistake of allowing too many query parameters, which made it really hard to optimize the database as there were hundreds of possible filter combinations (some requiring joins) that a client could ask for and that needed to be covered with indexes, so while most of the common queries worked well some of the &quot;long tail&quot; queries would always run into timeouts.<p>When using GraphQL with a backend like Hasura that generates SQL queries I would think that you have the same problem for complex data models, as there will be countless combinations of filters and joins that your database would need to efficiently cover. From what I understand most organizations solve this by either restricting the types of queries you can make through GraphQL or by just defining timeouts and dropping queries that take too long (which does not offer a great user experience).<p>To all of you who use GraphQL in practice, how do you solve this issue?

I am confident that GraphQL can be superior to REST in an scenario in which the client is iterating on features at an exponentially faster pace than the back end development can support. However, I’ve yet to find myself in that scenario. Simplicity of instrumentation and rate limiting are higher priorities in my experience.

This tweet from Ryan Florence [1], a big influencer in the frontend community, is something I think back to pretty often. Its so clear to me that GraphQL is designed and pushed primarily by frontend devs who&#x27;s goal is, probably unconsciously, to reduce the complexity and thus workload of their slice of the system. Its a selfish local optimization that dramatically increases the net complexity of the entire system. &quot;You dumb backend devs created so much complexity for us frontenders, now its our turn to ruin YOUR part of the system.&quot;<p>GraphQL may one day have the tooling and ecosystem to reduce the net complexity of the entire system, but that day wasn&#x27;t a year ago, its definitely not today, and judging by how long the community has had to mature and <i>still</i> hasn&#x27;t... probably won&#x27;t be for a very long time, if ever. Probably because, again, its pushed by frontend developers primarily, so the pace of innovation on the backend side of it is dramatically slower. Apollo Client is an amazing piece of software that does some insanely smart things; Apollo Server is a thin wrapper around Express which does nearly nothing of value beside &quot;make a GraphQL server possible.&quot;<p>Given how slowly things are progressing in GraphQL-land, I&#x27;d estimate that it has another two years before the zeitgeist moves against it. Though I hope I&#x27;m wrong, because its got some pretty cool ideas and is dramatically better for frontend development than anything else out there.<p>[1] <a href="https:&#x2F;&#x2F;twitter.com&#x2F;ryanflorence&#x2F;status&#x2F;1060557386421723136" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;ryanflorence&#x2F;status&#x2F;1060557386421723136</a>

We solved this by using persistent queries that maps it like<p>&#x2F;graphql&#x2F;{queryname}&#x2F;{hash}?{params}<p>Multiple advantages:<p>1) client doesn&#x27;t need to send the whole query unless it doesn&#x27;t exist. All of this is handled automatically.<p>2) http caching of queries are now possible since it&#x27;s a get instead of post<p>3) we can check slow queries using similar tools as rest. When we see a query being slow, we check each resolvers. We usually keep the queries simple

Not really.<p>I mean, not any more difficult than any other internal component of an application.<p>Yes, you can&#x27;t just aggregate by URL endpoint, but add opentracing and start at the top level resolver, and then start a new segment at each nested resolver.<p>Poof - you have an extremely nuanced view of your application performance.<p>Add in aggregate time metrics for each unique query&#x2F;mutation and you&#x27;ll have an even better view of what going on - far better than if you were simply looking at API endpoint timings in the first place.

I keep seeing stuff like this and wonder where the actual advantage to graphQL is?

Is it tho? We’re using elastic APM which is free and the Nodejs modules just work. They’re breaking down every request down to the database call.

Isn&#x27;t that what <a href="https:&#x2F;&#x2F;www.apollographql.com&#x2F;platform" rel="nofollow">https:&#x2F;&#x2F;www.apollographql.com&#x2F;platform</a> solves?

Oh goody I just hit my first medium.com effective paywall. Can we kill it now and go back to ordinary blog hosting? <a href="https:&#x2F;&#x2F;i.imgur.com&#x2F;Ii3VcfA.png" rel="nofollow">https:&#x2F;&#x2F;i.imgur.com&#x2F;Ii3VcfA.png</a>