Ein Leitfaden für Einsteiger zu Remote Functions in SvelteKit

Sie haben SvelteKit-Apps mit +server.ts-Endpunkten und Formularaktionen erstellt. Sie funktionieren, aber Sie schreiben Boilerplate-Code: Request-Bodies parsen, Eingaben manuell validieren und separate Typdefinitionen für Client und Server pflegen. SvelteKit Remote Functions bieten einen anderen Ansatz – typsichere Server-Aufrufe ohne die Umständlichkeit traditioneller API-Endpunkte.

Dieser Leitfaden erklärt, was Remote Functions sind, wann welcher Typ verwendet werden sollte und welche Kompromisse Sie verstehen sollten, bevor Sie sie einsetzen.

Was sind SvelteKit Remote Functions?

Remote Functions ermöglichen es Ihnen, serverseitigen Code zu schreiben, den Clients wie reguläre Funktionen aufrufen. Im Hintergrund kompiliert SvelteKit diese in HTTP-Endpunkte und generiert Fetch-Wrapper für den Client. Sie erhalten End-to-End-Typsicherheit, ohne traditionelle API-Routen erstellen oder warten zu müssen.

Stellen Sie es sich so vor, dass SvelteKit die Verbindung zwischen Ihrem Frontend und Backend übernimmt. Sie schreiben eine Funktion in einer .remote.ts-Datei, und SvelteKit kümmert sich um Serialisierung, Endpunkt-Generierung und Typ-Inferenz.

Die offizielle Referenz für dieses Feature finden Sie in der SvelteKit-Dokumentation unter Remote Functions: https://kit.svelte.dev/docs/remote-functions

Aktivierung des experimentellen Features

Remote Functions erfordern explizites Opt-in über kit.experimental.remoteFunctions in Ihrer svelte.config.js:

const config = {
  kit: {
    experimental: {
      remoteFunctions: true
    }
  }
};

export default config;

Wenn Sie await direkt in Svelte-Komponenten verwenden möchten, müssen Sie zusätzlich Sveltes experimentelle Async-Unterstützung separat aktivieren. Dies ist nicht erforderlich – Remote Functions funktionieren auch ohne – aber es vereinfacht den Komponenten-Code.

Die vier Typen von SvelteKit Server Functions

Remote Functions gibt es in vier Varianten, die jeweils für spezifische Anwendungsfälle konzipiert sind.

Query: Dynamische Daten abrufen

Verwenden Sie query, wenn Sie Daten aus Datenbanken, APIs oder anderen Server-Ressourcen lesen. Queries können während des Komponenten-Renderings ausgeführt werden und werden innerhalb desselben Render-Lebenszyklus dedupliziert und gebündelt.

import { query } from '$app/server';
import { db } from '$lib/db';
import { posts } from '$lib/schema';

export const getPosts = query(async () => {
  return await db.select().from(posts);
});

Für leistungskritische Szenarien gruppiert query.batch mehrere gleichzeitige Aufrufe in eine einzige Anfrage – das löst das n+1-Problem ohne manuelle Optimierung.

Form: Datenmutationen mit progressiver Verbesserung

Die form-Funktion verarbeitet Benutzereingaben. Ihr Hauptvorteil ist die progressive Verbesserung. Formulare funktionieren ohne JavaScript und fallen bei Bedarf auf traditionelle Übermittlung zurück.

Verteilen Sie das zurückgegebene Objekt auf Ihr <form>-Element, und SvelteKit verarbeitet sowohl verbesserte als auch nicht-verbesserte Übermittlungen automatisch.

Command: Flexible Mutationen

command funktioniert wie form, ist aber nicht an Formularelemente gebunden. Verwenden Sie es für Button-Klicks, Drag-and-Drop-Aktionen oder jede Mutation, die außerhalb eines Formularkontexts ausgelöst wird.

Im Gegensatz zu Formularen benötigen Commands JavaScript. Wählen Sie form, wenn progressive Verbesserung wichtig ist. Wählen Sie command, wenn Sie Flexibilität benötigen.

Prerender: Statische Daten zur Build-Zeit

prerender ruft Daten während des Builds ab, nicht zur Laufzeit. Die Ergebnisse werden zur Build-Zeit gecacht und über den Plattform-Cache oder CDN bereitgestellt. Verwenden Sie dies für Konfiguration, CMS-Inhalte, die sich nur bei Deployment ändern, oder alle Daten, die keine Echtzeit-Updates benötigen.

Wichtige Einschränkung: Sie können query nicht auf vollständig vorgerenderten Seiten verwenden, da Queries von Natur aus dynamisch sind.

Sicherheit: Jede Remote Function ist ein öffentlicher Endpunkt

Dies ist entscheidend zu verstehen: Jede Remote Function wird zu einem HTTP-Endpunkt, den jeder aufrufen kann. Eingabevalidierung ist nicht optional – sie ist unerlässlich.

SvelteKit erwartet, dass Sie Argumente mit Standard-Schema-Bibliotheken wie Zod oder Valibot validieren (die “Standard Schema”-Initiative ist unter https://standardschema.dev dokumentiert):

import { query } from '$app/server';
import * as v from 'valibot';
import { db } from '$lib/db';
import { posts } from '$lib/schema';

const Params = v.object({
  slug: v.string()
});

export const getPost = query(Params, async ({ slug }) => {
  return await db.select().from(posts).where(eq(posts.slug, slug));
});

Ohne Validierung können Angreifer beliebige Daten an Ihre Endpunkte senden. SvelteKit gibt bei Validierungsfehlern typischerweise 400er-Fehler zurück, um Informationslecks zu vermeiden.

Halten Sie SvelteKit aktuell

Frühere Versionen hatten Sicherheitslücken, die Remote Functions betrafen, einschließlich DoS-Problemen. Bleiben Sie mit Releases auf dem neuesten Stand, insbesondere solange das Feature experimentell bleibt (Stand: SvelteKit 2.x).

Kompromisse, die zu beachten sind

Remote Functions reduzieren Boilerplate-Code, sind aber keine Zauberei. Beachten Sie diese Einschränkungen:

• Dateispeicherort ist wichtig: .remote.ts-Dateien können überall in src liegen, außer in src/lib/server
• Prerender-Caching: Browser- und CDN-Caching bedeutet veraltete Daten bis zum nächsten Deployment
• Experimenteller Status: APIs können sich ändern und Bugs sind zu erwarten

Remote Functions funktionieren am besten, wenn Sie typsichere Client-Server-Kommunikation ohne Wartung separater Endpunkt-Definitionen wünschen. Sie sind kein Ersatz für jede +server.ts-Datei – komplexe Authentifizierungsabläufe oder Webhook-Handler von Drittanbietern rechtfertigen möglicherweise weiterhin traditionelle Endpunkte.

Wann welcher Funktionstyp verwendet werden sollte

Fazit

SvelteKit Remote Functions vereinfachen die Grenze zwischen Client- und Server-Code. Sie eliminieren manuelle Endpunkt-Wartung und bieten gleichzeitig integrierte Validierung und Typsicherheit. Beginnen Sie mit query für Datenabruf, fügen Sie form für Benutzereingaben hinzu und greifen Sie auf command oder prerender zurück, wenn diese spezifischen Muster zu Ihren Anforderungen passen.

Das Feature ist experimentell – erwarten Sie Änderungen. Aber für SvelteKit-Entwickler, die des Endpunkt-Boilerplates müde sind, bieten Remote Functions eine überzeugende Alternative, die es wert ist, erkundet zu werden.

Häufig gestellte Fragen (FAQs)

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.