GraphQL Support

[sl0thentr0py]

Starting a thread to gauge interest in first class graphql support. Please upvote / comment if you'd like to see this happen.

Some things to kick off

• Better parsing/semantic understanding of graphql payloads/queries
• Graphql transaction names / spans
• graphene integration for sentry-python
• apollo integrations for JS/node
• graphql-ruby integration for sentry-ruby

[ueman]

Hey, I've been playing around with getting GraphQL monitoring into Sentry for the Dart/Flutter environment. See the library at https://pub.dev/packages/sentry_link. I've also created an issue for better GraphQL support at #33723.

I've "hacked" the stacktrace format to show errors in queries with variables, which works okay-ish. See this screenshot:

My main points of interest are:

• Showing errors in the queries
• Showing GraphQl extensions nicely in relation to the query
• I'm mostly interested in the client side of using GraphQL, not in the server side of it.

I'm happy to answer questions if there are any.

[ueman]

While GraphQL itself is transport protocol agnostic, it's commonly used with HTTP calls, which leads to an interesting issue if used with existing http integrations: breadcrumb duplication. When I do a GraphQL request, I want to have individual traces for every part of it, http and graphql. Though, for breadcrumbs I don't care about the body of the http request, because that can be done better by the graphql integration. I do still want to have the headers of the http request. It would be nice to be able to merge graphql and http breadcrumbs into one. I guess it's similar for other transport protocols.

Another interesting issue is, that requests can have multiple queries and a subset from them can fail. That raises the question wether the request should be considered successful or not in performance traces. Maybe there should be a new partial success/failure state?

[marandaneto]

Btw I cannot reproduce the case that you can have multiple queries and just a subset fail, I always get the errors field only when one of them fails, can you reproduce that, or was it just an assumption? I tried using the GH explorer as well.

[ueman]

That's actually what I meant. As soon as one query fails, it includes errors. The other query in the same request might still be successful though, as there can be a result in data even when there's something in errors.

[marandaneto]

@ueman I got that but I could not reproduce this problem, I never got the errors and data together, and I explicitly made a mistake in one of the queries to test it out, so maybe this is actually not possible per spec.

[dapalex]

Hi,

I am not sure if it matches completely with this topic but I spent quite some time developing this library which is a python-GraphQL mapper for GraphQL clients.
Mainly the idea is to interact with a GraphQL API without creating all those hardcoded strings.
Here is the source code I just published on PyPI.

https://github.com/dapalex/py-graphql-mapper

It works pretty well, I have created an extensive suite of tests to make sure it is stable enough with Github GraphQL API, RapidAPI GraphQL and GeoDBCities API: I have been able to create quite complex queries and mutations.

Let me know if it something that can be of interest

[smeubank]

hi @dapalex

thanks for writing in!

is the idea that we could leverage this in a integration? Or that more developers could use this when seting up their own GraphQL API in python?

If I understand correctly we are ultimately relying on having a pretty high adoption of particular libraries for us to be able to plugin and provide enough value when creating standards events for span data etc

[wesbillman]

Another Flutter user here 👋 . I'm currently using the excellent work from @ueman and hoping to contribute as well. But it would be fantastic to have this be part of the built-in sentry package(s)

[zoesyc]

