Supabase Edge Functions in der Praxis: Deno-Runtime und globale Edge-Bereitstellung

Die rote Linie auf dem Monitoring-Dashboard – API-Antwortzeit bei 2,3 Sekunden.

Nutzer in Japan, Server in Ohio. Allein die Roundtrip-Latenz liegt bei 120 ms – plus Datenbankabfrage und Business-Logik. Kein Wunder, dass es langsam wirkt.

„Probier mal Edge Functions?“ schrieb ein Kollege in Slack.

Skeptisch war ich. Edge Functions – nur Code an einem anderen Ort? Wie viel kann das bringen? Ein Test später: Cold Start 120 ms, Antwort 47 ms. Dieselbe Logik, vom Ohio-Server zum Edge-Knoten in Tokio – fast fünfmal schneller.

Supabase Edge Functions laufen auf der Deno-Runtime an globalen Edge-Knoten. In diesem Artikel erklären wir, warum das so schnell ist, wie sich Deno von Node.js unterscheidet, wie Sie von null eine Edge Function aufbauen – und wann Cloudflare Workers die bessere Wahl sind.

1. Kernkonzept: Was Edge Functions sind und warum sie schnell sind

Kurz gesagt: Edge Functions verlagern Ihren Code vom zentralen Server an Edge-Knoten.

Früher lief eine Lambda-Funktion in einer festen Region (z. B. US-East oder Europa). Ein Request aus Tokio musste über den Ozean, wurde verarbeitet und zurückgeschickt. Die physische Distanz setzt eine Latenzuntergrenze – Lichtgeschwindigkeit ist endlich.

Edge Functions drehen das um. Ihr Code wird in ein kompaktes Format namens ESZip gepackt und automatisch auf Dutzende Edge-Knoten weltweit verteilt. Request aus Tokio? Ausführung in Tokio – der transozeanische Teil entfällt.

Was ist ESZip?

Ein Bundling-Format vom Deno-Team. Anders als klassische JavaScript-Bundles packt ESZip nicht nur Code, sondern den gesamten Modul-Abhängigkeitsgraphen mit. Vorteil beim Start: keine Netzwerk-Dependency-Downloads – alles in einer Datei. Cold Start wird von „Pakete laden + parsen + ausführen“ zu „entpacken + ausführen“.

Isolate-Ausführungsmodell

Supabase Edge Functions laufen in V8-Isolates, nicht in klassischen Containern oder VMs. Ein Isolate ist wie ein ultraleichter Worker-Container: ein Prozess, viele Isolates, ein Isolate pro Request. Leichter als Container, schneller beim Start.

Laut Supabase-Dokumentation beträgt das CPU-Zeitlimit pro Isolate 400 Sekunden (Soft- plus Hard-Limit). Das klingt viel – Edge Functions sind aber nicht für schwere Jobs: JWT prüfen, Requests weiterleiten, leichte Logik. Rechenintensive Arbeit gehört auf zentrale Server.

Ein minimales Beispiel:

// Minimales Edge-Function-Beispiel
import "jsr:@supabase/functions-js/edge-runtime.d.ts"

Deno.serve(async (req) => {
  const { name } = await req.json()
  const data = { message: `Hello ${name}!` }
  return new Response(JSON.stringify(data), {
    headers: { "Content-Type": "application/json" }
  })
})

Der Code läuft am Edge-Knoten: Deno.serve empfängt, verarbeitet, antwortet – alles am nächstgelegenen Knoten.

2. Deno-Runtime: die „sichere Weiterentwicklung“ von Node.js

Beim ersten Hören von Deno fragte ich mich: Node.js ist so ausgereift – warum noch eine Runtime?

Die Antwort ist einfach: Node.js ist zu früh entstanden; manche Probleme zeigten sich erst später.

Sicherheit

Node.js vertraut standardmäßig allem: Dateisystem, Netzwerk, Systembefehle – alles möglich. Ein bösartiges Dependency kann viel anrichten.

Deno kehrt das um. Standard: Sandbox – kein Dateizugriff, kein Netzwerk, keine Shell. Rechte müssen explizit gesetzt werden:

# Netzwerkrecht
deno run --allow-net server.ts

# Datei-Lese-/Schreibrecht
deno run --allow-read --allow-write file_ops.ts

