Entwicklung & Automatisierung

Edge Computing

Was ist Edge Computing? Code läuft auf geografisch verteilten Servern nah am Nutzer statt in einem zentralen Rechenzentrum – minimale Latenz, serverless, automatisch skalierend. Moderne Alternative zu klassischen Servern.

Kurz erklärt

Edge Computing bezeichnet die Ausführung von Code auf Servern, die geografisch nah am Endnutzer liegen – am “Rand” (Edge) des Netzwerks statt in einem zentralen Rechenzentrum.

Der Unterschied zu klassischem Cloud Computing:

Klassisch: Nutzer → CDN (statische Inhalte) → Origin-Server in USA (dynamische Logik) Edge: Nutzer → Edge-Server in Frankfurt (statische Inhalte UND dynamische Logik)

Vorteile von Edge Computing:

Minimale Latenz durch geografische Nähe
Serverless: Keine Server-Verwaltung nötig
Skaliert automatisch mit dem Traffic
Ideal für: Personalisierung, A/B-Tests, Auth-Checks, API-Gateways

Bekannte Edge-Plattformen:

Cloudflare Workers – JavaScript/TypeScript am Edge
Vercel Edge Functions – für Next.js optimiert
Deno Deploy – basiert auf Deno Runtime
AWS Lambda@Edge – Teil von CloudFront

Für Code-First-Projekte mit Astro oder Next.js ist Edge Computing die moderne Alternative zu klassischen Servern – schneller, skalierbarer und oft günstiger.

Edge Computing vs. Cloud Computing vs. CDN

Traditionelles Cloud Computing (Origin-Server)

Architektur:

Nutzer → CDN (statische Dateien) → Origin-Server (dynamische Logik)

Beispiel: Heroku, AWS EC2, DigitalOcean Droplet

Merkmale:

Server läuft in 1-2 festen Rechenzentren (z. B. Frankfurt, Virginia)
Nutzer weit entfernt haben hohe Latenz
Server muss manuell skaliert werden
Volle Kontrolle über Server-Umgebung

Latenz-Beispiel:

Nutzer in Tokyo → US-Server: 300-400 ms
Nutzer in Deutschland → US-Server: 150-200 ms

CDN (Content Delivery Network)

Architektur:

Nutzer → CDN (statische Dateien + Cache)

Beispiel: Cloudflare, Fastly, AWS CloudFront

Merkmale:

Verteilt nur statische Inhalte (HTML, CSS, JS, Bilder)
Keine dynamische Code-Ausführung (traditionell)
Cache-basiert: Origin-Server generiert Inhalte, CDN cached

Siehe auch: CDN

Edge Computing

Architektur:

Nutzer → Edge-Server (statische Dateien + dynamische Logik)

Beispiel: Cloudflare Workers, Vercel Edge, Deno Deploy

Merkmale:

Verteilt statische UND dynamische Inhalte
Code läuft auf 100+ Standorten gleichzeitig
Serverless: Keine Server-Verwaltung
Auto-Scaling: Von 0 auf Millionen Requests

Latenz-Beispiel:

Nutzer in Tokyo → Tokyo-Edge: 10-20 ms
Nutzer in Deutschland → Frankfurt-Edge: 10-20 ms

Vergleichstabelle

Aspekt	Origin-Server	CDN	Edge Computing
Standorte	1-2	50-300	100-300
Latenz	100-400 ms	10-50 ms (statisch)	10-50 ms (dynamisch)
Dynamische Logik	✅ Ja	❌ Nein (nur Cache)	✅ Ja
Skalierung	Manuell	Automatisch	Automatisch
Server-Verwaltung	✅ Ja	❌ Nein	❌ Nein
Kosten	Fix (Server-Miete)	Pay-per-use	Pay-per-use

Edge Computing Use Cases

1. Personalisierung

Problem: Nutzer sollen personalisierte Inhalte sehen, aber SSR vom Origin-Server ist langsam.

