Claude Code & SvelteKit: Full-Stack-Apps mit Svelte entwickeln

SvelteKit hat sich in den letzten Jahren von einem Geheimtipp zu einem ernsthaften Full-Stack-Framework entwickelt. Wer damit gearbeitet hat, schätzt die schlanke Syntax, die echte Reaktivität ohne Virtual DOM und das durchdachte Routing-Konzept. Was vielen fehlt: ein sinnvoller Einstieg in die komplexeren Teile — Server-Side Rendering, API-Routes, Form Actions und Authentication.

Genau hier kommt Claude Code ins Spiel. Nicht als Dokumentations-Ersatz, sondern als Co-Pilot, der das gesamte Projekt im Blick hat: Routing-Konventionen, bestehende Stores, den Datenbankzugriff dahinter — und der auf Basis dieser Kenntnisse konsistenten Code schreibt, der zu deiner Architektur passt.

1. SvelteKit vs. Next.js: Wo liegt der Unterschied wirklich?

Die häufigste Frage beim Einstieg: Brauche ich SvelteKit, wenn ich Next.js kenne? Die Antwort hängt davon ab, was dir wichtig ist. Next.js ist mächtiger im Ökosystem — mehr Drittanbieter-Bibliotheken, mehr Stack-Overflow-Antworten, mehr Stellenanzeigen. SvelteKit ist schlanker in der Ausgabe — kein Virtual DOM, kleinere Bundle-Größen, eine Syntax, die sich nach weniger Boilerplate anfühlt.

Der wichtigste konzeptuelle Unterschied: In Next.js unterscheidest du zwischen Server Components und Client Components explizit per 'use client'-Direktive. In SvelteKit ist die Grenze durch die Dateistruktur definiert: +page.svelte ist die Ansicht, +page.server.ts ist der Server-Teil, +server.ts ist der reine API-Endpunkt. Die Trennung ist expliziter und — sobald man sie verinnerlicht hat — klarer.

• Next.js: React-basiert, riesiges Ökosystem, use client/use server-Direktiven, App Router vs. Pages Router
• SvelteKit: Svelte-basiert, kleinere Bundles, File-based Routing durch Namenskonventionen, klare Server/Client-Trennung
• Wann SvelteKit wählen: Performance-kritische Frontends, Teams die Boilerplate hassen, Projekte wo Bundle-Größe zählt

2. File-based Routing verstehen

Das Routing in SvelteKit ist vollständig dateibasiert — der Ordnerpfad unter src/routes/ definiert die URL. Keine manuelle Konfiguration, kein Router-Setup. Claude Code navigiert in diesem System äußerst effizient, weil es die Konventionen kennt und beim Anlegen neuer Routen automatisch die richtigen Dateien erstellt.

src/routes/
├── +page.svelte          # /
├── +layout.svelte        # Root-Layout (gilt für alle Seiten)
├── blog/
│   ├── +page.svelte      # /blog
│   └── [slug]/
│       └── +page.svelte  # /blog/:slug (dynamische Route)
├── api/
│   └── users/
│       └── +server.ts    # /api/users (REST-Endpunkt)
└── (auth)/               # Gruppe ohne URL-Einfluss
    ├── login/
    │   └── +page.svelte  # /login
    └── +layout.svelte    # Layout nur für Auth-Seiten

Das Klammern-Syntax (auth) ist besonders wertvoll: Routen-Gruppen lassen dich Layouts und Guards teilen, ohne sie in die URL zu schreiben. Claude Code erklärt dieses Muster auf Anfrage und setzt es direkt um — inklusive des passenden +layout.server.ts für den Session-Check.

3. Server-Side Rendering und Load-Funktionen

In SvelteKit lädt jede Seite ihre Daten über eine load-Funktion. Liegt sie in +page.server.ts, läuft sie ausschließlich auf dem Server — kein Datenbankzugriff gelangt jemals zum Client. Das ist ein entscheidender Unterschied zu vielen anderen Frameworks.

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

