Build full-stack web apps with SvelteKit SSR and routing

SvelteKit Full-Stack Development covers building a complete web app with SvelteKit: file-based routing, server-side rendering, static site generation, API routes, and progressive form actions on top of Svelte's compile-time reactivity, which ships zero runtime overhead to the browser. It scaffolds a project:

npm create svelte@latest my-app
cd my-app
npm install
npm run dev

then covers file-based routing (src/routes/blog/[slug]/+page.svelte maps to /blog/:slug, [...path] is a catch-all, a (group) folder groups routes without adding a URL segment), data loading via +page.ts (universal) or +page.server.ts (server-only) load functions typed with generated $types, REST-style +server.ts API endpoints exporting GET/POST handlers, form actions for mutations bound with use:enhance so they keep working without client-side JavaScript and gain progressive enhancement when it is present, nested layouts, and per-route rendering control (prerender, ssr, csr booleans in a +page.ts).

Use it when building a new full-stack Svelte app, when a route needs fine-grained SSR or SSG control, when migrating a SPA to a framework with server capabilities, or whenever the task touches +page.svelte, +layout.svelte, load functions, or form actions. Server-only code in +page.server.ts, +server.ts, or $lib/server/ must never be imported directly into a +page.svelte or +layout.svelte component - that code is meant to run exclusively on the server, and sensitive state belongs in locals on the server rather than in a client-visible store.

Input is the app's route tree and data requirements. Output is a working SvelteKit app where load functions return typed data to pages and layouts, +server.ts files expose JSON endpoints, and form actions handle mutations via fail(400, ...) or redirect(303, ...) rather than a plain return - 303 is required for POST redirects, and a plain return after a form action will not redirect at all. Hooks in src/hooks.server.ts populate event.locals (for example a verified session user, read from a cookie) so that data is available in every subsequent load function without re-fetching it; if locals.user still reads undefined inside a +page.server.ts load function, the fix is setting event.locals.user in hooks.server.ts before resolve() runs. Two other recurring failures: a +page.server.ts file must stay .ts/.js, not .svelte, or the bundler throws an import-statement error; and a store that reads undefined on first SSR render needs to be populated from the load function's returned data prop, not from a client-only onMount. Form data should always be validated and sanitized before a database write, and errors/redirects should go through error()/redirect() from @sveltejs/kit rather than being returned as raw error objects.

@sveltejs/kit primitives (error, json, fail, redirect), $app/navigation's invalidateAll for re-running load functions on demand, and generated $types (PageData, LayoutData, PageServerLoad, RequestHandler, Handle) for end-to-end typing. Auth cookies should be set httpOnly: true and secure: true, and the framework's built-in CSRF checkOrigin protection for form actions should not be disabled in production. It complements @trpc-fullstack for added API type safety, @auth-implementation-patterns for authentication, and @tailwind-patterns for styling.

Frontend and full-stack developers building a new SvelteKit app, or migrating an existing single-page Svelte app to one, who need SSR, SSG, API routes, and progressively-enhanced form handling in a single cohesive framework rather than gluing a separate backend service onto a Svelte frontend.