Build full-stack web apps with SvelteKit SSR and routing

Covers building a full-stack SvelteKit app: file-based routing where every +page.svelte under src/routes/ maps directly to a URL (src/routes/about/+page.svelte becomes /about, [slug] for dynamic segments, [...path] for a catch-all), route groups in (group)/ folders that don't add a URL segment, and private routes prefixed with _; loading data via a +page.ts (universal) or +page.server.ts (server-only) load function whose return value is typed with generated $types; REST-style API endpoints defined in +server.ts files exporting GET/POST/etc handlers; form actions defined in +page.server.ts's actions export as the SvelteKit-native way to handle mutations without a client-side fetch, paired with the use:enhance action on the <form> for progressive enhancement; nested layouts via +layout.svelte (with a <slot /> for the child page) and +layout.server.ts for layout-level data such as the current user; and per-route rendering control through page-level exports (prerender, ssr, csr).

Use it when building a new full-stack Svelte web app, needing SSR or SSG with fine-grained per-route control, migrating a SPA to a framework with server capabilities, working on a project that needs file-based routing with collocated API endpoints, or when the user asks about +page.svelte, +layout.svelte, load functions, or form actions. Rules to follow: put database and auth logic only in +page.server.ts or $lib/server/ (which never ships to the client) - never import server-only code directly into +page.svelte or +layout.svelte; use form actions for mutations instead of client-side fetch, since actions work without JavaScript; never skip use:enhance on forms, since without it they lose progressive enhancement; and never store sensitive state in a client-visible store - use locals on the server instead. Security notes: validate and sanitize all form data before writing to a database, raise errors with error()/redirect() from @sveltejs/kit rather than returning raw error objects, set httpOnly: true and secure: true on auth cookies, and never disable checkOrigin in production since form actions have built-in CSRF protection.

Project setup:

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

A load function returning server-fetched data:

export const load: PageServerLoad = async ({ params, fetch }) => {
  const post = await fetch(`/api/posts/${params.slug}`).then(r => r.json());

  if (!post) {
    error(404, 'Post not found');
  }

  return { post };
};

A form action for mutations:

export const actions: Actions = {
  default: async ({ request }) => {
    const data = await request.formData();
    const email = data.get('email');

    if (!email) {
      return fail(400, { email, missing: true });
    }

    await sendEmail(String(email));
    redirect(303, '/thank-you');
  }
};

Session context is set once in src/hooks.server.ts's handle function (reading a cookie, verifying it, and assigning event.locals.user), then read from locals in any load function or +server.ts handler.

Built on @sveltejs/kit primitives (error, redirect, fail, json, RequestHandler, Handle) and Svelte's own $app/forms (enhance) and $app/navigation (invalidateAll) modules; pairs with related skills for tRPC end-to-end type safety on API routes, authentication patterns usable through SvelteKit hooks, and Tailwind CSS styling.

Developers building a SvelteKit app who need the file-based routing, server-only data loading, API route, and form-action conventions applied correctly - keeping server logic off the client and mutations working without hand-rolled fetch calls.