
GraphQL Performance Monitoring Is Hard - tepidandroid
https://medium.com/@__xuorig__/why-graphql-performance-monitoring-is-hard-41381bc7c44d
======
ThePhysicist
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.

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 "long tail" queries
would always run into timeouts.

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

To all of you who use GraphQL in practice, how do you solve this issue?

~~~
underwater
Restricting the queries is backwards. You expose should only expose the few
that makes sense in the domain of your app, and optimise for those.

GraphQL scares people because it seems to to allow arbitrary complex queries
from applications. But that complexity was always there. REST just hides it in
an unbounded number of predictable HTTP requests.

~~~
bernawil
I don't get the "arbitrary complexity" issue. It's only a problem if you're
auto generating everything in your schema, but otherwise you limit the fields
of problematic types by hand and that's it.

The same computatational challenges we've always had with mapping relational
models to REST didn't go away, mainly: N+1 queries, recursive types and query
parameters adding complexity.

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

------
013a
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'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. "You dumb backend devs created so much
complexity for us frontenders, now its our turn to ruin YOUR part of the
system."

GraphQL may one day have the tooling and ecosystem to reduce the net
complexity of the entire system, but that day wasn't a year ago, its
definitely not today, and judging by how long the community has had to mature
and _still_ hasn't... probably won'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 "make a GraphQL server possible."

Given how slowly things are progressing in GraphQL-land, I'd estimate that it
has another two years before the zeitgeist moves against it. Though I hope I'm
wrong, because its got some pretty cool ideas and is dramatically better for
frontend development than anything else out there.

[1]
[https://twitter.com/ryanflorence/status/1060557386421723136](https://twitter.com/ryanflorence/status/1060557386421723136)

------
maktouch
We solved this by using persistent queries that maps it like

/graphql/{queryname}/{hash}?{params}

Multiple advantages:

1) client doesn't need to send the whole query unless it doesn't exist. All of
this is handled automatically.

2) http caching of queries are now possible since it's a get instead of post

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

------
kromem
Not really.

I mean, not any more difficult than any other internal component of an
application.

Yes, you can'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.

Poof - you have an extremely nuanced view of your application performance.

Add in aggregate time metrics for each unique query/mutation and you'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.

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

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

Yes, this does make instrumentation and rate limiting harder, but not
impossible. It’s akin to using SQL... sometimes the query optimizer does weird
things, but declaratively asking for your data is much better than
imperatively pulling and joining it yourself.

~~~
BinaryIdiot
> 1\. Fewer API round trips compared to REST.

Why? This is always my chief complaint about GraphQL: there is no reason it
should take fewer trips than directly hitting an endpoint unless you're
structuring everything very rest-y in which case you're doing it wrong and
GraphQL is a bandaid (and you'd still probably make the same amount of trips
unless you're heavily caching things). IMO.

> 2\. Clients only download the data they need.

Most third party APIs let you specify what fields you want via a query string
or post variable which amounts to the same thing.

Honestly I think if people stopped trying to force REST into everything and
just made RPC like calls to HTTP we'd have far less of a need for GraphQL.

Don't get me wrong, I still think GraphQL is pretty cool for third party
access in some respects but I don't think it's as useful as a lot of people
make it out to be.

~~~
biggestdecision
Sure, it's possible to setup a REST api with those features (return full
objects for fields rather than ID's, client specifies which fields to return
in the query). But then you've basically just built a graphQL api. Any syntax
you pick for allowing the client to specify which (nested) fields to return is
going to look like a graphQL query. And using graphQL gives you some nice
tools to use on the client side.

~~~
BinaryIdiot
> But then you've basically just built a graphQL api

Not really. The type of API where you specify what you want and the API itself
included whatever data you need in an RPC fashion has been around for decades,
I feel weird calling it a "graphql api".

Ultimately GraphQL gives you some tools. The developer just has to figure out
if those tools make up for the additional overhead (processing, size,
training, etc). Sometimes it'll be justified I just think more often then not
it really isn't.

~~~
wereHamster
> [other types of APIs] has been around for decades

GraphQL is indeed not a new invention. It's a standardisation of existing
ideas, that has been given a particular name, and a whole community of people
who are building tooling around it.

If you tell me you are using/implementing GraphQL then I immediately know what
to expect. I know which tools I can use, I know you have a schema, I know I
can run queries and the syntax of those etc. But if you tell me that you are
using a REST/HATEOAS/RPC with some particular query syntax then I first have
to spend a day reading through the documentation to understand the API.

~~~
chii
> REST/HATEOAS/RPC ... I first have to spend a day reading through the
> documentation to understand the API.

i think you're giving graphql too much credit, and give too little to REST.

The schema of graphql is going to require just as much reading up and domain
knowledge as the REST api.

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

------
itake
Isn't that what
[https://www.apollographql.com/platform](https://www.apollographql.com/platform)
solves?

~~~
gms
Yep, only if you're using Apollo though.

------
xemdetia
Oh goody I just hit my first medium.com effective paywall. Can we kill it now
and go back to ordinary blog hosting?
[https://i.imgur.com/Ii3VcfA.png](https://i.imgur.com/Ii3VcfA.png)

~~~
ckuijjer
[https://outline.com/RckbpG](https://outline.com/RckbpG)

