Closed JVMartin closed 1 year ago
Actually, this is only the case on GraphQL implementations, since in GraphQL many resolvers are in the same request/response express lifecycle. I think for just HTTP / REST your implementation doesn't jumble spans.
Hi @JVMartin ,
Thanks for the feedback and information. I don't have experience with GraphQL but you might want to keep all your resolvers in the same initial HTTP request and then have a different Sentry project for each micro-service that you are calling with each of your resolvers. I think that way you will be able to segregate the traces and performance monitoring for each of your micro-service.
Though again I don't have much experience with that kind of setup.
Thanks for taking the time anyway @ericjeker, we're using your code on our REST APIs, still looking for a solution for our GraphQL APIs.
btw there are no microservices needed, GraphQL replaces REST, even if it's just 1 webserver. Nobody uses REST anymore if they know GraphQL, it's a protocol on top of http that is a HUGE improvement.
You can make hundreds of GraphQL queries with 1 http request. You should check it out, it's amazing.
Hello there. Thank you for this project, it was a great jumping off point to implement Sentry in NestJS for us.
There is a major issue with your implementation, however. Express can handle many request/responses at one time, when each request handler also makes async calls, so you cannot be using the same global hub since that will cause a huge jumbled mess.
If your app happens to never process multiple requests in parallel because you never hit it with multiple simultaneous requests, you've probably never noticed this.
But on apps receiving thousands of requests per minute, it becomes quite the huge mess.
You must use AsyncLocalStorage so that each request/response gets its own unique hub. See example here:
https://gist.github.com/jasonk/a06153476ae7fad41c527e321e318088