Clojurians Log v2
graphql 2021-11-20
Does anyone have advice on how to integrate tracing (e.g. AWS X-Ray SDK for Java) with Lacinia? • I need to trace the resolvers as well as underlying DB queries • My code base is almost entirely async API I’ve give it a few shot, but AWS X-Ray SDK for Java use thread-local storage intensively which doesn’t work well with async calls on a thread-pool. I’d like to try the Resolver Tracing API provided by Lacinia, but it doesn’t seems to be able to provide a parent segment / child segment relation info. https://lacinia.readthedocs.io/en/latest/tracing.html
> AWS X-Ray SDK for Java use thread-local storage
what part of the api does? Maybe the default AWSXRayServletFilter does, but you could make your own mechanism that keeps a segment open for the whole interceptor chain
also worth considering if your api needs to be async/if its possible to undo that work for better tracing
> what part of the api does? Segment context need to be explicitly passed between threads, and now I have this extra complexity of manually sync 1) Lacinia context, 2) application context 3) X-Ray context 4) superlifter context. https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-java-multithreading.html > worth considering if your api needs to be async/if its possible to undo that work for better tracing Async API is needed because I’m building a GraphQL API and I use superlifter to reduce N+1 problem. I’ve started with a synchronous API, but the performance did not meet the release requirement. That’s when I’ve decided to add X-Ray SDK, and here we are.
can you give some more examples of usage? I’m a bit out of my depth here
and also maybe just…use the api directly
by which i mean require something like cognitect.aws.api that just exposes the api more or less raw
and build out whatever context-propagation mechanism makes sense (maybe dynamic vars?) without the baggage of the thread local stuff
(keys (aws/ops xray))
=>
(:GetTraceGraph
:CreateGroup
:ListTagsForResource
:TagResource
:GetServiceGraph
:GetInsightImpactGraph
:UntagResource
:GetInsightSummaries
:PutTraceSegments
:GetSamplingStatisticSummaries
:GetGroups
:GetSamplingRules
:GetGroup
:UpdateGroup
:GetTraceSummaries
:GetTimeSeriesServiceStatistics
:UpdateSamplingRule
:DeleteGroup
:GetInsight
:GetSamplingTargets
:GetInsightEvents
:PutTelemetryRecords
:BatchGetTraces
:DeleteSamplingRule
:GetEncryptionConfig
:PutEncryptionConfig
:CreateSamplingRule)
Feels like you could define a directive to identify which fields (top level operations or deeper in the tree) require tracing, then use :apply-field-directives option to decorate those resolve functions to interact with AWS apis.