This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-01-18
Channels
- # announcements (6)
- # aws (1)
- # babashka (47)
- # beginners (50)
- # calva (65)
- # cider (4)
- # clj-commons (17)
- # clj-kondo (44)
- # clojure (150)
- # clojure-europe (41)
- # clojure-nl (4)
- # clojure-spec (1)
- # clojure-sweden (4)
- # clojure-uk (6)
- # clojurescript (15)
- # clr (1)
- # conjure (1)
- # core-async (7)
- # cursive (5)
- # datomic (12)
- # events (2)
- # fulcro (17)
- # graphql (12)
- # introduce-yourself (1)
- # jackdaw (5)
- # jobs (2)
- # lsp (52)
- # malli (5)
- # meander (3)
- # minecraft (2)
- # missionary (2)
- # off-topic (10)
- # other-languages (9)
- # reitit (9)
- # remote-jobs (1)
- # ring (8)
- # rum (7)
- # shadow-cljs (9)
- # sql (2)
- # tools-deps (20)
- # xtdb (12)
Not strictly graphql related but possibly someone in this channel could give me some pointers. I'd like to troubleshoot some performance issues with some of our graphql endpoints. There's obviously the timing extension support right there in Lacinia for one-offs, but I would like to take this as an opportunity to add proper observability (e.g. AWS x-ray, Honeycomb etc). What I'm looking for is to collect various timing data about graphql queries: How long did the root resolver took, how long did the sql backend took for the root resolver, any other N+1 queries that we may be unwittingly firing etc etc.
I did exactly that with X-Ray. It helped us identified several N+1 problems. The Java SDK is quite painful to work with, so I ended up with wrapping it as a clojure library. https://github.com/hden/aws-xray-sdk-clj
Thanks! Did you end up instrumenting every resolver manually or is there some trick in Lacinia to wrap all resolvers?
Any guidance on how to map segments to graphql? I guess the top level query is the first segment and any child resolvers would be subsegments?
Yes. Depends on how you resolve your result, a context switch might be needed. https://lacinia.readthedocs.io/en/latest/resolve/context.html
You might need to pass the root segment to the field resolvers so that the field resolvers can attach subsegments to the root segment. There are several ways to do so, one is to pass the parent (e.g. root) segment as a part of the application context.
Right, I was hoping that Lacinia could allow me to do that globally. But I guess I could do that via a defresolver macro or similar.
We've been using pedestal.log tracing with datadog, opening traces in interceptors, and spans around resolvers using a wrapper so that we have the details. It was quite painful tbh because active-span can return a closed span and we ended up with mangled traces. In the end with quite some lifting on our end to completely rely on our own active spans it works ok