Building Loom (Part 3): Real-Time Browser UI with SSE, Goroutines, and Channels

This is Part 3 of my series building Loom. 👉 Missed Part 2? Read it here Today: Building the real-time browser UI with SSE, goroutines, and channels. One request → three outputs simultaneously. joshuabvarghese / Loom gRPC L7 Debugging Proxy Loom A gRPC debugging proxy. Point it at your backend, point your client at Loom, and watch every call decoded in a browser tab. Your gRPC Client → Loom (:9999) → Your Backend (:50051) ↓ Web Inspector http://localhost:9998 Why gRPC traffic is binary. Wireshark can't read it. grpcurl is great for one-off calls but you can't watch a flow. I kept running it over and over trying to understand what was happening between services. Loom sits transparently between your client and backend. It uses Server Reflection to decode every frame on the fly — no .proto files required — and streams the results into a browser UI. You see the JSON payloads, the status codes, how long each call took, and a ready-to-copy grpcurl command to replay any of them. What it does Intercepts all four gRPC stream types — unary, server-streaming, client-streaming, bidi Auto-decodes using Server Reflection (no proto… View on GitHub The requirement I wanted a browser UI that shows every gRPC call in real time. No page refresh. No polling. Just instant updates. The challenge: One incoming gRPC request needs to go to three places at once: Browser UI (SSE stream) Console logs Recorder for replay Why SSE over WebSockets? WebSockets are great for two-way communication. But I just needed server → browser. SSE advantages: Simpler protocol (just HTTP) Auto-reconnection built in Native EventSource API in browsers Perfect for "fire and forget" updates The hub pattern The core insight: one goroutine that owns all client connections and broadcasts to them. type Hub struct { clients map [ chan ] bool // Active connections broadcast chan [] byte // Incoming messages register chan chan // New clients unregister chan chan // Leaving clients } func ( h * Hub ) Run () { for { select { case ch := <- h . register : h . clients [ ch ] = true case ch := <- h . unregister : delete ( h . clients , ch ) close ( ch ) case msg := <- h . broadcast : for ch := range h . clients { ch <- msg // Send to every client } } } } How it works: Any goroutine can push to broadcast. The hub sends it to ALL connected clients. No locks. No race conditions. Fanning out to multiple sinks When a gRPC request comes in, I fan it out: func ( p * Proxy ) handleRequest ( req * Request ) { // Same data to three places go p . sseHub . Broadcast ( req ) // Browser UI go p . logger . Log ( req ) // Console go p . recorder . Record ( req ) // For replay // Forward to backend p . backend . Call ( req ) } Each sink runs in its own goroutine. If one blocks, the others keep going. The 40KB UI file The frontend is a single HTML file (40KB) that: Opens an EventSource connection to /events Listens for new gRPC calls Renders them as cards in real time const source = new EventSource ( ' /events ' ); source . onmessage = ( event ) => { const call = JSON . parse ( event . data ); addCallCard ( call ); // Render to page }; No React. No build step. Just vanilla JS that works. What I learned Channels as connection managers — The hub pattern feels unnatural at first, then becomes obvious Fan-out is trivial in Go — go func() for each sink, done SSE is underrated — For logs, metrics, UIs, it's perfect One file is fine — My 40KB UI never needed splitting Performance With 100 concurrent gRPC requests: Component Latency added SSE broadcast ~2ms Logger ~1ms Recorder ~3ms Total overhead ~6ms All three run in parallel thanks to goroutines. The aha! moment Coming from Node.js, I would've used callbacks or promises. In Go, I just wrote: go doSomething () go doSomethingElse () go doAnotherThing () And it worked. No thinking about event loops. Just concurrency. Key takeaways SSE > WebSockets for one-way real-time updates The hub pattern is Go's answer to connection management Fan-out with