Skip to main content
Du siehst gerade die Entwicklerdokumentation
Diese Dokumentation richtet sich an Entwickler, die mit der Base44-Entwicklerplattform arbeiten.
Ein Actor ist ein langlaufender Backend-Prozess, mit dem sich mehrere Clients gleichzeitig verbinden. Mit Actors kannst du Live-Session-Instanzen bauen, die folgende Funktionen unterstützen:
  • Echtzeitnachrichten: Sende und empfange Nachrichten mit Clients über WebSockets.
  • Persistenter Speicher: Erhalte den Session-Zustand über Leerlaufphasen hinweg.
  • Geplante Arbeit: Führe Logik in einem festen Intervall oder zu einem bestimmten Zeitpunkt aus.
Verwende Actors für Funktionen, bei denen mehrere Clients Echtzeit-Updates und Interaktion brauchen, etwa einen Chatraum oder ein Multiplayer-Spiel.

​
Actors

Actor ist die Klasse, die du in deinem Backend erweiterst. Die Actor-Klasse definiert das Verhalten einer Live-Session. Mit Actors kannst du:
  • Verbindungen verwalten: Akzeptiere oder lehne einen Client ab, der sich mit der Session verbindet, und identifiziere, wer sich verbindet.
  • Nachrichten verarbeiten: Empfange eine Nachricht von einem Client, aktualisiere den Session-Zustand und antworte einem Client oder sende an alle.
  • Arbeit planen: Führe Logik in einem Intervall oder zu einem geplanten Zeitpunkt aus.

​
Sessions

Eine Session ist eine laufende Instanz eines Actors. Sie wird durch den Actor-Namen und eine von dir gewählte Session-ID identifiziert.
Jede Session verwaltet ihren eigenen Zustand, Speicher und ihre Client-Verbindungen unabhängig.

​
Verbindungen

Eine Verbindung steht für den WebSocket eines Clients zu einer Session. Jeder Client, der beitritt, erhält eine eigene Verbindung. Ein Actor nutzt diese Verbindung, um zu erkennen, wer sich verbindet, Client-Verbindungen zu verwalten und Nachrichten zu senden. Mehr dazu unter Verbindungen. Einen Beispielablauf findest du unter Client-Verbindungen verwalten.

​
Aktive und inaktive Sessions

Eine Session ist immer in einem der folgenden Zustände:
  • Aktiv: Die Session ist live und verarbeitet Ereignisse. Eine Session wird aktiv, wenn sich ein Client verbindet, wenn ein Client einer inaktiven Session eine Nachricht sendet oder wenn eine geplante Wake-Zeit erreicht ist.
  • Inaktiv: Die Session verarbeitet keine Ereignisse. Eine Session wird kurz nach ihrer letzten Nachricht inaktiv, sobald alle geplante Arbeit stoppt. Die Session behält ihre gespeicherten Daten, geplanten Zeiten und offenen Verbindungen, bis sie wieder aktiv wird.
Wenn eine Session inaktiv wird, bleiben Clients mit offenen Verbindungen verbunden. Ihre nächste Nachricht oder ein geplanter Wake aktiviert die Session wieder.

​
Client

Verwende base44.actors im JavaScript SDK, um einen Client mit einer Actor-Session zu verbinden und Nachrichten auszutauschen. Das Actors-SDK unterstützt folgende Funktionen:
  • Verbinden: Öffne eine WebSocket-Verbindung zu einer Session.
  • Abonnieren: Empfange Nachrichten vom Actor.
  • Senden: Sende Nachrichten an den Actor.
  • Schließen: Schließe die WebSocket-Verbindung zum Actor.
Mehr dazu unter Einen Client mit einer Session verbinden.

​
So interagieren Actors und Clients

