My take on combining SvelteKit static build with a separate API backend

Backend
1

I’ve been thinking about different ways to set up web apps lately. There’s always talk about finding the right combo of frontend and backend tech. I think I stumbled onto something pretty good.

What I’m doing is using SvelteKit with the static adapter plus whatever backend I want (like Go or Rust).

Why this works well for me:

  • I still get all the nice SvelteKit features during development. File routing, load functions, good dev tools, and other cool stuff they keep adding. But I don’t need to worry about running Node servers in production.
  • When I build everything, it just becomes a regular SPA with basic HTML, CSS and JavaScript files.
  • My backend only needs to handle API calls and serve static files. I can even pack the whole frontend into one Go executable which makes deployment super easy.

It seems like I get the good parts of modern frontend development but keep things simple when it’s time to deploy. The frontend and backend stay separate which I really like.

Anyone else tried something similar? Curious what others think about this approach.

2

I’ve been running this exact setup for two years - SvelteKit static builds + Python FastAPI backend. The deployment simplicity blows full-stack frameworks out of the water. What’s great is how it scales: static assets go on a CDN, API runs separately, and performance is excellent. You can also version your API independently from frontend releases. The main downside? You lose SvelteKit’s server-side stuff like form actions and SSR. But for most apps, the deployment benefits are totally worth it.

3

Nice approach! I’m doing something similar with SvelteKit static + Node Express API. CORS caught me off guard when the frontend and backend were on different domains. I miss SvelteKit’s built-in form validation, but the deployment simplicity makes up for it.

4

that’s interesting! any issues with spa routing when serving from your go backend? like if users refresh on a nested route - does go handle it gracefully or did you need special routing logic?