Einführung der Workers Cache API: Sie steuern selbst, wie Ihre Inhalte zwischengespeichert werden

Bei Cloudflare wollen wir das Internet für alle schneller und sicherer machen. Eine Möglichkeit dafür ist Caching: Wir bewahren Kopien der Inhalte unserer Kunden in unseren 165 Rechenzentren auf der ganzen Welt auf. Dadurch sind die Inhalte näher bei den Nutzern und die Zugriffe auf die Ursprungsserver werden reduziert.

Wir freuen uns, heute eine große Änderung in der Funktionsweise unseres Cache bekannt geben zu können. Cloudflare Workers integriert nun die Cache-API, was Ihnen die programmatische Kontrolle über unsere Caches auf der ganzen Welt verschafft.

Es kann kompliziert sein herauszufinden, was wo zwischengespeichert werden muss. Denken Sie beispielsweise an eine E-Commerce-Site mit einem Warenkorb, ein Content-Management-System (CMS) mit vielen Vorlagen und Hunderten von Artikeln oder eine GraphQL-API. Jede enthält eine Mischung von Elementen, die für einige Benutzer dynamisch sind, die aber für die überwiegende Mehrheit der Anfragen unverändert bleiben können.

In den letzten acht Jahren haben wir viele Funktionen hinzugefügt, um unseren Kunden Flexibilität und Kontrolle darüber zu geben, was in den Cache gelangt. Wir haben jedoch gelernt, dass wir mehr bieten müssen, als nur Einstellungsmöglichkeiten in unserem Dashboard hinzuzufügen. Unsere Kunden haben uns klar gesagt, dass sie ihre Ideen in Code umsetzen wollen, um Dinge zu bauen, die wir uns nie hätten vorstellen können.

Das Abrufen von Inhalten ist eine der häufigsten Aufgaben des Workers. fetch() hat schon immer leistungsstarke Cloudflare-Funktionen wie Argo und Load Balancing genutzt. Es läuft auch durch unseren Cache: Wir suchen lokal nach Inhalten, bevor wir uns mit dem Internet verbinden. Ohne die Cache-API geht der mit fetch() angeforderte Inhalt so in den Cache, wie er ist.

fetch() wird nach einem Miss immer in den Cache zurückschreiben.

Die Cache-API ändert das alles. Sie basiert auf der Service Workers Cache API und bietet im Wesentlichen drei Methoden:

• put(request, response) stellt eine Antwort in den Cache, geschlüsselt durch eine Anfrage

• match(request) gibt eine gegebene Antwort zurück, die zuvor mit put() in den Cache gestellt wurde

• delete(request) löscht eine Antwort, die zuvor mit put() in den Cache gestellt wurde

Mit der Cache-API können Sie Inhalte ändern, bevor sie in den Cache geschrieben werden.

Diese API birgt ein enormes Leistungspotential. Da Workers Ihnen die Möglichkeit gibt, Anfrage- und Antwortobjekte zu ändern, können Sie jedes Caching-Verhalten, z. B. TTL oder Cache-Tags, steuern. Sie können kundenspezifische Vary-Logik implementieren oder normalerweise nicht zwischengespeicherte Objekte wie POST-Anfragen zwischenspeichern.

Die Cache-API erwartet Anfragen und Antworten, diese müssen aber nicht von externen Servern stammen. Ihr Worker kann beliebige Daten erzeugen, die in unserem Cache gespeichert werden. Das bedeutet, dass Sie die Cache-API als universelle, flüchtige Schlüssel-Werte-Datenbank verwenden können!

Seit wir im September die Beta angekündigt haben, ist die Nutzung der Cache-API auf Tausende von Anfragen pro Sekunde angewachsen. Ein häufiger Anwendungsfall ist das Caching von POST-Anfragen.

Normalerweise betrachtet Cloudflare POST-Anfragen nicht als zwischenspeicherbar, da sie als nicht idempotent konzipiert sind, d. h. sie ändern ihren Status auf dem Server, wenn eine Anfrage gestellt wird. Anwendungen können jedoch POST-Anfragen auch verwenden, um große Datenmengen an den Server zu senden, oder als gemeinsame HTTP-Methode für API-Aufrufe.

Und das hatte ein Entwickler über die Verwendung der Cache-API zu sagen:

Wir mussten einige komplexe serverseitige Codes an die Edge migrieren. Wir haben einen API-Endpunkt, der POST-Anfragen mit großen Bodys akzeptiert, aber hauptsächlich die gleichen Daten zurückgibt, ohne etwas auf unserem Ursprungsserver zu ändern. Mit Workers und der Cache-API konnten wir Antworten auf POST-Anfragen zwischenspeichern, von denen wir wussten, dass sie sicher sind, und so die Belastung unseres Ursprungsservers erheblich reduzieren.

– Aaron Dearinger, Edge Architect, Garmin International

Das Zwischenspeichern von POST-Anfragen mit der Cache-API ist einfach. Hier etwas Beispielcode aus unserer Dokumentation:

async function handleRequest(event) {
  let request = event.request
  let response

  if (request.method == 'POST') {
    let body = await request.clone().text()
    let hash = await sha256(body)

    let url = new URL(request.url)
    url.pathname = "/posts" + url.pathname + hash

    // Convert to a GET to be able to cache
    let cacheKey = new Request(url, {
      headers: request.headers,
      method: 'GET'
    })

    let cache = caches.default
    // try to find the cache key in the cache
    response = await cache.match(cacheKey)

    // otherwise, fetch from origin
    if (!response) {
      // makes POST to the origin
      response = await fetch(request.url, newRequest)
      event.waitUntil(cache.put(cacheKey, response.clone()))
    }
  } else {
    response = await fetch(request) 
  }
  return response
}

async function sha256(message) {
  // encode as UTF-8
  const msgBuffer = new TextEncoder().encode(message)

  // hash the message
  const hashBuffer = await crypto.subtle.digest('SHA-256', msgBuffer)

  // convert ArrayBuffer to Array
  const hashArray = Array.from(new Uint8Array(hashBuffer))

  // convert bytes to hex string
  const hashHex =
    hashArray.map(b => ('00' + b.toString(16)).slice(-2)).join('')
  return hashHex
}

Bereits bei unserer Beta-Version haben wir gesehen, wie Kunden die Cache-API verwenden, um Teile von GraphQL-Abfragen dynamisch zwischenzuspeichern und Kundendaten zu speichern, um die Performance zu verbessern. Wir sind gespannt, welche Verwendung Sie finden werden! Schauen Sie sich den Erste-Schritte-Leitfaden für Cloudflare Workers und die Cache-API-Dokumentation an und lassen Sie uns im Workers Community Forum wissen, was Sie gebaut haben.