Neue Wege für die Erstellung von Inhalten auf der Edge mit Compute
Die meisten Inhalte, die über Fastly bereitgestellt werden, werden auf den Servern unserer Kunden erzeugt. Das muss aber nicht zwangsläufig so sein. Es war schon immer möglich, Inhalte programmatisch zu generieren. Aber mit der Einführung von Compute, das zum Erstellen, Testen und Bereitstellen von Code in unserer Serverless-Compute-Umgebung verwendet wird, lassen sich Inhalte jetzt noch effizienter und leistungsstärker entwickeln und transformieren als je zuvor.
Traditionell sitzt ein Content Delivery Network (CDN) zwischen Ihren Webservern und Ihren Endnutzern und speichert Ihre Inhalte im Cache, sodass sie schneller als vom Origin-Server abgerufen werden können. Das gilt insbesondere für Nutzer, die physisch weit von Ihren Servern entfernt sind. Dies ist eine wesentliche Voraussetzung für die meisten modernen Websites, die performant und skalierbar sein sollen.
Wenn also ein CDN vor Ihrer Website unverzichtbar ist, ist es eine Schande, die gesammelten Inhalte nach wie vor an einem einzigen Ort zu generieren. Denn wenn Sie ein so leistungsstarkes Tool für die Verarbeitung von Anfragen haben, das so nah am Endnutzer sitzt, warum sollten Sie es nicht zu einem integralen Bestandteil Ihrer Infrastruktur machen?
Erste Schritte: Robots, Redirects und CORS
CORS oder Cross-Origin Resource Sharing ist ein großartiges Beispiel für etwas, wofür die Edge geradezu ideal ist. Bei der Anforderung von originübergreifenden Ressourcen müssen Browser vor dem Start möglicherweise eine OPTIONS-Request ausgeben, um zu überprüfen, ob der Ziel-Host bereit ist, die Anfrage zu bedienen. Bei der Antwort auf diese Anfrage muss der Name des Origin-Servers, der die Anfrage stellt, angegeben werden. Es handelt sich also nicht um einen völlig statischen Inhalt, aber um einen, der sich leicht auf der Edge generieren lässt – egal, ob auf Compute oder in VCL. Klicken Sie in der nachstehenden Abbildung auf RUN, um dies auf einem Fastly VCL-Service auszuprobieren:
Einfache synthetische Antworten wie diese können alle Arten von Use Cases abdecken. Ein weiterer häufiger Anwendungsfall sind Redirects, ob HTTP zu HTTPS, die Normalisierung eines Hostnamens (z. B. das Hinzufügen (oder Entfernen) von www. zu einer Apex-Domain) oder das Mapping alter auf neue Pfade.
Die Durchführung von Redirects auf der Edge ist eine großartige Möglichkeit, Ihren Origin-Server zu entlasten und gleichzeitig die Performance für Ihre Endnutzer erheblich zu verbessern.
Natürlich können synthetische Antworten auch Body-Inhalte umfassen. In einer Microservice-Architektur wissen Sie möglicherweise nicht, von wo aus Sie Dateien wie robots.txt bereitstellen sollen. Also warum nicht einfach von der Edge?
Das nächste Level: Von der Edge aus bereitgestellte APIs und Beacon-Terminierung
Fastly wird oft als API-Gateway verwendet (und darin sind wir besonders gut). Aber haben Sie schon einmal darüber nachgedacht, API-Antworten auf der Edge auszuliefern, ohne sie an den Origin-Server weiterleiten zu müssen? Dies ist besonders nützlich, wenn Sie Clients Zugriff auf Informationen wie Geolocation-Daten geben wollen, die bereits innerhalb von Fastly verfügbar sind. Versuchen Sie es in VCL:
Fastly versorgt Ihre Enge-Anwendungen automatisch mit einer Fülle an Informationen. Mit Edge Dictionaries können Sie aber auch Ihre eigenen Key-Value-Datensätze hinzufügen.
Und wo wir gerade bei APIs sind: Wir haben bereits ausführlich über die Terminierung von Beacons auf der Edge gesprochen. Es gibt also keinen Grund, Ihre eigenen Server mit all den Daten zu bombardieren, die Sie von Clients sammeln, um Ihre Performance und das Nutzererlebnis zu messen. Mithilfe unseres Log Streaming in Echtzeit (eine meiner persönlichen Lieblingsfunktionen von Fastly) können Sie die eingehenden Daten bereinigen, validieren, anreichern und verdichten und sie anschließend direkt von Fastly an S3, Google Cloud Storage, BigQuery, Splunk oder sogar an Ihre eigenen Collector-Server senden.
Maximaler Nutzen: Vollständiges Templating komplexer Seiten auf der Edge
So weit, so gut. Alle diese Lösungen sind seit Jahren erfolgreich auf den Websites unserer Kunden im Einsatz und lassen sich jetzt sowohl in VCL als auch in Compute realisieren. Eine Sache, die VCL aber noch nie konnte, ist das Zusammenstellen eines Response-Bodys durch die Verarbeitung von Upstream-API-Daten. Aber wäre es denn nicht unglaublich stark, wenn Sie Daten effizient aus mehreren Quellen parallel abfragen und laden könnten – einschließlich Daten, die möglicherweise im Cache verfügbar sind –, um anschließend HTML-Seiten unter Verwendung von auf der Edge gespeicherten Templates zu generieren?
Weniger Origin Traffic. Leichteres Debugging und Trennung von Belangen. Schnellere Performance für Ihre Endnutzer. Dies ist nichts anderes als die Verlagerung des gesamten View-Layers Ihrer Anwendung auf die Edge.
Mein Kollege Kailan Blanks hat unserem Developer Hub kürzlich ein Tutorial hinzugefügt, in dem er Schritt für Schritt erklärt, wie man dies mit einer Wetter-App unter Verwendung von Rust auf Compute machen kann. Hier ist die fertige App, die in einem Frame auf dieser Seite läuft:
Dies ist eines meiner Lieblingsbeispiele, weil es anschaulich zeigt, welche Bausteine für die Erstellung großer Anwendungen auf der Edge notwendig sind:
Plattform-Funktionen: Wir verwenden die Geolocation-API von Fastly um herauszufinden, wo sich ein Endnutzer in der Welt befindet, und ein Edge Dictionary, um dynamische Konfigurationen zu speichern.
API-Anfragen an den Origin: Wir senden Anfragen an Openweathermap über den Fastly Edge Cache mithilfe der send()-Methode unserer Request-Struktur im Rust SDK.
Community-Bibliotheken: Wir parsen API-Antworten von Openweathermap mit serde_json und erstellen damit ansprechende HTML-Seiten mit tinytemplate. Sie können dafür alle Module oder Bibliotheken verwenden, die sich nach WebAssembly kompilieren lassen.
In vielen Fällen, in denen Inhalte als „nicht zwischenspeicherbar“ gelten, liegt das daran, dass sie aus vielen verschiedenen Datenbits zusammengesetzt sind, die miteinander kombiniert werden. Eine fertige HTML-Seite könnte beispielsweise den Namen des aktuellen Nutzers, einen Artikel auf der Grundlage der URL und Links auf Basis des Landes, aus dem die Seite angefordert wird, enthalten.
Der Vary-Header bietet einen leistungsstarken Mechanismus, der die verschiedenartigen Variationen eines cachefähigen Objekts getrennt hält. Es kann aber ein Punkt kommen, an dem es zu viele Variationen gibt, um diese Methode anwenden zu können. Und genau dann erweist sich das Templating direkt auf der Edge als besonders nützlich! Jedes einzelne Element der Daten, die in den Seitenaufbau einfließen, kann separat gecacht werden. Dynamische Seiten können durch das Zusammenfügen aller passenden Teilinhalte zusammengestellt werden.
Vor einigen Monaten habe ich einen Post über neue Denkansätze für das Design von „edgenativen“ Anwendungen geschrieben, aber das Verschieben von Templates auf die Edge ist wahrscheinlich einfacher als Sie denken. Warum wählen Sie nicht einmal eine Seite aus, bei der Sie Ihre Performance verbessern möchten, und probieren es einfach aus?