Edge-Lösung:

// Cloudflare Worker
export default {
  async fetch(request) {
    const country = request.cf.country; // Edge kennt Nutzer-Standort

    if (country === 'DE') {
      return fetch('https://example.com/de');
    } else if (country === 'FR') {
      return fetch('https://example.com/fr');
    }

    return fetch('https://example.com');
  }
};

Vorteile:

Nutzer-Standort am Edge bekannt (keine API-Calls nötig)
Routing am Edge = keine zusätzliche Latenz
Cached Content kann trotzdem personalisiert werden

2. A/B-Testing

Problem: A/B-Testing per JavaScript = Flash of Unstyled Content (FOUC).

Edge-Lösung:

// Vercel Edge Function
export default function handler(request) {
  const variant = Math.random() < 0.5 ? 'A' : 'B';

  return Response.redirect(`https://example.com/${variant}`);
}

Vorteile:

Kein FOUC (Server-seitiges Rendering)
Schneller als Origin-Server
Variant-Tracking am Edge

3. Authentication & Authorization

Problem: Auth-Checks am Origin-Server = zusätzliche Latenz für jeden Request.

Edge-Lösung:

// Deno Deploy
Deno.serve(async (request) => {
  const token = request.headers.get('Authorization');

  if (!token || !await verifyToken(token)) {
    return new Response('Unauthorized', { status: 401 });
  }

  // Request zu Origin weiterleiten
  return fetch('https://origin.example.com', request);
});

Vorteile:

Ungültige Requests werden am Edge abgelehnt (Origin entlastet)
JWT-Verifikation am Edge (keine Origin-Roundtrip)
Globale Auth-Layer ohne Origin-Server-Änderungen

4. API Gateway & Rate Limiting

Problem: Origin-Server wird von API-Requests überlastet.

Edge-Lösung:

// Cloudflare Worker mit Rate Limiting
const rateLimit = new Map();

export default {
  async fetch(request) {
    const ip = request.headers.get('CF-Connecting-IP');
    const count = rateLimit.get(ip) || 0;

    if (count > 100) {
      return new Response('Rate limit exceeded', { status: 429 });
    }

    rateLimit.set(ip, count + 1);
    return fetch('https://api.example.com', request);
  }
};

Vorteile:

Rate Limiting am Edge (Origin-Server geschützt)
Globale Rate Limits über alle Edge-Standorte
DDoS-Schutz inklusive

5. Image Optimization

Problem: Bilder sollen in verschiedenen Formaten (WebP, AVIF) ausgeliefert werden.

Edge-Lösung:

// Cloudflare Workers (mit Image Resizing)
export default {
  async fetch(request) {
    const url = new URL(request.url);
    const format = request.headers.get('Accept').includes('avif') ? 'avif' : 'webp';

    return fetch(url, {
      cf: {
        image: {
          format,
          quality: 85,
          width: 800
        }
      }
    });
  }
};

Vorteile:

On-the-fly Image-Transformation
Format-Negotiation am Edge
Keine Origin-Server-Last

Edge-Plattformen im Vergleich

Cloudflare Workers

Technologie: V8 Isolates (JavaScript/TypeScript/Rust/C++)

Standorte: 310+ weltweit

Cold Start: <1 ms (keine Cold Starts dank Isolates)

Limits:

CPU-Zeit: 50 ms (kostenlos), 50-500 ms (paid)
Memory: 128 MB
Request-Größe: 100 MB

Kosten:

100.000 Requests/Tag: kostenlos
$5/Monat für 10 Mio. Requests

Ideal für: Middleware, Auth, Routing, kleine APIs

Beispiel:

export default {
  async fetch(request, env, ctx) {
    return new Response('Hello from Cloudflare Edge!');
  }
};

Vercel Edge Functions

Technologie: V8 Isolates (JavaScript/TypeScript)