Das folgende Diagramm zeigt die allgemeine Interaktion zwischen einem Client und einem Actor:
  1. Der Client verbindet sich über einen WebSocket mit dem Actor.
  2. Die Session wird aktiviert. handleStart() läuft beim ersten Start und bei jeder Aktivierung aus dem Leerlauf.
  3. Der Actor verarbeitet die Verbindung. Du kannst die Identität des Clients prüfen und die Verbindung ablehnen oder den aktuellen Zustand senden.
  4. Der Client sendet eine Nachricht.
  5. Der Actor verarbeitet die Nachricht. Du kannst das Format und die Berechtigungen des Absenders prüfen, bevor du den Session-Zustand änderst.
  6. Der Actor sendet das Update per Broadcast an jeden verbundenen Client oder antwortet nur dem Absender.
  7. Der Client schließt die Verbindung.
  8. Der Actor verarbeitet den Verbindungsabbruch. Du kannst verbindungsbezogenen Zustand entfernen.

​
Echtzeitnachrichten

Jeder verbundene Client gehört zu einer Session und kann über WebSockets Nachrichten in Echtzeit senden. Clients können mit subscribe() auch auf eingehende Nachrichten hören.
Base44 bietet mehrere Echtzeitfunktionen mit abonnementbasiertem Listener:
  • Actor-subscribe() hört auf Nachrichten, die der Actor an verbundene Clients sendet.
  • Entity-subscribe() hört auf Änderungen an App-Entitäten.
Prüfe, welchen Dienst du verwendest, damit du die erwarteten Ereignisse erhältst.
Mit Echtzeitnachrichten kannst du:
  • Einem bestimmten Client antworten.
  • An alle verbundenen Clients senden.
  • Die aktuell verbundenen Clients auflisten.
  • Jeden Client identifizieren und prüfen, ob er angemeldet ist.
Mehr dazu unter Verbindungen. Einen Beispielablauf findest du unter Client-Verbindungen verwalten.

​
Nachrichtentypen

Ein Client und ein Actor tauschen Nachrichten über eine Verbindung aus. Nachrichten gehören zu folgenden Typen:
  • Eingehende Nachrichten: Was ein verbundener Client an den Actor sendet, etwa einen Text, einen Spielzug oder eine Stimme. Der Client sendet sie mit send(). Der Actor empfängt sie in handleMessage().
  • Ausgehende Nachrichten: Was der Actor an verbundene Clients sendet, etwa eine Antwort an einen Client, einen Broadcast an alle verbundenen Clients oder das aktuelle Spielbrett, wenn jemand beitritt. Der Actor sendet sie mit conn.send() oder broadcast(). Der Client empfängt sie in einem subscribe()-Callback.
Wir empfehlen, deine Nachrichten zu typisieren, damit Actor und Client dieselbe Struktur jeder Nachricht verwenden:
  • Backend: Übergib die Typen Incoming und Outgoing als Generics an die Klasse Actor. Ein vollständiges Beispiel findest du unter Einen Actor erstellen.
  • Client: Erweitere das Interface ActorRegistry mit denselben Strukturen. So prüft TypeScript die Typen von send() und subscribe().

​
Speicher

Actors bieten mehrere Speicheroptionen, je nachdem, wie deine Session Daten nutzt und aufbewahrt:
  • In-Memory-Speicher: Arbeitszustand in Klassenfeldern, solange die Session aktiv ist. Er wird zurückgesetzt, wenn die Session inaktiv wird.
  • Persistenter Speicher: Ein Key-Value-Speicher für Daten, die erhalten bleiben müssen, wenn die Session inaktiv wird.

​
In-Memory-Speicher

Klassenfelder enthalten den Arbeitszustand, solange die Session aktiv ist, etwa das aktuelle Spielbrett oder einen Runden-Timer. Verwende In-Memory-Speicher, wenn sich deine Daten häufig ändern und beim Leerlauf nicht erhalten bleiben müssen, etwa ein Live-Spielstand oder eine Cursorposition. Wenn eine Session inaktiv wird, werden Klassenfelder zurückgesetzt.

