Anfragen an benannte Zähler weiterleiten

Einführung

Ein gewöhnlicher Cloudflare Worker kann viele Anfragen beantworten. Eine Anfrage kann jedoch nicht davon ausgehen, dass die nächste Anfrage dieselbe laufende JavaScript-Instanz erreicht. Dieses zustandslose Design eignet sich hervorragend für unabhängige Aufgaben. Es wird jedoch unpraktisch, wenn mehrere Anfragen sich auf einen veränderlichen Wert einigen müssen, zum Beispiel auf die Anzahl der Personen in einer Support-Warteschlange.

Ein Durable Object stellt der Anwendung eine adressierbare Koordinationseinheit bereit. In diesem Lab wählt jeder Zählername ein anderes Objekt aus. Anfragen für support erreichen wiederholt denselben logischen Zähler, während Anfragen für billing einen anderen Zähler mit getrenntem Zustand erreichen. Cloudflare kann die zugrunde liegende Laufzeit verschieben oder neu starten. Die stabile Objektidentität und der SQLite-basierte Zustand bleiben jedoch Teil des Anwendungskontrakts.

Sie verbinden vier Konzepte:

1. Eine Klasse legt fest, was ein Zählerobjekt tun kann.
2. Ein Namespace ist die Sammlung der Objekte, die von dieser Klasse unterstützt werden.
3. Ein Binding ermöglicht dem vorgeschalteten Worker den Zugriff auf den Namespace.
4. getByName() wandelt denselben validierten Namen in dieselbe Objektreferenz um, und eine RPC-Methode ruft den Code dieses Objekts auf.

Sie erstellen die Anwendung, weisen die namensbasierte Weiterleitung lokal nach, stellen sie in Ihrem eigenen Cloudflare-Lernkonto bereit, verknüpfen Terminal-Nachweise mit dem Dashboard und entfernen anschließend sowohl den Klassen-Namespace als auch den Worker.

Schließen Sie vor Beginn dieses Kurses LabEx mit Ihrem Cloudflare-Konto verbinden ab. Dort lernen Sie das LabEx-VM-Terminal, die Wrangler-Geräteautorisierung, die Kontobestätigung und die Konfiguration der Konto-ID kennen. Sie sollten bereits wissen, wie ein kleiner JavaScript-Worker eine HTTP-Anfrage verarbeitet. Vorkenntnisse zu Durable Objects sind nicht erforderlich.

Laut der aktuellen offiziellen Dokumentation sind SQLite-basierte Durable Objects in Workers Free verfügbar. Dieses Lab erstellt einen kurzlebigen Klassen-Namespace, einige kleine Objekte und ausschließlich begrenzte Anfragen. Workers Paid ist nicht erforderlich. Die Einrichtung installiert Node.js 22.22.0 und Wrangler 4.132.0 lokal im Projektverzeichnis /home/labex/project/named-counters. Sie meldet Sie nicht an, erstellt keinen Cloud-Zustand, stellt keinen Code bereit und vervollständigt nicht die Implementierung des Lernenden.

VM autorisieren und Anwendung benennen

In diesem Schritt verbinden Sie diese frische LabEx-VM mit Ihrem Cloudflare-Lernkonto und erstellen eine eindeutige Anwendungskonfiguration. Wenn Sie in einem Browser beim Dashboard angemeldet sind, werden Befehle in einer neuen VM nicht automatisch autorisiert.

Wechseln Sie in das vorbereitete Projekt und überprüfen Sie die festgelegte Wrangler-Version:

cd /home/labex/project/named-counters
npx wrangler --version

Erwartet wird 4.132.0. Starten Sie den Geräteautorisierungsablauf von Wrangler:

npx wrangler login --device --browser=false

Wrangler gibt eine URL und einen kurzen Gerätecode aus. Öffnen Sie die URL im Browser, geben Sie den Code ein, bestätigen Sie, dass das ausgewählte Konto Ihr dediziertes Lernkonto ist, und prüfen Sie vor der Autorisierung die angeforderten Berechtigungen. Hintergrundzugriff kann angezeigt werden, weil Wrangler auch nach Ihrer Rückkehr zum Terminal weiterarbeiten muss. Senden Sie niemals ein Passwort oder Token über das Terminal.

Kehren Sie zum Terminal zurück, nachdem der Browser den Erfolg gemeldet hat, und warten Sie, bis Wrangler fertig ist. Fordern Sie strukturierte Kontoinformationen an:

npx wrangler whoami --json

Bestätigen Sie loggedIn: true. Identifizieren Sie anschließend das vorgesehene Konto, auch wenn nur ein Konto angezeigt wird. Der Kontoname dient der menschlichen Kontrolle; die ID ist ein stabiler Konfigurationswert und muss nicht im Terminal ausgegeben werden.

Speichern Sie das strukturierte Ergebnis, zeigen Sie nur den nicht vertraulichen Kontonamen an und wählen Sie die passende ID für LabEx Learning aus:

WHOAMI="$(npx wrangler whoami --json)"
printf '%s\n' "$WHOAMI" | jq '{loggedIn, authType, accounts: [.accounts[] | {name}]}'
ACCOUNT_ID="$(printf '%s\n' "$WHOAMI" | jq -r '.accounts[] | select(.name == "LabEx Learning") | .id')"
test -n "$ACCOUNT_ID"

$(...) übernimmt die Befehlsausgabe in eine Shell-Variable. jq zeigt zunächst nur den Kontonamen zur Bestätigung an und wählt anschließend die zugehörige ID intern aus. test -n ist nur erfolgreich, wenn der ausgewählte Wert nicht leer ist. Wenn Ihr dediziertes Lernkonto einen anderen Anzeigenamen hat, ersetzen Sie LabEx Learning im Auswahl-Ausdruck durch den zuvor bestätigten Namen.

Generieren Sie einen eindeutigen Worker-Namen. openssl rand -hex 6 erzeugt 12 zufällige Hexadezimalzeichen, und $(...) fügt sie in die Shell-Variable ein:

RUN="labex-c10-o01-$(openssl rand -hex 6)"
printf '%s\n' "$RUN"

Erstellen Sie wrangler.jsonc. Eine Konfigurationsdatei teilt Wrangler mit, welchen Code es bereitstellen soll und welche Cloudflare-Funktionen die Laufzeit verwenden soll. Die nicht in Anführungszeichen gesetzte Markierung JSON ermöglicht die Expansion von $RUN und $ACCOUNT_ID, während der Backslash den Schlüssel $schema wörtlich erhält.

cat > wrangler.jsonc <<JSON
{
  "\$schema": "./node_modules/wrangler/config-schema.json",
  "name": "$RUN",
  "account_id": "$ACCOUNT_ID",
  "main": "src/index.js",
  "compatibility_date": "2026-09-18",
  "workers_dev": true,
  "preview_urls": false,
  "observability": {
    "enabled": true,
    "head_sampling_rate": 1
  },
  "durable_objects": {
    "bindings": [
      { "name": "COUNTERS", "class_name": "Counter" }
    ]
  },
  "exports": {
    "Counter": { "type": "durable-object", "storage": "sqlite" }
  }
}
JSON

Diese Datei beschreibt die Anwendung, erstellt aber noch nichts in Cloudflare. observability bewahrt Anfrage- und Anwendungsprotokolle für einen späteren Dashboard-Prüfpunkt auf. Die Felder für Durable Objects werden im nächsten Schritt relevant.

Namespace, Binding und Klasse verbinden

In diesem Schritt lesen Sie die Konfiguration der Durable Objects als Zuordnung dazu, wie eine Anfrage ein zustandsbehaftetes Objekt erreicht. Anschließend erzeugen Sie Laufzeittypen, die das Binding in Ihrem Code verfügbar machen.

Eine Durable-Object-Klasse ist der JavaScript-Bauplan für ein Objekt. Die Klasse Counter, die Sie später schreiben, definiert Vorgänge wie das Erhöhen und Auslesen eines Werts.

Ein Namespace ist die Sammlung aller Objekte, die von dieser Klasse unterstützt werden. Ein Namespace kann support, billing und viele weitere benannte Zähler enthalten. Das bedeutet nicht, dass diese Zähler denselben Wert teilen. Jede stabile Objektidentität besitzt einen eigenen Speicher.

Ein Binding ist der Name, den der vorgeschaltete Worker für den Zugriff auf diesen Namespace verwendet. Diese Konfiguration bindet den Namen COUNTERS an die Klasse Counter. Ihr Code verwendet daher env.COUNTERS.

Der Eintrag exports deklariert den aktuellen Lebenszyklusstatus der Klasse. Er teilt Cloudflare mit, dass Counter bei der ersten Bereitstellung mit dem SQLite-Speicher-Backend erstellt werden soll. SQLite ist das empfohlene Backend für neue Klassen und in Workers Free verfügbar. Die kleine Tabelle in diesem Lab speichert in jedem Objekt nur eine Ganzzahl.