export const load: PageServerLoad = async ({ params }) => {
  const post = await db.post.findUnique({
    where: { slug: params.slug }
  });

  if (!post) {
    error(404, 'Artikel nicht gefunden');
  }

  return { post };
};

Claude Code schreibt diese Load-Funktionen konsistent und typsicher: Es importiert automatisch die generierten $types, behandelt Fehlerfälle mit dem SvelteKit-eigenen error()-Helper und gibt nur die Daten zurück, die die Seite tatsächlich braucht. Kein Overthinking, kein zu breites Interface.

4. API Routes mit +server.ts

Für REST-Endpunkte, Webhooks oder JSON-APIs jenseits der Seiten-Load-Funktionen gibt es in SvelteKit die +server.ts-Dateien. Sie exportieren benannte Handler für die HTTP-Methoden: GET, POST, PUT, DELETE.

// src/routes/api/users/+server.ts
import { json, error } from '@sveltejs/kit';
import type { RequestHandler } from './$types';
import { db } from '$lib/server/db';

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

export const POST: RequestHandler = async ({ request }) => {
  const body = await request.json();

  if (!body.email) {
    error(400, 'E-Mail ist Pflichtfeld');
  }

  const user = await db.user.create({ data: body });
  return json(user, { status: 201 });
};

Claude Code schreibt diese Handler mit korrekter Fehlerbehandlung, validierten Inputs und den richtigen HTTP-Statuscodes. Wenn du POST /api/users einen neuen Nutzer anlegen lassen sagst, liest es die bestehende Datenbankstruktur, importiert den richtigen DB-Client und schreibt einen Handler, der zum Rest der Codebasis passt.

5. Svelte Stores: Reaktiver globaler State

Stores sind Sveltes Antwort auf globalen State — leichter als Redux, direkter als React Context. Ein writable-Store ist in drei Zeilen definiert und in jeder Komponente verwendbar.

// src/lib/stores/cart.ts
import { writable, derived } from 'svelte/store';

interface CartItem { id: string; name: string; price: number; qty: number; }

export const cartItems = writable<CartItem[]>([]);

export const cartTotal = derived(
  cartItems,
  $items => $items.reduce((sum, item) => sum + item.price * item.qty, 0)
);

<!-- In einer Komponente -->
<script>
  import { cartItems, cartTotal } from '$lib/stores/cart';
</script>

<p>{$cartItems.length} Artikel — {$cartTotal.toFixed(2)} €</p>

Das $-Prefix ist Sveltes Auto-Subscription: keine manuelle subscribe/unsubscribe-Logik, keine Memory-Leaks. Claude Code schreibt Stores konsistent mit derived-Werten für berechnete Zustände und erklärt auf Anfrage, wann ein readable- oder get-Zugriff sinnvoller ist.

6. Form Actions: Formulare ohne JavaScript

Eine der stärksten SvelteKit-Funktionen: Form Actions erlauben serverseitige Formularverarbeitung, die auch ohne JavaScript im Browser funktioniert. Progressives Enhancement eingebaut, kein Workaround.

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

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

    if (!email || !message) {
      return fail(400, { email, error: 'Alle Felder sind Pflicht' });
    }

    // E-Mail versenden, Datenbankzugriff etc.
    await sendContactEmail({ email, message });

    return { success: true };
  }
};

<!-- src/routes/contact/+page.svelte -->
<script>
  import { enhance } from '$app/forms';
  export let form;
</script>

