SvelteKit Full-Stack Development

Overview

SvelteKit is the official full-stack framework built on top of Svelte. It provides file-based routing, server-side rendering (SSR), static site generation (SSG), API routes, and progressive form actions — all with Svelte's compile-time reactivity model that ships zero runtime overhead to the browser. Use this skill when building fast, modern web apps where both DX and performance matter.

When to Use This Skill

• Use when building a new full-stack web application with Svelte
• Use when you need SSR or SSG with fine-grained control per route
• Use when migrating a SPA to a framework with server capabilities
• Use when working on a project that needs file-based routing and collocated API endpoints
• Use when the user asks about +page.svelte, +layout.svelte, load functions, or form actions

How It Works

Step 1: Project Setup

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

Choose Skeleton project + TypeScript + ESLint/Prettier when prompted.

Directory structure after scaffolding:

src/
  routes/
    +page.svelte        ← Root page component
    +layout.svelte      ← Root layout (wraps all pages)
    +error.svelte       ← Error boundary
  lib/
    server/             ← Server-only code (never bundled to client)
    components/         ← Shared components
  app.html              ← HTML shell
static/                 ← Static assets

Step 2: File-Based Routing

Every +page.svelte file in src/routes/ maps directly to a URL:

src/routes/+page.svelte          → /
src/routes/about/+page.svelte    → /about
src/routes/blog/[slug]/+page.svelte  → /blog/:slug
src/routes/shop/[...path]/+page.svelte → /shop/* (catch-all)

Route groups (no URL segment): wrap in (group)/ folder. Private routes (not accessible as URLs): prefix with _ or (group).

Step 3: Loading Data with load Functions

Use a +page.ts (universal) or +page.server.ts (server-only) file alongside the page:

// src/routes/blog/[slug]/+page.server.ts
import { error } from '@sveltejs/kit';
import type { PageServerLoad } from './$types';

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 };
};

<!-- src/routes/blog/[slug]/+page.svelte -->
<script lang="ts">
  import type { PageData } from './$types';
  export let data: PageData;
</script>

<h1>{data.post.title}</h1>
<article>{@html data.post.content}</article>

Step 4: API Routes (Server Endpoints)

Create +server.ts files for REST-style endpoints:

// src/routes/api/posts/+server.ts
import { json } from '@sveltejs/kit';
import type { RequestHandler } from './$types';

export const GET: RequestHandler = async ({ url }) => {
  const limit = Number(url.searchParams.get('limit') ?? 10);
  const posts = await db.post.findMany({ take: limit });
  return json(posts);
};

export const POST: RequestHandler = async ({ request }) => {
  const body = await request.json();
  const post = await db.post.create({ data: body });
  return json(post, { status: 201 });
};

Step 5: Form Actions

Form actions are the SvelteKit-native way to handle mutations — no client-side fetch required:

// src/routes/contact/+page.server.ts
import { fail, redirect } from '@sveltejs/kit';
import type { Actions } from './$types';

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');
  }
};

<!-- src/routes/contact/+page.svelte -->
<script lang="ts">
  import { enhance } from '$app/forms';
  import type { ActionData } from './$types';
  export let form: ActionData;
</script>

<form method="POST" use:enhance>
  <input name="email" type="email" />
  {#if form?.missing}<p class="error">Email is required</p>{/if}
  <button type="submit">Subscribe</button>
</form>

Step 6: Layouts and Nested Routes

<!-- src/routes/+layout.svelte -->
<script lang="ts">
  import type { LayoutData } from './$types';
  export let data: LayoutData;
</script>

<nav>
  <a href="/">Home</a>
  <a href="/blog">Blog</a>
  {#if data.user}
    <a href="/dashboard">Dashboard</a>
  {/if}
</nav>

<slot />  <!-- child page renders here -->

// src/routes/+layout.server.ts
import type { LayoutServerLoad } from './$types';

export const load: LayoutServerLoad = async ({ locals }) => {
  return { user: locals.user ?? null };
};

Step 7: Rendering Modes

Control per-route rendering with page options:

// src/routes/docs/+page.ts
export const prerender = true;   // Static — generated at build time
export const ssr = true;         // Default — rendered on server per request
export const csr = false;        // Disable client-side hydration entirely

Examples

Example 1: Protected Dashboard Route

// src/routes/dashboard/+layout.server.ts
import { redirect } from '@sveltejs/kit';
import type { LayoutServerLoad } from './$types';

export const load: LayoutServerLoad = async ({ locals }) => {
  if (!locals.user) {
    redirect(303, '/login');
  }
  return { user: locals.user };
};

Example 2: Hooks — Session Middleware

// src/hooks.server.ts
import type { Handle } from '@sveltejs/kit';
import { verifyToken } from '$lib/server/auth';

export const handle: Handle = async ({ event, resolve }) => {
  const token = event.cookies.get('session');
  if (token) {
    event.locals.user = await verifyToken(token);
  }
  return resolve(event);
};

Example 3: Preloading and Invalidation

<script lang="ts">
  import { invalidateAll } from '$app/navigation';

  async function refresh() {
    await invalidateAll(); // re-runs all load functions on the page
  }
</script>

<button on:click={refresh}>Refresh</button>

Best Practices

• ✅ Use +page.server.ts for database/auth logic — it never ships to the client
• ✅ Use $lib/server/ for shared server-only modules (DB client, auth helpers)
• ✅ Use form actions for mutations instead of client-side fetch — works without JS
• ✅ Type all load return values with generated $types (PageData, LayoutData)
• ✅ Use event.locals in hooks to pass server-side context to load functions
• ❌ Don't import server-only code in +page.svelte or +layout.svelte directly
• ❌ Don't store sensitive state in stores — use locals on the server
• ❌ Don't skip use:enhance on forms — without it, forms lose progressive enhancement

Security & Safety Notes

• All code in +page.server.ts, +server.ts, and $lib/server/ runs exclusively on the server — safe for DB queries, secrets, and session validation.
• Always validate and sanitize form data before database writes.
• Use error(403) or redirect(303) from @sveltejs/kit rather than returning raw error objects.
• Set httpOnly: true and secure: true on all auth cookies.
• CSRF protection is built-in for form actions — do not disable checkOrigin in production.

Common Pitfalls

• Problem: Cannot use import statement in a module in +page.server.ts Solution: The file must be .ts or .js, not .svelte. Server files and Svelte components are separate.
• Problem: Store value is undefined on first SSR render Solution: Populate the store from the load function return value (data prop), not from client-side onMount.
• Problem: Form action does not redirect after submit Solution: Use redirect(303, '/path') from @sveltejs/kit, not a plain return. 303 is required for POST redirects.
• Problem: locals.user is undefined inside a +page.server.ts load function Solution: Set event.locals.user in src/hooks.server.ts before the resolve() call.

Related Skills

• @nextjs-app-router-patterns — When you prefer React over Svelte for SSR/SSG
• @trpc-fullstack — Add end-to-end type safety to SvelteKit API routes
• @auth-implementation-patterns — Authentication patterns usable with SvelteKit hooks
• @tailwind-patterns — Styling SvelteKit apps with Tailwind CSS

Limitations

• Use this skill only when the task clearly matches the scope described above.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.