Erzeugen Sie aus der Konfiguration eine Typbeschreibung:

npx wrangler types

Suchen Sie in der generierten Datei nach COUNTERS:

grep -n 'COUNTERS' worker-configuration.d.ts

Die Zeile ähnelt folgendem Inhalt:

COUNTERS: DurableObjectNamespace<import("./src/index").Counter>;

Der genaue umgebende generierte Text kann sich ändern. Wichtig sind jedoch drei Fakten: Das Binding heißt COUNTERS, es ist ein DurableObjectNamespace, und es verweist auf die exportierte Klasse Counter. Erzeugen Sie die Typen immer dann neu, wenn sich ein Binding ändert, damit Konfiguration und Code nicht unbemerkt auseinanderlaufen.

Benannten Zähler erstellen

In diesem Schritt implementieren Sie die Klasse Counter und den vorgeschalteten Worker, der einen validierten URL-Namen an ein Objekt weiterleitet.

Jedes Durable Object besitzt privaten Speicher. Der Konstruktor erstellt eine Tabelle mit einer Zeile namens counter_state und fügt den Anfangswert nur dann ein, wenn die Zeile noch nicht vorhanden ist. blockConcurrencyWhile() verzögert Objektanfragen, bis diese kurze Initialisierung abgeschlossen ist. Die Methode eignet sich für die Einrichtung des Schemas. Sie sollte jedoch nicht jede Anfrage oder externe Netzwerkoperation umschließen.

Die öffentlichen Methoden increment() und getCount() sind RPC-Methoden. RPC steht für Remote Procedure Call und ermöglicht es dem Worker, eine Methode eines Durable-Object-Stubs so aufzurufen, als wäre dieser ein asynchrones JavaScript-Objekt. Cloudflare leitet den Aufruf an das ausgewählte Objekt weiter.

Erstellen Sie den Worker-Einstiegspunkt:

cat > src/index.js <<'JS'
import { DurableObject } from "cloudflare:workers";

export class Counter extends DurableObject {
  constructor(ctx, env) {
    super(ctx, env);
    ctx.blockConcurrencyWhile(async () => {
      this.ctx.storage.sql.exec(`
        CREATE TABLE IF NOT EXISTS counter_state (
          key INTEGER PRIMARY KEY CHECK (key = 1),
          value INTEGER NOT NULL
        )
      `);
      this.ctx.storage.sql.exec(
        "INSERT OR IGNORE INTO counter_state (key, value) VALUES (1, 0)"
      );
    });
  }

  increment() {
    return this.ctx.storage.sql
      .exec("UPDATE counter_state SET value = value + 1 WHERE key = 1 RETURNING value")
      .one().value;
  }

  getCount() {
    return this.ctx.storage.sql
      .exec("SELECT value FROM counter_state WHERE key = 1")
      .one().value;
  }
}

function json(data, status = 200) {
  return Response.json(data, { status });
}

function counterName(pathname) {
  const match = pathname.match(/^\/counters\/([^/]+)$/);
  if (!match) return { error: "not_found", status: 404 };

  let name;
  try {
    name = decodeURIComponent(match[1]);
  } catch {
    return { error: "invalid_counter_name", status: 400 };
  }

  if (!/^[a-z][a-z0-9-]{0,31}$/.test(name)) {
    return { error: "invalid_counter_name", status: 400 };
  }
  return { name };
}

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    if (request.method === "GET" && url.pathname === "/health") {
      return json({ status: "ok" });
    }

    const parsed = counterName(url.pathname);
    if (parsed.error) return json({ error: parsed.error }, parsed.status);
    if (request.method !== "GET" && request.method !== "POST") {
      return json({ error: "method_not_allowed" }, 405);
    }

    const name = parsed.name;
    const stub = env.COUNTERS.getByName(name);
    const count = request.method === "POST"
      ? await stub.increment()
      : await stub.getCount();

    console.log(JSON.stringify({
      event: request.method === "POST" ? "counter_incremented" : "counter_read",
      name,
      count
    }));
    return json({ name, count });
  }
};
JS

Die Weiterleitungszeile getByName(name) bildet die Identitätsgrenze. Derselbe validierte Text wählt deterministisch dasselbe logische Objekt aus; ein anderer Text wählt ein anderes Objekt aus. Der Stub ist lediglich eine Referenz. Das Objekt wird verzögert erstellt, sobald ein RPC-Aufruf es tatsächlich erreicht.