# Alle Rechte (sparsam nutzen)
deno run -A everything.ts

Am Edge ist das wichtig: Ihre Funktion läuft auf Dutzenden Knoten – ein Angriff skaliert mit.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Cold Start

Gleicher Code auf Deno Deploy vs. AWS Lambda (Node.js):

Etwa Faktor drei. Kerne: Deno ohne Node.js-Historie – kein CommonJS, kein require-Resolve, kein node_modules-Pfad. ESZip plus natives TypeScript spart Start-Overhead.

Modulsystem

Node.js: CommonJS, require(), npm, package.json, node_modules – bei großen Projekten hunderte Megabyte.

Deno: ESM-Standard. Kein npm, kein package.json, kein node_modules. Import per URL:

// Direkt von URL importieren
import { serve } from "https://deno.land/[email protected]/http/server.ts"

// oder JSR (Deno-Paketregistry)
import { cors } from "jsr:@hono/hono/cors"

Beim ersten Lauf cached Deno Module lokal; danach Start aus dem Cache.

TypeScript ohne Konfiguration

Unter Node.js: ts-node, webpack/vite/esbuild, tsconfig.json. Deno führt .ts nativ aus:

deno run hello.ts

Kompilierung und Typprüfung zur Laufzeit – schlankere Entwicklung.

Vendor Lock-in

Sorge: Mit Supabase Edge Functions fest gebunden?

Nicht zwingend. Deno ist Open Source; Supabase Edge Runtime ebenfalls (Quellcode auf GitHub). Theoretisch selbst hostbar – nur das globale Edge-Netzwerk müssten Sie selbst betreiben. Technisch kein „kein Ausweg“.

3. Praxis: Ihre erste Edge Function in 10 Minuten

Theorie reicht nicht – ausprobieren hilft.

Nach der offiziellen Doku von Installation bis Deploy: unter 10 Minuten. Ablauf:

Schritt 1: Supabase CLI installieren

npm install -g supabase

Version prüfen:

supabase --version
# z. B.: 1.200.0

Schritt 2: Projekt initialisieren

supabase init

Erzeugt das Verzeichnis supabase mit config.toml.

Schritt 3: Edge Function anlegen

supabase functions new hello-world

Unter supabase/functions/hello-world/ entsteht index.ts, etwa:

import "jsr:@supabase/functions-js/edge-runtime.d.ts"

Deno.serve(async (req) => {
  const data = {
    message: "Hello from Edge Function!"
  }

  return new Response(JSON.stringify(data), {
    headers: { "Content-Type": "application/json" }
  })
})

Eigene Logik – z. B. Parameter name und Begrüßung:

import "jsr:@supabase/functions-js/edge-runtime.d.ts"

Deno.serve(async (req) => {
  // Nur POST erlauben
  if (req.method !== "POST") {
    return new Response("Method not allowed", { status: 405 })
  }

  try {
    const body = await req.json()
    const name = body.name || "Stranger"

    return new Response(JSON.stringify({
      message: `Hey ${name}, welcome to the edge!`,
      timestamp: new Date().toISOString()
    }), {
      headers: { "Content-Type": "application/json" }
    })
  } catch (err) {
    return new Response(JSON.stringify({ error: "Invalid JSON" }), {
      status: 400,
      headers: { "Content-Type": "application/json" }
    })
  }
})

Schritt 4: Lokal testen

supabase functions serve --no-verify-jwt

Port standardmäßig 54321 – mit curl:

curl -X POST http://localhost:54321/functions/v1/hello-world \
  -H "Content-Type: application/json" \
  -d '{"name":"Easton"}'

# Antwort:
# {"message":"Hey Easton, welcome to the edge!","timestamp":"2026-05-03T14:30:00.000Z"}

--no-verify-jwt überspringt JWT – praktisch lokal; in Produktion Verifizierung aktivieren.

Schritt 5: Global deployen

# Login (falls noch nicht)
supabase login

# Projekt verknüpfen
supabase link --project-ref <your-project-id>

# Deploy
supabase functions deploy hello-world

Supabase verteilt die Funktion auf Edge-Knoten weltweit. Im Dashboard: Deploy-Logs und Funktions-URL.

Schritt 6: Aufruf testen

URL-Format:

https://<project-id>.supabase.co/functions/v1/hello-world

