· 1 min read
I Rewrote My SvelteKit Backend in Go, and I'd Do It Again
Why I moved from a serverless SvelteKit backend to a standalone Go service, and what I gained from the split.
By Tanner Goins
This started as a fully serverless backend to enable fast iteration.
That worked well initially, but as the system evolved, the limitations became more apparent:
- No persistent WebSocket connections
- Limited options for background jobs and queues
- Reliance on vendor-specific alternatives
- Less control over execution, memory, and long-running work
At that point, serverless stopped being an advantage and started being a constraint.
The Split
I split the app into:
- A fully static SvelteKit frontend
- A standalone Go backend built for concurrency and real-time communication
Why It Was Worth It
The result wasn’t about performance benchmarks or technology preferences. It was about removing friction and making the system easier to build upon as it grows. It’s a similar philosophy to what drove my Svelte 5 website rebuild: sometimes a clean split is faster than incremental migration.