Führen Sie die bereitgestellten deterministischen Tests aus. Sie verwenden ein kleines lokales Namespace-Fixture und senden daher keine Cloud-Anfrage:

NODE_NO_WARNINGS=1 node --experimental-loader ./test/cloudflare-loader.mjs --test test/worker.test.mjs

Der kleine Loader stellt lediglich eine lokale Ersatzimplementierung für die Basisklasse cloudflare:workers bereit, damit Node das Modul importieren kann. Das Namespace-Fixture steuert weiterhin jeden getesteten Aufruf, und es wird keine Cloudflare-API kontaktiert. Erwartet werden drei erfolgreiche Tests. Bitten Sie Wrangler anschließend, den Worker zu erstellen, ohne ihn bereitzustellen:

npx wrangler deploy --dry-run

Die Tests weisen den HTTP-Weiterleitungsvertrag nach, und der Probelauf zeigt, dass Wrangler die echte Durable-Object-Klasse bündeln kann. Keine der beiden Aktionen erstellt einen Namespace in der Cloud.

Stabile Namen lokal nachweisen

In diesem Schritt führen Sie die Anwendung in der lokalen Workers-Laufzeit aus und verwenden zwei Namen, um die Weiterleitungsregel zu beobachten, bevor Sie eine Cloud-Ressource erstellen.

Starten Sie Wrangler im Hintergrund auf Port 8787. > speichert Protokolle, 2>&1 führt Fehlerausgaben mit der normalen Ausgabe zusammen, und & gibt die Terminal-Eingabeaufforderung zurück. $! ist die Prozess-ID des gerade gestarteten Befehls.

npx wrangler dev --port 8787 > .labex/dev.log 2>&1 &
echo $! > .labex/dev.pid

Warten Sie auf die Health-Route. Die Schleife versucht es einmal pro Sekunde und endet, sobald der Worker antwortet:

for attempt in $(seq 1 30); do
  if curl --silent --fail http://127.0.0.1:8787/health; then
    break
  fi
  sleep 1
done

Erwartet wird {"status":"ok"}. Erhöhen Sie den Zähler support zweimal:

curl --silent --request POST http://127.0.0.1:8787/counters/support | jq
curl --silent --request POST http://127.0.0.1:8787/counters/support | jq

Die Antworten zeigen, dass support von 1 auf 2 steigt:

{
  "name": "support",
  "count": 2
}

Erhöhen Sie nun billing einmal:

curl --silent --request POST http://127.0.0.1:8787/counters/billing | jq

Der Wert beträgt 1, nicht 3. Ein Namespace ist eine Sammlung, während jeder Name ein isoliertes Objekt innerhalb dieser Sammlung auswählt.

Lesen Sie beide Objekte aus, ohne sie zu ändern:

curl --silent http://127.0.0.1:8787/counters/support | jq
curl --silent http://127.0.0.1:8787/counters/billing | jq

Die Werte bleiben 2 und 1. Weisen Sie abschließend nach, dass ungültige Eingaben abgewiesen werden, bevor getByName() ein Objekt auswählen kann:

curl --silent --request POST --write-out '\nHTTP %{http_code}\n' \
  http://127.0.0.1:8787/counters/Not_Allowed

Erwartet werden {"error":"invalid_counter_name"} und HTTP 400. Der Unterstrich und die Großbuchstaben verstoßen gegen die dokumentierte Namensregel.

Namespace bereitstellen und untersuchen

In diesem Schritt beenden Sie die lokale Laufzeit, stellen dieselbe Anwendung in Cloudflare bereit und verknüpfen das API-Verhalten mit dem Namespace, dem Binding, den Metriken und den im Dashboard sichtbaren Protokollen.

Beenden Sie nur den Entwicklungsprozess, dessen ID Sie gespeichert haben:

kill "$(cat .labex/dev.pid)"
wait "$(cat .labex/dev.pid)" 2>/dev/null || true

Stellen Sie den Worker und seine deklarierte SQLite-basierte Klasse Counter bereit:

npx wrangler deploy

Wrangler gibt eine öffentliche workers.dev-URL und ein Ergebnis der Klassenabstimmung aus. Speichern Sie die exakte URL, indem Sie den Beispielwert ersetzen:

WORKER_URL="https://YOUR_WORKER_URL"

