We reduced the query to a summary query that ignored leaves in the query, and rounded the counts (e.g., first: 7941) to the closest power of 10. E.g., { budgetDetails (# <= 10) } , { accountBalances (# <= 100) { account period } }, etc. Then logged that, with the timing, etc.
Our challenge was always that you wouldn't want to log the full query in each request, since it can be monstrously large. Our pragamatic approach was, as I said, create a hash/fingerprint of the query (stripping out variables and such) and every N thousand requests, log the full query with the fingerprint (so that we could dig the actual query out of Splunk if necessary).
Right, but those aren't the full queries, just the 'branches'. The full queries might be thousands of characters.
How do you monitor GraphQL(Lacinia) server? I'm using datadog's statds to aggregate custom metrics, but I often feel the need for better APM that works for GraphQL. Maybe some alternatives are ApolloStudo, Stellate, and moesif? Or I'd be better off with DataDog?
The challenge for metrics is that if you do it as an endpoint, every requests large or small looks the same. We worked on several different monitoring approaches while I was at Walmart, essentially, reducing the query to a hash code, and occasionally logging the query matching the hash code. This kind of thing works better if you restrict to pre-defined, server-side queries.
Sounds like https://relay.dev/docs/guides/persisted-queries/ in Relay. In our case, we don't supply public access so maybe we can use operationName as an identifier, rather than custom hash.