Standorte: 100+ weltweit

Cold Start: <5 ms

Limits:

Execution Time: 30 s (Hobby), 5 min (Pro)
Memory: Unbegrenzt
Request-Größe: 4 MB (Hobby), 100 MB (Pro)

Kosten:

100 GB-Stunden/Monat: kostenlos
$20/Monat (Pro) für mehr

Ideal für: Next.js-Projekte, Middleware, API-Routes

Beispiel:

// app/api/hello/route.ts
export const runtime = 'edge';

export async function GET(request: Request) {
  return new Response('Hello from Vercel Edge!');
}

Deno Deploy

Technologie: Deno Runtime (TypeScript/JavaScript)

Standorte: 35+ weltweit

Cold Start: ~10 ms

Limits:

Execution Time: 15 min
Memory: 512 MB
Request-Größe: Unbegrenzt

Kosten:

100.000 Requests/Tag: kostenlos
$20/Monat (Pro) für 5 Mio. Requests

Ideal für: Full-stack TypeScript-Apps, Deno-Projekte

Beispiel:

Deno.serve((request) => {
  return new Response('Hello from Deno Edge!');
});

AWS Lambda@Edge

Technologie: Node.js, Python (Container-basiert)

Standorte: 400+ CloudFront-Edge-Locations

Cold Start: 100-500 ms (Container-Start)

Limits:

Execution Time: 5 s (Viewer-Events), 30 s (Origin-Events)
Memory: 128 MB (Viewer), 10 GB (Origin)
Package Size: 1 MB (Viewer), 50 MB (Origin)

Kosten:

$0,60 pro 1 Mio. Requests
$0,00005001 pro GB-Sekunde

Ideal für: AWS-Integration, komplexe Logik, Origin-Transformation

Beispiel:

exports.handler = async (event) => {
  const request = event.Records[0].cf.request;
  return request;
};

Edge Computing mit Astro

Astro SSR + Edge:

// astro.config.mjs
import { defineConfig } from 'astro/config';
import vercel from '@astrojs/vercel/edge'; // Vercel Edge Adapter

export default defineConfig({
  output: 'server', // SSR aktivieren
  adapter: vercel(),
});

Edge-Route:

---
// src/pages/api/hello.ts
export const prerender = false; // SSR für diese Route

export async function GET({ request }) {
  const country = request.headers.get('x-vercel-ip-country') || 'Unknown';

  return new Response(JSON.stringify({
    message: `Hello from ${country}!`,
    edge: true
  }), {
    headers: { 'Content-Type': 'application/json' }
  });
}
---

Deployment:

npm run build
vercel deploy

Ergebnis: API läuft auf 100+ Edge-Standorten automatisch.

Edge Computing Best Practices

1. Stateless Functions

Edge-Funktionen sind stateless – kein persistenter State zwischen Requests.

Falsch:

let counter = 0; // Wird bei jedem Deployment zurückgesetzt

export default {
  async fetch(request) {
    counter++; // Funktioniert NICHT über Requests hinweg
    return new Response(`Counter: ${counter}`);
  }
};

Richtig:

// State in KV-Store (Cloudflare KV, Vercel KV)
export default {
  async fetch(request, env) {
    let counter = await env.KV.get('counter') || 0;
    counter++;
    await env.KV.put('counter', counter);
    return new Response(`Counter: ${counter}`);
  }
};

2. Cold Starts minimieren

V8 Isolates (Cloudflare, Vercel) haben keine Cold Starts.

Container-basiert (AWS Lambda@Edge) hat Cold Starts:

Kleine Bundle-Größen verwenden
Tree-Shaking nutzen
Provisioned Concurrency verwenden (kostenpflichtig)

3. Edge vs. Origin entscheiden

Edge geeignet für:

Authentifizierung & Authorization
Routing & Redirects
Header-Manipulation
A/B-Testing
Rate Limiting
Kleine APIs (<50 ms CPU-Zeit)