Mit curl:

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

curl -X POST https://<project-id>.supabase.co/functions/v1/hello-world \
  -H "Authorization: Bearer <anon-key>" \
  -H "Content-Type: application/json" \
  -d '{"name":"World"}'

Authorization-Header: Edge Functions prüfen standardmäßig JWT – anon key oder User-JWT mitgeben.

Wofür Edge Functions außer Demos? Typische Szenarien:

Webhook-Verarbeitung

Stripe sendet nach Zahlung einen Webhook – Edge Function empfängt und schreibt in die DB:

// supabase/functions/stripe-webhook/index.ts
import "jsr:@supabase/functions-js/edge-runtime.d.ts"
import { createClient } from "jsr:@supabase/supabase-js@2"

Deno.serve(async (req) => {
  // Stripe-Signatur prüfen (hier vereinfacht, produktiv HMAC)
  const event = await req.json()

  const supabase = createClient(
    Deno.env.get("SUPABASE_URL")!,
    Deno.env.get("SUPABASE_SERVICE_ROLE_KEY")!
  )

  if (event.type === "payment_intent.succeeded") {
    const payment = event.data.object

    await supabase.from("payments").insert({
      id: payment.id,
      amount: payment.amount,
      customer_id: payment.customer,
      created_at: new Date().toISOString()
    })
  }

  return new Response(JSON.stringify({ received: true }), {
    headers: { "Content-Type": "application/json" }
  })
})

API-Proxy

Drittanbieter-API braucht Key, den Sie nicht ins Frontend legen wollen:

// supabase/functions/openai-proxy/index.ts
Deno.serve(async (req) => {
  const body = await req.json()

  const response = await fetch("https://api.openai.com/v1/chat/completions", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${Deno.env.get("OPENAI_API_KEY")}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify(body)
  })

  return new Response(response.body, {
    headers: { "Content-Type": "application/json" }
  })
})

Frontend ruft Ihre Edge Function auf – der API-Key bleibt am Edge.

4. Auswahl: Supabase vs. Cloudflare Workers

Bei Edge-Computing fragen viele: Cloudflare Workers oder Supabase Edge Functions?

Keine direkten Konkurrenten – unterschiedliche Szenarien.

Performance

Cold Start: Cloudflare Workers ~30 ms, Supabase Edge Functions ~120 ms.

Cloudflare nutzt eine eigene Runtime, stark für Edge optimiert. Supabase setzt auf Deno – schnell, aber mit TypeScript-Kompilierungsschicht.

In der Praxis merken die meisten Nutzer 120 ms vs. 30 ms nicht; Netzwerk-Schwankungen sind oft größer. Bei Hochfrequenz-Trading oder Echtzeit-Auktionen eher Cloudflare Workers.

Integration

Supabase-Stärke: Postgres, Auth, Storage im selben Projekt – Umgebungsvariablen automatisch, wenig Extra-Konfiguration.

Bei Cloudflare Workers: DB-Verbindung selbst lösen – D1 (SQLite am Edge) oder externe DB, mehr Setup.

Vendor Lock-in

Cloudflare Workers-Runtime ist proprietär – Code läuft praktisch nur dort; Plattformwechsel bedeutet Anpassungen.

Supabase Edge Functions nutzen Open-Source-Deno – gleicher Code theoretisch auf Deno Deploy oder selbst gehosteter Edge Runtime. Das Supabase-Edge-Netzwerk selbst ist nicht portierbar, die Runtime-Schicht aber offener.

Ökosystem

Cloudflare Workers seit 2017 – reife Tools, Frameworks, Community. Hono, Remix unterstützen Workers.

Supabase Edge Functions seit 2022 – wächst; Standard-Deno-Bibliotheken oft direkt nutzbar.

Empfehlung

Praxis: hybrid – Cloudflare Workers für Reverse Proxy und Cache, Supabase Edge Functions für Auth und DB-Logik.

5. Fallstricke und Best Practices

Aus der Praxis – damit Sie Umwege vermeiden.

Fallstrick 1: Node.js-Pakete

import axios from "axios" – Deploy schlägt fehl: Modul nicht gefunden.

Deno, nicht Node.js. npm-Pakete nicht direkt – Deno-kompatible Pakete oder natives fetch:

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