Es kann kurze Zeit dauern, bis die Edge-Route bereit ist. Fragen Sie ausschließlich die Health-Route ab, die kein Durable Object berührt:

for attempt in $(seq 1 30); do
  if curl --silent --fail "$WORKER_URL/health"; then
    break
  fi
  sleep 2
done

Erstellen Sie zwei Anfragen für support und eine für billing:

curl --silent --request POST "$WORKER_URL/counters/support" | jq
curl --silent --request POST "$WORKER_URL/counters/support" | jq
curl --silent --request POST "$WORKER_URL/counters/billing" | jq

Lesen Sie die Werte aus:

curl --silent "$WORKER_URL/counters/support" | jq
curl --silent "$WORKER_URL/counters/billing" | jq

Die entfernte Anwendung muss denselben Identitätsvertrag wie die lokale Laufzeit zeigen: support ist 2, während billing 1 ist.

Öffnen Sie Workers & Pages im Cloudflare-Dashboard. Ihr eindeutig benannter Worker erscheint in der Anwendungsliste. Der Worker-Name, die Zeitstempel und die kontoweiten Nutzungswerte im folgenden Screenshot sind Beispiele aus dem getesteten Lauf. Suchen Sie den Namen labex-c10-o01-..., der in Ihrem eigenen Terminal erzeugt wurde.

Öffnen Sie das Cloudflare-Dashboard und gehen Sie zu Workers & Pages → Overview → Ihr labex-c10-o01-...-Worker → Settings → Bindings. Suchen Sie das Durable-Object-Binding mit dem Namen COUNTERS und seine Klasse Counter. Der Worker kennt den Binding-Namen; Cloudflare verbindet ihn mit dem Namespace, der durch den Klassenexport deklariert wird.

Das Binding-Diagramm sollte zeigen, dass der Worker über COUNTERS mit einem Durable Object verbunden ist. Die Worker- und Namespace-Namen im Screenshot beziehen sich auf den jeweiligen Testlauf und sind nur Beispiele. Entscheidend sind der Binding-Name und die dargestellte Beziehung.

Öffnen Sie als Nächstes Durable Objects in der Navigation der Developer Platform. Wählen Sie den Namespace aus, der Ihrem kurzlebigen Worker gehört. Bestätigen Sie, dass er den SQLite-Speicher verwendet und dass die Klasse Counter heißt. Ein Namespace ist die Sammlung auf Klassenebene; die Namen support und billing identifizieren Objekte innerhalb dieser Sammlung.

Die Namespace-Übersicht zeigt Storage: SQL. Der Namespace-Name und die ID gehören zum kurzlebigen Testlauf und unterscheiden sich bei Ihnen.

Öffnen Sie die Ansicht Metrics des Namespace. Es kann dauern, bis aktuelle Anfragen angezeigt werden. Ein vorübergehend leeres Diagramm ist daher nicht aussagekräftig. Erzeugen Sie keine große Anfrageschleife, um ein Diagramm zu erzwingen.

Der Beispiel-Screenshot des Namespace meldet weiterhin null aktuelle Aufrufe, obwohl die Laufzeitanfragen erfolgreich waren. Das zeigt, warum verzögerte Dashboard-Metriken nur unterstützenden Kontext liefern und nicht die maßgebliche Funktionsprüfung sind.

Kehren Sie zum Worker zurück und öffnen Sie Observability → Logs. Suchen Sie ein aktuelles Ereignis counter_incremented oder counter_read. Das strukturierte Protokoll enthält den künstlichen Zählernamen und den Zählerstand, jedoch keine Konto-ID oder Zugangsdaten. Ordnen Sie es einer der oben ausgeführten begrenzten Anfragen zu.

Klappen Sie ein passendes Ereignis auf. Im getesteten Lauf endete ein vom Prüfer erzeugter Name beim Zählerstand 2, während das Ereignisdiagramm erfolgreiche Anfragen und null Fehler meldete. Ihr künstlicher Name und Ihre Gesamtwerte werden abweichen.

Dashboard-Werte wie Worker-Namen, Objekt-IDs, Zeitstempel und Anfragezahlen sind spezifisch für Ihren Lauf. CLI-, API- und Laufzeitprüfungen bleiben die maßgeblichen Nachweise. Die Dashboard-Ansichten zeigen, an welcher Stelle dieselben Beziehungen sichtbar sind.

Namespace entfernen und abmelden

