──────────────────────────────────────────────────────────────────────
Go Microservices: A Frontend Engineer's Perspective
After years of Node.js, switching to Go changed how I think about performance, concurrency, and the invisible wall between frontend and backend.
I spent five years building Node.js backends. When I picked up Go for a microservices project, I expected a stricter, faster Node. It felt like a different way of thinking about programs.
Concurrency vs. Async
Node's model is single-threaded concurrency through an event loop. Go's is actual parallelism through goroutines and channels — cheap (4KB stack vs. 1MB OS thread) but real. The Go model is harder to learn but produces code that's easier to reason about under load.
The Performance Gap Is Real
I rewrote a document processing service from Node to Go. Node: ~800 docs/sec with GC pauses. Go: ~4,200 docs/sec, no observable pauses. Typical, not exceptional.
What It Changed
Writing Go made me more aggressive about performance budgets on the frontend. The invisible wall between frontend and backend is largely a tooling artifact. Understanding both sides makes you a better engineer at either one.