Stateless web frameworks - Shopping Bag und isLoggedIn in die DB?
-
Habe mir heute mal 2h hergenommen und mir das Play-Framework http://www.playframework.org/ angesehen. Gefällt mir bis dato ausgezeichnet. Allerdings ist das Framework komplett stateless und jetzt frage ich mich:
Wo speichere ich jetzt bspw. isLoggedIn oder einen Shopping Bag? Muss das tatsächlich zurück in die Datenbank? Ich könnte eine In-Memory-DB verwenden, ist das so usus? Kann ich dem JPA in Java sagen, dass ich je Entity eine andere DB haben will (Persistent vs. in-memory?)
Wie denkt ihr generell über diese "stateless Sache"?
MfG SideWinder
-
Stateless Frameworks sind das einzig wahre (tm).
isLoggedIn und Shopping Carts klingt nach Session. Das hat nichts mit stateful vs stateless zu tun.Stateless bedeutet das zwischen einzelnen Requests keine Daten gehalten werden. In gewisser Weise kann man Session Daten natuerlich als state ansehen, aber es ist dennoch etwas anderes - da es eher persistente Daten sind.
Stateful Systeme gibt es eigentlich recht wenige. Hauptsaechlich in der Java welt bei EJBs. Stateful Systeme skalieren naemlich ziemlich schlecht.
Besser ist stateless wohl eher als sandboxing zu betrachten. Jeder Request laeuft abgeschotten von anderen ab. Was bedeutet dass ein Request keinen anderen beeinflussen kann -> bei php ist das zB standard so. Deshalb skalieren PHP Systeme auch so gut.
-
Fragt sich nur wo die Session dann abgelegt ist. Nehmen wir an ich speichere Session-Daten in die DB und gebe dem User ein Cookie um die richtigen Daten wieder auslesen zu können.
Anstatt das Frontend muss nun eben die DB verteilt sein. Inwiefern habe ich mich da verbessert? Ich habe das Problem ja nur weiter weg geschoben, oder?
MfG SideWinder
-
SideWinder schrieb:
Anstatt das Frontend muss nun eben die DB verteilt sein. Inwiefern habe ich mich da verbessert? Ich habe das Problem ja nur weiter weg geschoben, oder?
Die DB selber kann man ja wiederum clustern
Aber ja, natuerlich ist es ein Problem, dass die DB (oder FileSystem oder was auch immer: der persistente Speicher eben) nun staerker belastet wird. Dies laesst sich durch einige Tricks natuerlich reduzieren - aber Grundlegend ist dies in der Tat ein Problem.
Es ist aber ein viel groesseres Problem ein statefull System zu haben. Denn wenn wir nun einen 2. Server nehmen um die Last besser verteilen zu koennen, haben wir ein Problem. Wir koennen nicht garantieren dass der naechste Request wieder auf dem gleichen Server ladent (bzw. wenn wir das garantieren koennen dann balancieren wir unausgewogen).
Wir muessen beide Server nun irgendwie synchron halten und das kostet. Bei einer Datenbank ist das zB weniger ein Problem, weil wir eben die HTTP Server clustern koennen und die DB Server ebenfalls. Wir tun uns also beim skalieren leichter.
Vorallem: eine starke DB braucht man ja auch bei statefull Systemen. Denn auch wenn die Session Daten weniger belastet werden, so haben wir ja dennoch eine Menge dynamischer Daten die wir laden muessen... Wo statefull System richtig stark sind, ist bei vielen Ajax requests auf einer Seite - da wir hier sehr viel im Speicher halten koennen. Solange wir eben nicht auf mehrere Server gehen muessen.
Prinzipiell ist es aber wie schon gesagt so, dass stateless die korrekte wahl ist. Die besten Systeme sind stateless. Ich kenne jetzt eigentlich nur Java Seam als stateful System...