In diesem Schritt setzen Sie die Klasse Counter absichtlich außer Betrieb, löschen ihren Namespace und die gespeicherten Daten, entfernen den Worker und widerrufen anschließend die Wrangler-Sitzung dieser VM.

Das alleinige Löschen eines Worker-Skripts ist keine eindeutige Erklärung dafür, dass gespeicherte Durable-Object-Daten verschwinden sollen. Der Lebenszyklus über exports verwendet einen gelöschten Tombstone: einen kurzlebigen Konfigurationseintrag, der Cloudflare anweist, einen Klassen-Namespace dauerhaft zu löschen. Für diesen Vorgang gibt es keinen Papierkorb. Vergewissern Sie sich daher, dass Klasse und Worker-Name zu diesem Lab gehören.

Erstellen Sie einen minimalen Cleanup-Einstiegspunkt ohne Counter-Export:

cat > src/cleanup.js <<'JS'
export default {
  fetch() {
    return Response.json({ status: "cleanup" }, { status: 410 });
  }
};
JS

Erstellen Sie eine Cleanup-Konfiguration. Sie behält denselben Worker-Namen und dasselbe Konto bei, entfernt das Binding und markiert ausschließlich Counter als gelöscht:

ACCOUNT_ID="$(node -e 'console.log(JSON.parse(require("fs").readFileSync("wrangler.jsonc", "utf8")).account_id)')"
cat > wrangler.cleanup.jsonc <<JSON
{
  "\$schema": "./node_modules/wrangler/config-schema.json",
  "name": "$RUN",
  "account_id": "$ACCOUNT_ID",
  "main": "src/cleanup.js",
  "compatibility_date": "2026-09-18",
  "workers_dev": true,
  "preview_urls": false,
  "exports": {
    "Counter": { "type": "durable-object", "state": "deleted" }
  }
}
JSON

Stellen Sie den Tombstone bereit:

npx wrangler deploy --config wrangler.cleanup.jsonc

Lesen Sie die Abstimmungsausgabe von Wrangler sorgfältig. Sie sollte melden, dass Counter gelöscht wurde. Dadurch werden der Klassen-Namespace und die kleinen Werte, die von support, billing und dem unabhängigen Prüfer gespeichert wurden, dauerhaft entfernt.

Löschen Sie nun den verbleibenden zustandslosen Cleanup-Worker:

npx wrangler delete --config wrangler.cleanup.jsonc

Bestätigen Sie ausschließlich die Anwendung mit dem exakten Namen labex-c10-o01-.... Prüfen Sie im Dashboard, dass genau dieser Worker nicht mehr vorhanden ist und der zugehörige Namespace ebenfalls nicht mehr angezeigt wird. Historische Metriken oder Protokolle können vorübergehend bestehen bleiben und sind keine aktiven Ressourcen.

Führen Sie die authentifizierte Löschprüfung aus, bevor Sie die Autorisierung entfernen:

python3 .labex/verify.py deleted

Melden Sie sich erst ab, nachdem PASS: deleted ausgegeben wurde:

npx wrangler logout

npx wrangler whoami --json

Die abschließende Ausgabe muss ausdrücklich loggedIn: false melden. Ein Netzwerkfehler ist kein Beweis dafür, dass die Abmeldung erfolgreich war.

Zusammenfassung

Sie haben Ihre erste Anwendung mit Durable Objects erstellt und betrieben. Sie haben gelernt, dass eine Klasse das Verhalten eines Objekts definiert, ein Namespace Objekte dieser Klasse gruppiert, ein Binding den Namespace für einen Worker verfügbar macht und getByName() deterministisch ein logisches Objekt auswählt. RPC-Methoden haben den SQLite-basierten Zustand verändert und ausgelesen. Wiederholte Namen teilten sich einen Zählerstand, verschiedene Namen blieben isoliert, und ungültige Namen wurden vor der Objektauswahl abgewiesen.

Außerdem haben Sie das Laufzeitverhalten mit dem Cloudflare-Dashboard verknüpft. Anschließend haben Sie mithilfe eines deklarativen Klassen-Tombstones den Namespace und seine Daten entfernt, bevor Sie den Worker gelöscht und sich abgemeldet haben. Im nächsten Lab bauen Sie auf diesem Identitätsmodell auf, indem Sie SQLite als Aktivitätsprotokoll verwenden und zeigen, warum dauerhafter Speicher sich von temporärem Speicher im Arbeitsspeicher unterscheidet.