-
Notifications
You must be signed in to change notification settings - Fork 170
Add engineering blog posts on React architecture and performance #2414
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Add 5 new engineering blog posts: - Rendering large JSON payloads with sub-10ms interactions - Handling 200K observations without stack overflow - React architecture part 1: Layer separation - React architecture part 2: Co-location and pure functions - React architecture part 3: Adaptive optimization These posts form a cohesive series about building production-grade React components and performance optimization at Langfuse. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📦 Next.js Bundle Analysis for langfuse-docsThis analysis was generated by the Next.js Bundle Analysis action. 🤖 New Pages AddedThe following pages were added to the bundle from the code in this PR:
Seven Hundred Fifty-six Pages Changed SizeThe following pages changed size from the code in this PR compared to its base branch:
DetailsOnly the gzipped size is provided here based on an expert tip. First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If Any third party scripts you have added directly to your app using the The "Budget %" column shows what percentage of your performance budget the First Load total takes up. For example, if your budget was 100kb, and a given page's first load size was 10kb, it would be 10% of your budget. You can also see how much this has increased or decreased compared to the base branch of your PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this. If you see "+/- <0.01%" it means that there was a change in bundle size, but it is a trivial enough amount that it can be ignored. |
| author: Michael | ||
| --- | ||
|
|
||
| At Langfuse we have a culture governed by [high ownership and proactive engineering](https://langfuse.com/handbook/how-we-work/principles). Engineers work directly with users, plan features across the full stack, and independently ship features and improvements without the need for complicated approval processes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need a headlines across the blog posts.
| ## The Technical Challenge | ||
|
|
||
| The trace view is one of the most-used components in Langfuse. Users see it every time the open a trace. It combines multiple concerns: progressive data fetching from several endpoints, transforming it into hierarchical structures, managing user interactions, handling responsive layouts, and adapting to different display modes. | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"The trace view"...
Users do not know what the trace view is. Maybe adding a picture would be great.
|
|
||
| The challenge is knowing how close is too close. Move things too far apart and you create friction. Move them too close and you lose clarity. Finding the right distance for each situation is key. | ||
|
|
||
| ### Feature-Level Organization |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One reaseon here is also licensing. We may want to have certain features on a specific license. Hence, we should colocate to have one directory on a different license than the ret of the system.
|
|
||
| For small traces (under 350 observations), download fetches all data before exporting. Users get complete trace exports with all input/output payloads included. | ||
|
|
||
| For large traces (over 350 observations), download uses cache-only mode. The export includes full data for expanded observations and metadata-only for unexpanded ones. Users see a clear indicator: "Downloaded trace data (cache only)". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why did we do this? We could also use the export infra to send users an export for a given trace id via email
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was a feature available prior to making any changes. Allowing to download under the threshold is equivalent to what worked before (except now the UI would not block).
For traces > threshold this can be solved in different ways. Batch export could be one
| authors={["Michael"]} | ||
| /> | ||
|
|
||
| Langfuse is agnostic to what users trace. We don't impose structure or limits on how teams instrument their LLM applications. This flexibility is powerful, but it means we need to handle everything from simple chatbot calls to complex autonomous agents. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
first sentence does not make sense
| ## Trade-offs | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can remove this section
|
|
||
| Our first virtualized implementation followed a straightforward pipeline: | ||
|
|
||
| **Step 1: Deep Parse JSON** - Convert JSON string into JavaScript objects |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
formatting is broken
|
|
||
| Deep parsing and tree building for 100K+ nodes took 500ms+ on the main thread, freezing the browser. Solution: conditionally offload to Web Workers for datasets over 10,000 nodes. | ||
|
|
||
| **Problem 2: Expand/Collapse Still Sluggish** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reader has no idea what this is. Can you add a gif / image here?
|
|
||
| With agentic workflows, we see a small but increasing number of traces with significantly larger payloads. Long-running agent loops accumulate tens of thousands of lines of JSON. Tool calls sometimes return entire database query results. Some responses contain 100,000+ lines of structured data. Our initial JSON viewer rendered all nodes to the DOM, which caused browser lags or even crashes on these large payloads. | ||
|
|
||
| ## Initial Approach: Virtualization with Eager Flattening |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the other articles are way more clearer to the user. I am wondering a bit:
What are the flat rows? Why do we need this to visualise? Why not json parse?
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
Summary
Add 5 new engineering blog posts to the Langfuse documentation:
These posts form a cohesive series about building production-grade React components and performance optimization at Langfuse.
Test plan
🤖 Generated with Claude Code
Important
Adds 5 new blog posts to Langfuse documentation on React architecture and performance, covering topics like handling large JSON payloads and structuring React components.
This description was created by
for 84518c3. You can customize this summary. It will automatically update as commits are pushed.