// Kein axios
// import axios from "axios"  // Fehler

// fetch nutzen
const response = await fetch("https://api.example.com/data", {
  method: "GET",
  headers: { "Authorization": "Bearer xxx" }
})
const data = await response.json()

Alternative im Deno-Ökosystem: z. B. ky.

Fallstrick 2: Laufzeit zu lang

Batch-Funktion über tausende Datensätze – lokal ok, Deploy bricht nach ~30 Sekunden ab.

CPU-Zeitlimit: Isolate max. 400 Sekunden (Soft + Hard). Überschreitung → Prozessende.

Lösung: keine schwere Arbeit am Edge – Validierung, Weiterleitung, leichte Berechnung. Batch auf zentralen Server oder Worker-Dienst.

Fallstrick 3: Falsche DB-Verbindung

Klassische Long-Lived-Connections am Edge: viele Knoten, voller Connection Pool.

Supabase Pooler oder kurze Verbindungen pro Request. SUPABASE_DB_URL zeigt auf den Pooler:

import { Pool } from "https://deno.land/x/[email protected]/mod.ts"

const pool = new Pool(Deno.env.get("SUPABASE_DB_URL")!, 10)

Deno.serve(async (req) => {
  const client = await pool.connect()
  try {
    const result = await client.queryArray("SELECT * FROM users LIMIT 10")
    return new Response(JSON.stringify(result.rows))
  } finally {
    client.release()  // Nicht vergessen!
  }
})

Fallstrick 4: JWT-Verifizierung vergessen

Lokal --no-verify-jwt – Deploy ohne Verifizierung: jeder kann die Funktion aufrufen.

In config.toml:

[functions.hello-world]
verify_jwt = true

Oder beim Deploy:

supabase functions deploy hello-world --verify-jwt

Praktische Tipps

1. Hono statt barem Deno.serve

Hono: leichtes Web-Framework fürs Edge – Routing, Middleware, ~13 KB. Für Edge Functions oft angenehmer als Express:

import { Hono } from "jsr:@hono/hono"
import { cors } from "jsr:@hono/hono/cors"

const app = new Hono()

app.use("*", cors())

app.get("/health", (c) => c.json({ status: "ok" }))

app.post("/echo", async (c) => {
  const body = await c.req.json()
  return c.json({ echo: body })
})

Deno.serve(app.fetch)

2. Umgebungsvariablen

Zwei Runtimes: Main Runtime (Supabase) und User Runtime (Ihr Code) – unterschiedliche Rechte:

• SUPABASE_URL, SUPABASE_ANON_KEY, SUPABASE_SERVICE_ROLE_KEY automatisch injiziert
• Eigene Variablen: Dashboard oder supabase secrets set MY_VAR=value

3. Import Map

Viele externe Module: Import Map reduziert wiederholtes URL-Parsing:

// deno.json oder import_map.json
{
  "imports": {
    "hono": "jsr:@hono/hono",
    "supabase-js": "jsr:@supabase/supabase-js@2"
  }
}

Kurzimport im Code:

import { Hono } from "hono"
import { createClient } from "supabase-js"

Fazit

Kernbotschaft: Supabase Edge Functions bringen Code zum nächsten Knoten, laufen sicher auf Deno, Cold Start ~120 ms, globale Verteilung automatisch.

Nutzen Sie bereits Supabase – Auth, Database oder Storage – sind Edge Functions die naheliegende Erweiterung. Kein separates DB-Setup, Auth passt direkt. Vendor Lock-in? Deno ist Open Source, Edge Runtime selbst hostbar – ein Ausweg bleibt.

Nächster Schritt: Supabase Dashboard, Quickstart durchspielen – in 10 Minuten läuft Ihre erste Edge Function global.

Weitere Artikel der Serie:

• Supabase-Einstieg: PostgreSQL + Auth + Storage als Backend – Überblick über Supabase
• Supabase Auth in der Praxis: E-Mail-Verifizierung, OAuth und Sessions – Auth im Einsatz
• Supabase Auth vertieft: OAuth, SSO und Berechtigungen – Fortgeschrittene Konfiguration

Interesse an Cloudflare Workers: Cloudflare Workers – Praxisleitfaden. Beide Plattformen haben Stärken – wählen Sie, was zu Ihrem Stack passt.