Stateful vs non-stateful App [geschlossen]

Ich habe etwas über zustandsbehaftete Apps im Vergleich zu nicht zustandsbehafteten Apps gelernt, bin aber in diesem Thema immer noch etwas verwirrt.

Angenommen, ich habe eine App auf Node, in der Benutzer zufälligen Räumen zugewiesen werden, sobald sie über socket.io eine Verbindung herstellen. Dies sind Räume von 4 und in keiner Weise persistent, aber sie werden in einer globalen Variablen als Hash-Map gespeichert. Ich verwende weder eine Datenbank (zu viele Abfragen) noch Redis (es ist zu teuer).

Ist dies ein Beispiel für eine zustandsbehaftete App oder nicht?

Im Kontext von Webanwendungen rufen wir den Server als statusbehaftet auf, wenn er den vorübergehenden Status im Speicher beibehält , anstatt Daten extern zu speichern (z. B. in einer Datenbank).

Stateful-Anwendungen haben eine Reihe von Problemen, zum Beispiel:

• Sie können nicht mehr als einen Server ausführen, ohne Sitzungen an einen bestimmten Server zu pinnen
• Der Status geht verloren, wenn der Server neu gestartet wird

Es wird daher empfohlen, den serverseitigen Status zu vermeiden (erneut: es sei denn, er wird extern in einer Datenbank gespeichert).

Web - App - Backends der Regel keinen Sitzungszustand speichern muß , weil sie REST Prinzipien verwenden können: Zustand wird übertragen zwischen dem Client und dem Server. Dieser Status wird durch URLs, Cookies, HTTP-Körper usw. dargestellt. Dies ist erforderlich, da HTTP ein zustandsloses Protokoll ist (semantisch nicht unbedingt in seiner technischen Grundlage).

Bei Web-Sockets brechen diese Prinzipien ein wenig zusammen, weil der Client eine Sitzung / Verbindung mit dem Server über eine lange Dauer aufrechterhält - und diese Verbindung beinhaltet den Status. Dies ist unvermeidlich, aber Sie steuern, ob und inwieweit die Verwendung von Websockets ein ansonsten zustandsloses Backend-Design gefährden soll.

• Es ist völlig in Ordnung, speicherinterne Datenstrukturen zu verwalten, die steuern, welche Verbindung für welche Ereignisse abonniert wird.

• Es ist problematisch, wenn diese speicherinterne Datenstruktur die „Quelle der Wahrheit“ für diese Informationen ist.

  • Wenn die Abonnements vorübergehend sein sollen, ist alles in Ordnung.
  • Wenn Sie dieselben Abonnements wiederherstellen möchten, wenn ein Client erneut eine Verbindung herstellt, müssen Sie diesen Status an einem anderen Ort speichern. Zum Beispiel serverseitig in einer Datenbank oder clientseitig über Cookies oder LocalStorage.

Im Allgemeinen ist die Aufrechterhaltung des internen Serverstatus in Ordnung, wenn eine der folgenden Bedingungen zutrifft

• Der Zustand wird extern gespeichert
• Der Status wird nicht zwischen Anforderungen geteilt
• Der Staat ist nur der Erwerb einer teuren Ressource, die wiederverwendet werden kann, z. B. Datenbankverbindungen
• Der Status ist ein Cache für eine autorisierende Datenquelle, obwohl dies zu schwierigen Problemen wie der Ungültigmachung des Caches und der eventuellen Konsistenz führt

Wenn Sie den Status auf dem Server speichern, der zum Verarbeiten einer eingehenden Anforderung vom Client erforderlich ist, ist der Server statusbehaftet. Anders gesagt, es hat den Status, dass es speichert und darauf zugreifen muss, um Anforderungen von Clients zu verarbeiten. Ihre Hashmap ist also state, also ist Ihr Server stateful.

Jetzt gibt es nur noch wenige echte Web-Apps, die reichhaltige Dinge tun, die überhaupt nicht zustandsbehaftet sind. Wenn Sie sich als Benutzer anmelden und dann Anforderungen im Auftrag eines angemeldeten Clients verarbeiten möchten, speichern Sie per Definition den Status auf dem Server, der sich auf einen bestimmten Client bezieht, und der Server ist statusbehaftet , auch wenn nur für die Login-Infos.

Ich würde mich also nicht zu sehr darauf einlassen, dass auf dem Server kein Status vorhanden ist. Entscheidend ist, wie viel Status sich auf dem Server befindet, wie teuer (in Bezug auf Verarbeitung, Speicherung usw.) das Speichern und Zugreifen auf diesen Status ist und ob Sie Ihre App mit diesem Status weiterhin horizontal skalieren können. Und wo immer es praktisch ist, behalten Sie den Status im Client bei, nicht auf dem Server. Angenommen, Sie haben eine Client-App mit der Schaltfläche "Nächste Seite". Sie können "nächste Seite" entweder mit dem clientseitigen Status oder dem serverseitigen Status implementieren.

Wenn Sie für die aktuelle Seite des Clients einen serverseitigen Status hatten, können Sie einfach einen Befehl an den Server senden, auf dem Sie die "nächste" Seite anzeigen möchten. Der Server überprüft den Status für diesen Client, erhöht die Seite und gibt dann die Daten für die nächste Seite zurück.

Oder Sie können die aktuelle Seite auf dem Client speichern. Wenn der Client die nächste Seite möchte, nimmt er die aktuelle Seitenzahl, erhöht sie um eins und fordert generisch die spezifische Seitenzahl an, die er als Nächstes anzeigen möchte.

Welche dieser Implementierungen lässt sich Ihrer Meinung nach besser skalieren? Was ist einfacher zu implementieren, wenn der Benutzer eine zweite Registerkarte öffnet, auf der eine andere Seite angezeigt wird? Welches ist einfacher horizontal zu skalieren. Die Antwort auf all diese Fragen ist die, bei der die aktuelle Seite nicht auf dem Server gespeichert, sondern im Client gespeichert wird und nur allgemeine Anforderungen für Seite N an den Server gesendet werden. Wenn Sie diesen Status clientseitig beibehalten, können Sie einfacher einzeln und horizontal skalieren und mehrere Ansichten für denselben Client unterstützen.