Hey @wesbillman - thanks for your feedback! We have plans work on GraphQL integration for Flutter this quarter (inclusive of @ueman's excellent work) and we'd love to hear more about what you'd like to see 😄

We are starting with spans and breadcrumbs with a goal of expanding into GraphQL client errors in the future. Any thoughts here?

[smeubank]

There is already some support in Node for Apollo and GraphQL, but we would still be happy to get more feedback on the extent of the support and for other platforms where there is interest.

https://docs.sentry.io/platforms/node/performance/database/opt-in/

[ueman]

There is certainly interest in the client and server side of GraphQL.

On the server side you want to detect for example N+1 queries.

On the client side you want to detect whether your queries are correct for example.

[mjq-sentry]

I've previously instrumented a pretty big GraphQL API with OpenTelemetry to try to understand/track its performance. Some thoughts:

Transactions

Through typical instrumentation, all your GraphQL traffic ends up in a single transaction - a single URL hosts every query and mutation permutation offered by your GraphQL API. Individual requests have very different performance characteristics since queries are arbitrarily constructed.

Even though that one transaction ends up being a big bucket of disparate requests, it's still useful to be able to see and monitor the aggregate performance of the entire API when thinking about things like scale (e.g. how many web servers are serving your API).

Alternatives to URL for transaction naming

If transactions could be named something other than "URL path" they might not all be grouped into a single transaction, but I wasn't able to find an alternative split that made sense for something like our transaction table.

• Queries can be named, but these are optional and arbitrary. If you allow third-party clients these are definitely unreliable.
• You can group by something like a hash of the query, but that doesn't help humans distinguish between rows. Further, small differences in queries can lead to either no change in performance or a large change in performance, and it isn't obvious just looking at the query which is which.

FWIW I think that collecting metrics by query hash or similar is still really useful (see workflows below), just maybe not as a way to label rows in a transactions table.

The span tree

The main thing I cared about seeing in the tree was the resolvers, since that's where the vast majority of the execution time comes from. Most slow resolvers are slow because they're doing database queries or HTTP calls, so having the spans we we typically auto-instrument as children of the resolver spans is of course useful too.

Closely tied to resolvers, and also important to see in the tree, are dataloaders. Usually you end up with many resolver spans that are all dependent on a single dataloader span finishing. This is hard to represent in the tree when spans only have a single parent - what's the parent of a dataloader span? Ideally it's all the resolvers that fed into it. (Note: see span links in OpenTelemetry for potential data model). Being able to show that in the tree somehow would be very useful. Further, resolver spans waiting on a dataloader can look like they're long operations, but really they're doing nothing waiting for the dataloader to finish. Being able to distinguish between when a resolver is working and when it is waiting would also go a long way to understanding a GraphQL query's span tree.

Ideal Workflows

Resolvers

Resolvers are the most consistent unit for understanding GraphQL API performance. I want to monitor them directly - how often are they called? What are their performance characteristics? This is analogous to how you'd monitor API endpoints in a REST API in my opinion. GraphQL doesn't return results until all resolvers have finished - so your slowest resolver also serves as the lower bound on how quickly a query involving that resolver can return. (Note: this is a pretty clear span indexing use case).

Being able to show representative queries/transactions that use a given resolver would also be useful for context.

Dataloaders

Similar to resolvers above. Slow dataloaders slow down any resolvers that use them; understanding and monitoring their performance directly can make sense.

Aggregate performance of subsets of transactions

In addition to the aggregate performance of the GraphQL endpoint as a whole, it's nice to be able to see the aggregate performance of some subset of your queries. Examples:

• Queries vs Mutations
• internal/first-party vs external/third-party (so you can compare queries you control vs ones you don't)
• By tenant (at my last job the reason we used GraphQL is we had a multi-tenanted system where, through configuration, each tenant would have its own query patterns.)
• by query complexity, for APIs implementing that

Slowest queries

It's nice to know flat out what is the worst stuff people are sending us. (If I clicked into a slow query, it would also be nice if we pulled the performance characteristics of that query in general for comparison - did I find an outlier or is this always slow? Is this the only time anyone has made this query, or is it common?)

Frequently slow queries

Similar to slowest queries, if I could get prompted with "here is stuff that's frequently called and also slow", those are usually higher value things to fix.

Query complexity tuning

Some GraphQL APIs use query complexity as a means to rate limit or prevent excessively large queries. Being able to confirm that the complexity scores of queries actually roughly correspond with their runtime or resource use would be amazing.

Other stuff

I haven't used Subscriptions much, but helping users understanding their performance would be interesting too.

[marandaneto]

#33723 is closed for GraphQL Client errors, next step is for Transactions/Spans.