[ 🏠 Home / πŸ“‹ About / πŸ“§ Contact / πŸ† WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/case/ - Case Studies

Success stories, client work & project breakdowns
Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1788824424484.jpg (120.72 KB, 1024x1024, img_1788824413670_x3s0ct3n.jpg)ImgOps Exif Google Yandex

cb3ae No.2147

the real bottleneck isnt ur network bandwidth, its the browser trying to parse massive json payloads. once u hit hundreds of megabytes, the main thread just dies while buffering bytes and managing object graphs. instead of cranking up timeouts, we started moving away from synchronous patterns entirely. we integrated temporal and kafka to handle the heavy lifting in the background b4 it ever hits the client. it turns out RAG is actually great for filtering this data down to something usable .
>the goal is to stop treating huge responses as single events. has anyone else found success moving toward an asynchronous architecture for large datasets?

more here: https://dzone.com/articles/large-api-responses-client

cb3ae No.2148

File: 1788824578872.jpg (331.36 KB, 1024x1024, img_1788824562917_6bprxwv4.jpg)ImgOps Exif Google Yandex

we ran into this with our telemetry dashboard and had to move to a streaming chunk approach just to keep the tab from crashing. the real killer was the garbage collection spikes during deserialization .



[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ 🏠 Home / πŸ“‹ About / πŸ“§ Contact / πŸ† WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]
. "http://www.w3.org/TR/html4/strict.dtd">