JavaScript Wann State Management, wann REST API?

[Physically]

Moin,

wenn ich eine Webapp programmiere mit einem JS Framework (z.B. Vue) dann habe ich dort die Möglichkeit über Vuex State Management zu nutzen. Wenn ich nun eine Datenbank (z.B. PostgreSQL) dahinterschalten will mit einem Backend Framework wie Django dann kann ich das super über eine REST API verbinden. Vue holt sich dann über die API-Endpoints die Daten bzw. modifiziert diese. Ich frage mich ob es ein Szenario gibt, in dem es Sinn macht trotz REST API State Management zu nutzen? Ich meine wenn ich einen Datensatz habe, den ich auf Seite 1 anzeigen möchte, dann mache ich das mit einem GET-Request. Auf Seite 2 möchte ich diesen ebenfalls mit einem GET holen und dann z.B. mit PUT oder DELETE modifizieren. D.h. Seite 1 und Seite 2 können auf die zentrale Datenbank über die REST API zugreifen und die Daten abrufen/modifizeren. Das gleiche passiert doch auch beim State Management nur ohne "richtige" Datenbank oder? Warum sollte ich dann State Management nutzen wenn ich eine Backend programmiere mit Datenbank?

Ich kann mir vorstellen, dass abfragen von Daten über State Mangement deutlich effizienter ist da bei einem API-Request das ganze HTTP-Protokoll transferiert werden muss.

Danke für die Aufklärung!

 

[pmkrefeld]

Also REST mit State ist kein Rest mehr
Und nicht jede Änderung sollte sofort in der Datenbank landen.
Aber werden Bindings nicht sowieso vom Framework abgewickelt, so dass die Überlegung eigentlich überflüssig ist?

 

[Physically]

Aber werden Bindings nicht sowieso vom Framework abgewickelt, so dass die Überlegung eigentlich überflüssig ist?

Wie meinst du?

 

[pmkrefeld]

Wenn ich jetzt nicht etwas komplett falsch verstehe ist das StateManagement mit vuex komplett unabhängig davon wie und wann du diese an ein Backend weitergibst und soll lediglich dazu dienen den Zustand der App zentral zu halten und nicht zu duplizieren.

 

[Physically]

Das ist schon richtig. Ich verstehe es so:

Ich nutze ein Backend wie z.B. Django, mit welchem ich Daten in einer Datenbank speichere z.B. Kontakte, Projektdaten, todos etc

Wenn wir bei den Kontakten bleiben: Angenommen ich gehe auf "meineseite.de/kontakte". Es wird ein Lifecycle von Vue aufgerufen (created) der beim Erstellen des DOM aufgerufen wird. Dort habe ich eine Methode drin, die mittels GET-Request die Kontakte aus der Datenbank zieht und sie dann "stateful" client-seitig speichert. Somit muss ich nicht, wenn ich z.B. auf der Seite "meineseite.de/projekte" bin, auch hier die Kontakte von der Datenbank requesten (da diese Seite bspw. die Kontakte benötigt) sondern kann mich dann einfach auf den State beziehen der z.B. vom Typ Object ist und client-seitig verfügbar ist. Ergo: effizienter.

Ist das der Sinn und Zweck oder liege ich da falsch?

 

[mastaqz]

Am einfachsten ist es, wenn du zwischen Daten und dem Zustand (=State) unterscheidest.

Daten sind Informationen, die langfristig gespeichert werden.
Deshalb wandern sie in eine Datenbank.
Beispiel: Useraccounts, Forenposts etc.

State sind Informationen, die kurzfristig gespeichert werden.
Deshalb werden sie in Plain JavaScript, React Hooks, Vuex, Redux etc. gespeichert.
Beispiel: geöffnete User-Interface-Menüs, angeklickte Elemente etc.

Der Vorteil von State ist, dass man keine Requests machen muss, die Anwendung also offline nutzbar sein kann.
Der Nachteil von State ist, dass er ohne zusätzliche Datenbankanbindung nicht langfristig gespeichert wird.

 

[Physically]

Das war ein sehr gute Erklärung. D.h. das Nutzen von einer REST API und einem State Management ist was ganz Normales weil das letztendlich zwei verschiedene Dinge sind?

 

[fhtagn]

So ist es.
Vor REST war es häufig so, dass eine Webanwendung auf dem Server lief. Dort wurde verwaltet, welche Benutzer aktuell angemeldet sind, was jeder Benutzer gerade macht (Anwendungsfall/Arbeitsschritt), was man sich so an Logik und Zustand vorstellen kann.
Mit REST befindet sich so viel wie möglich Logik/Zustand auf dem Client. Der Client fragt den aktuellen Zustand ab (GET), ändert ihn lokal über beliebig viele Bedienschritte und schickt ihn irgendwann zurück (PUT). Der Server braucht dadurch keinerlei Kontext mehr. Alle erforderlichen Informationen befinden sich in der Anfrage (GET, PUT usw.). Der Server wird nachvollziehbarer, robuster und Resourcen-schonender. Der Client, auf der anderen Seite, wird komplexer, aber auch reaktionsfreudiger. Und er muss nur Logik für einen Benutzer implementieren was immer noch einfacher ist als die Server-Logik zuvor.

 

[ayngush]

Gut beschrieben @fhtagn
Im Web findet man viele Informationen zu dem Thema unter den folgenden Stichworten

"API First" (genereller Ansatz, warum man überhaupt API verwendet und nicht alles Serverseitig abhandelt)
"API Driven Architecture" (die Architekturentscheidungen - hat viel mit dem API First Paradigma zu tun)
"API Driven Development" (die Entwicklungsentscheidungen, wenn man sich für eine API Architektur entschieden hat)
"Documentation Driven API Design" (ein Paradigma, wie man moderne API gestaltet)
"CRUD" (Create Read Update Delete - ein Entscheidungsschema, wie man von seinem Datenmodell zu seinen API-Endpunkten und -Methoden gelangt)