AWS WebSocket unterstützt Serverless-Echtzeit-Funktionen

WebSockets versus HTTP-Verbindungen

Im Gegensatz zu HTTP-Endpunkten sind WebSockets zustandsorientiert (stateful). WebSocket-APIs bilden persistente Verbindungen. Traditionelle HTTP-Verbindungen trennen eine Verbindung zum Browser, nachdem sie den Inhalt zurückgegeben haben. WebSocket-APIs erfordern keine wiederholte Verbindungslogik, und sowohl der Client als auch der Server haben nach der Verbindung weniger Overhead als bei HTTP-Verbindungen.

HTTP-Polling ist eine Technik, mit der eine Anwendung Informationen basierend auf einem Client abrufen kann, der Daten anfordert. Im Gegensatz dazu ermöglichen WebSocket-APIs dem Server, Inhalte in Echtzeit an den Browser zu übertragen. WebSockets umgehen auch das Problem der Zeitüberschreitung bei Verbindungen nach 30 Sekunden, da sie Daten nach dem Herstellen der Verbindung zum Client jederzeit asynchron zurücksenden können.

Wenn WebSockets nicht passen

Man sollte WebSockets für Always-on-Geräte in Betracht ziehen. Allerdings ist zu beachten, dass die Technologie Probleme bei Systemen verursachen kann, die keinen Always-connected Client benötigen.

WebSockets eignen sich hervorragend für Anwendungen, die auf Echtzeitdaten basieren. Dies kann zum Beispiel eine Chat-Funktion sein, von der Benutzer erwarten, dass sie sich sofort aktualisiert – und zwar unabhängig davon, wie viele neue Einträge auftreten. Sie eignen sich auch für Anwendungen, die auf datenintensive Workflows angewiesen sind, bei denen der Client eine stabile Verbindung braucht. Chat-Anwendungen, Analytics-Applikationen und Big-Data-Analyse-Anwendungen verlassen sich nicht auf eine typische Request-/Response-Ressource, sondern können asynchron arbeiten.

Diese WebSocket-Interaktionen sind jedoch nicht auf die Bedürfnisse von Blogs, einfachen E-Commerce-Seiten oder anderen Anwendungen zugeschnitten, die zumeist semi-statische Informationen bereitstellen.

WebSockets sind eine großartige Ergänzung zu Single-Page-Anwendungsfunktionen auf AWS. Aber der Cloud-Provider kann eine WebSocket-API-Anwendung nicht ganz allein bedienen. Stattdessen bietet die Technologie eine Möglichkeit, eine API für eine Client-Anwendung zu liefern, die über ein statisches Content Delivery Network (CDN) bereitgestellt wird und sich auf Dienste wie S3 oder CloudFront stützt.

Erste Schritte mit AWS WebSockets auf API Gateway

Entwickler sollten sich Amazon API Gateway mit WebSockets eher wie einen Alexa-Skill statt eines HTTP-Endpunkts vorstellen. Der AWS WebSocket Support ermöglicht es Entwicklern, konzeptionelle Routen einzurichten – ähnlich wie Alexa Intents. Diese matchen bestimmte Eingaben, sowie eine Standardroute, die das WebSocket ausführt, wenn kein anderes Muster passt.

Typischerweise sind WebSockets als ein JSON Data String Request strukturiert, der eine Aktion erhält, sowie andere Daten, die an die Serverless-Lambda-Funktion weitergegeben werden sollen. Wenn ein Entwickler zum Beispiel alle Benutzer mit E-Mail-Support auflisten muss, kann die Anwendung Folgendes verwenden:

{ "action": "ListUsers", "data": { "email": "support" } }

Entwickler können hier jedes grundlegende Nachrichtenmuster verwenden, sollten aber etwas standardmäßiges wie zum Beispiel action wählen, um die Dinge für alle anderen, die mit dem Code arbeiten, leicht verständlich zu machen. Entwickler können den Ausdruck für die Routenauswahl angeben, wenn sie ein API Gateway mit einer WebSocket-API erstellen. In diesem Fall handelt es sich um die Standardaktion $request.body.action.

AWS WebSocket Standardrouten

Alle API Gateway WebSocket-Verbindungen haben drei Standardrouten. Sie beginnen alle mit einem Dollarzeichen ($):

1. $connect wird ausgelöst, wenn sich ein neuer Client verbindet.

2. $disconnect wird ausgelöst, wenn ein Websocket-Client die Verbindung trennt.

3. $default wird als Fallback ausgelöst, wenn keine bestimmte action-Route zugeordnet ist.

