Closed yurishkuro closed 9 months ago
Hey @yurishkuro I want to work on this for the upcoming LFX mentorship . Will go through good first Issues and suggest improvements if needed
Hi @yurishkuro, I am very interested and definitely apply for this project in the upcoming LFX mentorship!!
Hey @yurishkuro , would love to contribute to this project under the LFX mentorship . Also going through the first good issues and will work upon them .
@shashwatm1111 welcome
Hello @yurishkuro, I would love to get involved with this project. I am currently getting familiar with Jaeger and Plexus. Looking forward to making an amazing contribution!
Hello @yurishkuro, I would love to contribute to this project under the LFX mentorship.
Hello @yurishkuro👋
I'm Pranit Patil, a student pursuing a Bachelor's degree in Computer Science at Mumbai University. Recently, I completed my internship at hubx.ai, where I worked as a full-stack developer intern. Prior to that, I gained experience as a front-end developer intern at Tech Cryptors.
My skills include JavaScript, ReactJS, Node, Express, MongoDB, and CSS libraries, such as Bootstrap. Through various projects, including full-stack ones, I have honed my expertise in full-stack development
I'm keen on participating in the LFX mentorship program and becoming an active community member. I kindly request your assistance in guiding me through project discussions.
Thank you.
@prathamesh-mutkure's application was selected for this project. Congratulations!
congrats @prathamesh-mutkure
Plexus is the likely choice, but it needs to be benchmarked on large graphs (the System view can handle several thousand nodes). We can also consider server-side filtering (proposed in https://github.com/jaegertracing/jaeger-ui/issues/784).
Do we have any sample(s) of data, which we can use to run the benchmarks against?
not to my knowledge. We have a storage integration test that saves a trace with 10k spans, but it just generates that on the fly. I would do the same here - a fake trace is not difficult to generate. It's a bit tricky to decide on the good way to connect different nodes so that we don't test on a contrived cases like a graph which is a single very long branch.
Another interesting lib I just stumbled upon in some internal tool: https://reactflow.dev/
Another alternative: SigmaJS with Graphology
For the application process please refer to this issue.
Requirement
As a user of Jaeger UI I want to have a consistent experience with service graph views.
Problem
Jaeger currently uses three distinct renderings for service graphs
Proposal
To reduce the different code paths and provide a consistent user experience we should converge on a single graph visualization.
Plexus is the likely choice, but it needs to be benchmarked on large graphs (the System view can handle several thousand nodes). We can also consider server-side filtering (proposed in #784).
We may also have to address #1081 (deprecated graphing libs)
Some Evaluation Criteria