Edge-Konfiguration ist genau deshalb leistungsstark, weil der Anwendungsfall eng gefasst ist. Es handelt sich nicht um eine allgemeine Datenbank. Es ist ein schneller, global verfügbarer Ort, um kleine Werte zu lesen, die das Anfragehandling in der Nähe des Nutzers beeinflussen.
Wo es sich auszahlt
Die besten Anwendungsfälle sind kleine, überwiegend lesende Entscheidungen:
- Feature-Flags
- Not-Aus-Schalter
- länderbasierte Weiterleitung
- Banner-Umschalter
- Experimentkonfiguration
Solche Daten können TTFB und Benutzererfahrung beeinflussen, wenn jede Anfrage zuerst zum Ursprung zurückgehen muss.
Ein typisches Edge-Lesen sieht so aus:
import { get } from "@vercel/edge-config";
const homepageVariant = await get("homepage-variant");
Das ist klein, kann jedoch eine ganze Origin-Abhängigkeit aus dem Anfragepfad entfernen.
Die wichtige Auditfrage ist, ob der Wert klein, leseintensiv und latenzsensibel ist. Wenn die Antwort nein lautet, kann das Verschieben an den Edge ein komplizierteres System schaffen, ohne bedeutende Fortschritte bei den Core Web Vitals.
Was nicht dorthin gehört
Edge-Config ist das falsche Werkzeug für:
- hochschreibende Arbeitslasten
- relationale Abfragen
- große Dokumente
- Daten, die transaktionale Garantien benötigen
Wenn die Plattformentscheidung über kleine dynamische Lesevorgänge hinauswächst, sprechen Sie nicht mehr von Konfiguration. Sie sprechen von Datenarchitektur.
Bessere Regel
Verwenden Sie Edge-Config, wenn ein kleiner Wert globale Nähe benötigt und der Lesevorgang für die Latenz von Bedeutung ist. Fördern Sie ihn nicht zu einer Datenbank, nur weil es bequem ist.
Weiterführende Literatur