<form method="POST" use:enhance>
  <input name="email" type="email" value={form?.email ?? ''} />
  <textarea name="message"></textarea>
  {#if form?.error}<p class="error">{form.error}</p>{/if}
  <button type="submit">Senden</button>
</form>

use:enhance macht das Formular progressiv: Mit JavaScript wird die Seite nicht neu geladen, Fehler werden inline angezeigt. Ohne JavaScript funktioniert das Formular trotzdem vollständig. Claude Code schreibt Actions und das zugehörige Svelte-Template zusammen — konsistent, mit korrekter Fehlerrückgabe via fail().

7. Authentication mit Lucia

Lucia ist die empfohlene Auth-Bibliothek für SvelteKit: typsicher, datenbankagnostisch, ohne Magie. Sie kümmert sich um Sessions und User-Objekte; du entscheidest, wie du Passwörter hasht und Token speicherst.

// src/lib/server/auth.ts
import { Lucia } from 'lucia';
import { PrismaAdapter } from '@lucia-auth/adapter-prisma';
import { prisma } from './db';

export const lucia = new Lucia(new PrismaAdapter(prisma.session, prisma.user), {
  sessionCookie: { attributes: { secure: process.env.NODE_ENV === 'production' } },
  getUserAttributes: (attrs) => ({ email: attrs.email, role: attrs.role })
});

// src/hooks.server.ts — Session bei jedem Request prüfen
import type { Handle } from '@sveltejs/kit';
import { lucia } from '$lib/server/auth';

export const handle: Handle = async ({ event, resolve }) => {
  const sessionId = event.cookies.get(lucia.sessionCookieName);
  if (sessionId) {
    const { session, user } = await lucia.validateSession(sessionId);
    event.locals.user = user;
    event.locals.session = session;
  }
  return resolve(event);
};

Claude Code liest bei Authentication-Aufgaben immer zuerst die bestehende auth.ts und hooks.server.ts, bevor es neuen Code schreibt. Es erweitert konsistent statt zu überschreiben und weist explizit darauf hin, wenn eine Route einen Guard braucht.

8. Deployment auf Vercel und Cloudflare

SvelteKit ist Adapter-basiert: Du wechselst das Deployment-Ziel durch einen einzigen Package-Tausch, kein Framework-Wechsel. Vercel und Cloudflare Pages sind die beliebtesten Optionen.

# Für Vercel
npm install -D @sveltejs/adapter-vercel

# Für Cloudflare Pages
npm install -D @sveltejs/adapter-cloudflare

// svelte.config.js
import adapter from '@sveltejs/adapter-vercel'; // oder adapter-cloudflare

export default {
  kit: {
    adapter: adapter({
      runtime: 'nodejs22.x' // Vercel: Node.js-Version festlegen
    })
  }
};

Cloudflare-Besonderheit: Der Cloudflare-Adapter verwendet Workers statt Node.js. Das bedeutet: kein Zugriff auf Node-spezifische APIs wie fs, kein Prisma ohne speziellen Adapter, dafür weltweite Edge-Latenz. Claude Code weist auf diese Einschränkungen hin und schlägt Alternativen vor, bevor du in eine Sackgasse läufst.

9. Claude Code-Tipps speziell für SvelteKit

Einige Prompts, die sich in der täglichen SvelteKit-Arbeit bewährt haben:

• Neue Route anlegen: „Erstelle eine Route /dashboard/settings mit Load-Funktion, die den eingeloggten User aus locals.user liest, und einem Form Action zum Ändern der E-Mail-Adresse." Claude Code legt alle nötigen Dateien an, importiert korrekt aus $types und behandelt den nicht-eingeloggten Fall.
• Store-Logik: „Schreib einen writable Store für den Warenkorb mit add, remove und clear Methoden und einem derived Store für den Gesamtpreis."
• Typ-Fehler: Svelte-Typfehler direkt übergeben — Claude Code versteht die generierten $types-Importe und korrigiert Typ-Inkompatibilitäten präzise.
• Migration: „Ich wechsle von adapter-node zu adapter-cloudflare. Was muss sich im Code ändern?" Bekommt eine vollständige Checkliste: Node-APIs ersetzen, Prisma-Adapter tauschen, Umgebungsvariablen-Syntax anpassen.

Zwei weitere Artikel die dieses Thema ergänzen:

• Claude Code & Vercel Deployment — Zero-Downtime-Deploys, Previews und Environment Variables im Detail
• Claude Code & Prisma — Schema-Design, Migrationen und typsichere Datenbankzugriffe