Entwickler sollten immer den $default-Handler implementieren. Für die meisten Anwendungen kann die Einrichtung etwa so einfach sein, dass sie anzeigt, dass der Befehl nicht verstanden wurde und der Client, der sich verbindet, nicht auf eine Antwort wartet, die niemals eintrifft.

Da WebSocket Requests asynchron sind, kann ein Client mehrere Requests senden, bevor er eine Antwort erhält. Der Entwickler muss daher eine Methode einrichten, um den Client darüber zu informieren, ob eine Anforderung niemals eine Antwort erhalten wird.

Request-IDs hinzufügen

Es besteht auch keine direkte Request/Response-Beziehung zu asynchronen WebSocket Requests. Da Clients mehrere Requests gleichzeitig senden können, setzt man WebSockets mit Request-IDs. Damit kann der Client jede Antwort mit der Anfrage, die er gesendet hat, abgleichen. Zum Beispiel kann eine Anfrage zur Suche nach Stories mit darin enthaltenem API Gateway so aussehen:

{
    "request_id": 1,
    "action": "SearchStories",
    "query": "API Gateway"
}

Die Antwort sollte alle relevanten Informationen enthalten, die der Kunde wissen muss:

{
    "request_id": 1,
    "action": "SearchStories",
    "query": "API Gateway",
    "results": [
         {
             "$type": "Story",
             "id": "2019-02-12-01",
             "title": "API Gateway Websockets"
         },
         {
             "$type": "Story",
             "id": "2019-02-12-02",
             "title": "API Gateway with Lambda functions"
         },
         …
    ]
} 

Alternativ lässt sich eine WebSocket-API so einrichten, dass die Ergebnisse so gestreamt werden, wie sie gefunden werden, so dass mehrere Ergebnisse zurückgegeben werden, die jeweils auf einem eigenen Objekt liegen:

{
    "request_id": 1,
    "result": {
         "$type": "Story",
         "id": "2019-02-12-01",
         "title": "API Gateway Websockets"
    }
}
{
    "request_id": 1,
    "result": {
         "$type": "Story",
         "id": "2019-02-12-02",
         "title": "API Gateway with Lambda functions"
    }
}

Der Client kann die Ergebnisse beim Streaming schneller anzeigen, da das System nicht alle Ergebnisse abrufen muss, bevor eine Antwort zurückkommt.

Wie WebSockets Ergebnisse an den Client weiterleiten

Wenn es um einen Vergleich von WebSockets mit HTTP geht, ist der größte Vorteil von WebSockets, dass Backend-Server Inhalte an Clients weiterleiten können, sobald die Server diese haben. Der Client muss nicht nach neuen Ergebnissen für einen bestimmten Request suchen.

Wenn zum Beispiel ein Benutzer Statistiken zu einer E-Mail-Kampagne sucht, kann WebSockets die Ergebnisse live an den Browser des Benutzers übertragen, sobald Kunden die E-Mail-Nachrichten öffnen. Der Benutzer muss nicht erst umständlich auf Aktualisieren klicken – oder ein automatisches Aktualisierungsintervall konfigurieren – um sich aktualisierte Statistiken anzeigen zu lassen. Anwendungen führen diesen Echtzeit-Stream mit WebSockets über einen PUB/SUB-Ansatz (Publish and Subscribe) durch.

Um PUB/SUB einzurichten, lässt man den Client eine bestimmte Anforderung abonnieren, zum Beispiel die Überwachung einer E-Mail-Kampagne:

{ "action": "subscribe", "id": "stats/email-campaign/1" }

Die Backend-Funktion sollte dann den Connection Handler aus der WebSocket-Verbindung registrieren, die häufig in einer DynamoDB-Datenbank oder einem ähnlichen Dienst gespeichert ist. Wenn die Anwendung ein neues Ereignis empfängt – ein E-Mail-Empfänger zum Beispiel eine E-Mail anklickt oder öffnet – überprüft die Backend-Komponente die entsprechende DynamoDB-Tabelle und gibt die Informationen an alle Verbindungs-IDs weiter, die dieser bestimmten Themen-ID zugeordnet sind.

Diese PUB/SUB-Interaktion ähnelt der Funktionsweise des Amazon Simple Notification Service (SNS). Allerdings ist es derzeit nicht möglich, eine Verbindungs-ID direkt mit SNS zu registrieren, um Nachrichten über AWS WebSockets zu veröffentlichen. Die Integration in Amazon SNS erscheint jedoch wie ein logischer nächster Schritt für API Gateway und WebSockets.