​
Persistenter Speicher

Jede Session hat ihren eigenen Key-Value-Speicher, den du vollständig verwalten kannst. Verwende persistenten Speicher, wenn deine Daten erhalten bleiben müssen, wenn die Session inaktiv wird, etwa ein Chatverlauf oder ein Spielbrett. Um Daten zu speichern, die in der gesamten App verfügbar sind, verwende Entitäten. Mehr über Actor-Speicher erfährst du unter Speicher.

​
Zustand wiederherstellen

Wenn eine Session inaktiv wird, wird der In-Memory-Zustand zurückgesetzt. Persistenter Speicher bleibt erhalten. Die Session lädt die gespeicherten Daten bei der Aktivierung aber nicht automatisch zurück in den Arbeitsspeicher. Verwende handleStart(), um persistente Daten wiederherzustellen, etwa den Chatverlauf oder das Spielbrett. Einen Beispielablauf findest du unter Session-Daten persistieren.

​
Geplante Arbeit

Actors bieten Funktionen, mit denen eine Session Logik nach Zeitplan ausführt, unabhängig von Client-Nachrichten:
  • Ticks: Führe Code in einem Intervall aus und halte die Session aktiv, solange sie sich wiederholen.
  • Wakes: Führe Code einmalig zu einem von dir gewählten Zeitpunkt aus, egal ob die Session aktiv oder inaktiv ist.

​
Ticks

Ticks führen Code in einem Intervall aus und halten die Session aktiv, solange sie sich wiederholen. Verwende shouldTick(), um die Bedingungen für das Ticken festzulegen. Ein Actor wertet shouldTick() nach jeder Verbindung, Nachricht, Trennung und jedem Tick neu aus. So stoppt das Ticken, sobald die Bedingung nicht mehr erfüllt ist.
Ticken erfordert mindestens einen verbundenen Client.
Mit Ticks kannst du:
  • Die Länge jedes Intervalls wählen.
  • Eine Bedingung definieren, die das Ticken startet und stoppt, etwa „mindestens zwei Spieler sind in der Session“.
  • Den Code schreiben, der in jedem Intervall läuft.
Verwende Ticks, um eine Session aktiv zu halten, auch wenn Clients keine Nachrichten senden, etwa um einen Runden-Timer zu aktualisieren. Mehr über Ticks erfährst du unter Timer-Handler und Einstellungen. Einen Beispielablauf findest du unter Ticks ausführen.

​
Wakes

Ein Wake läuft einmalig zu einem von dir gewählten Zeitpunkt, egal ob die Session aktiv oder inaktiv ist. Mit Wakes kannst du:
  • Festlegen, wann ein Wake läuft.
  • Logik implementieren, die beim Wake ausgeführt wird.
Verwende einen Wake, um eine einmalige Aktion zu planen. Beispiele sind das Beenden eines Spielzugs, das Schließen einer leeren Lobby, eine Erinnerung oder der Start eines Ereignisses zu einem bestimmten Zeitpunkt. Mehr über Wakes erfährst du unter Timer-Handler und Einstellungen. Einen Beispielablauf findest du unter Wakes planen.

​
Einen Actor deployen

Deploye Actors mit actors deploy. Um alle Projektressourcen auf einmal zu pushen, verwende deploy. Beim Deployen werden Remote-Actors hinzugefügt und aktualisiert. Die übrigen bleiben unverändert.

​
Einen Actor löschen

So löschst du einen Actor:
  • Führe actors delete aus, um den Remote-Actor aus Base44 zu löschen.
  • Lösche das Actor-Verzeichnis aus deinem lokalen Projekt.
Wenn du den Actor nicht aus deinem lokalen Projekt löschst, erstellt und deployt das nächste actors deploy oder deploy den Actor erneut in deinem Base44-Projekt.

​
Siehe auch

Diese Seite wurde mit KI übersetzt. Die genauesten und aktuellsten Informationen findest du in der englischen Version.