This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-20
Channels
- # announcements (1)
- # babashka (4)
- # beginners (8)
- # cider (4)
- # clj-kondo (10)
- # cljdoc (1)
- # cljsrn (7)
- # clojure (3)
- # clojure-europe (20)
- # clojure-france (3)
- # clojure-sg (2)
- # clojurescript (16)
- # clojureverse-ops (3)
- # community-development (5)
- # core-async (35)
- # cursive (1)
- # datahike (14)
- # datomic (7)
- # events (5)
- # fulcro (59)
- # graphql (11)
- # lsp (33)
- # meander (1)
- # off-topic (33)
- # polylith (23)
- # portal (33)
- # re-frame (1)
- # reagent (10)
- # reclojure (7)
- # reveal (14)
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
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.
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)