Origin besser für:

Komplexe Business-Logik (>50 ms CPU-Zeit)
Datenbankabfragen (Edge hat keine direkte DB-Verbindung)
File-Uploads (große Payloads)
Long-Running Tasks (>30 s)

4. Edge + Origin kombinieren

Hybrid-Architektur:

Nutzer → Edge (Auth, Routing) → Origin (Business-Logik, DB)

Beispiel:

// Edge: Auth-Check
export default {
  async fetch(request, env) {
    const token = request.headers.get('Authorization');

    if (!await verifyToken(token)) {
      return new Response('Unauthorized', { status: 401 });
    }

    // Zu Origin weiterleiten
    return fetch('https://origin.example.com', request);
  }
};

5. Caching am Edge

Edge kann statische Responses cachen:

export default {
  async fetch(request) {
    const cache = caches.default;
    let response = await cache.match(request);

    if (!response) {
      response = new Response('Hello from Edge!');
      response.headers.set('Cache-Control', 'public, max-age=3600');
      await cache.put(request, response.clone());
    }

    return response;
  }
};

Edge Computing und Performance

Latenz-Reduktion

Messbare Verbesserung:

Vor Edge Computing (Origin in USA):
- Deutschland: 150-200 ms
- Tokyo: 300-400 ms
- Sydney: 500-600 ms

Nach Edge Computing:
- Deutschland: 10-20 ms (Frankfurt-Edge)
- Tokyo: 10-20 ms (Tokyo-Edge)
- Sydney: 20-30 ms (Sydney-Edge)

10-30x schneller für API-Requests!

TTFB-Verbesserung

Edge Computing verbessert TTFB drastisch:

Ohne Edge:

TTFB = DNS (20 ms) + TCP (50 ms) + TLS (50 ms) + Server (200 ms) = 320 ms

Mit Edge:

TTFB = DNS (20 ms) + TCP (10 ms) + TLS (10 ms) + Edge (10 ms) = 50 ms

Siehe auch: TTFB

Kosten-Vergleich

Klassischer Server (z. B. AWS EC2 t3.small)

Fixkosten:

$15-20/Monat für Server
Immer an, auch bei 0 Requests

Skalierung:

Manuell (größere Instance buchen)
Traffic-Spitzen = teurere Instance nötig

Edge Computing (z. B. Cloudflare Workers)

Pay-per-use:

100.000 Requests/Tag: $0
10 Mio. Requests/Monat: $5

Skalierung:

Automatisch (0 → Millionen Requests)
Keine Kapazitätsplanung

Break-Even:

<1 Mio. Requests/Monat: Edge günstiger
10 Mio. Requests/Monat: Ähnliche Kosten
Traffic-Spitzen: Edge deutlich günstiger (kein Overprovisioning)

Nächste Schritte

Edge-Plattform wählen (Cloudflare Workers für Einstieg, Vercel für Next.js, Deno für TypeScript)
Einfache Edge-Funktion testen (Hello World, Geo-Routing)
Use Case identifizieren (Auth, A/B-Testing, Personalisierung)
Latenz-Verbesserung messen (vor/nach Edge)
Produktiv deployen mit CI/CD (GitHub Actions + Edge-Platform)
Monitoring einrichten (Edge-Dashboard, Logs)

Siehe auch

CDN – Statische Inhalte am Edge
CLI-first Delivery – Moderne Deployment-Workflows
GitOps – Git-basiertes Deployment für Edge
Automation – Automatisierung von Edge-Deployments

Praxisnutzen & Umsetzung

Quellen & weiterführende Links

Cloudflare – What is Edge Computing?

Vercel – Edge Functions Documentation

Deno Deploy – Edge Runtime

Edge Computing

Praxisnutzen & Umsetzung

Quellen & weiterführende Links

Verwandte Begriffe