Thursday, April 18, 2013

A comparison of Web Frameworks: How they handle application state


This table summarizes my research about how different web frameworks handle state in web applications. Sorry for the bad formatting. As usual, it is the result of my ethernal, hopeless fight with blogger.com.  Additionally  this table is generated from a latex script passed trough an online converter. ( I´m too lazy to redo it again in HTML)

The event model, or state transition model is imposed by the inversion of control of the web architecture, where the  IO handler, the web server,  call different pieces of programmer code, instead of the other way around. This is imposed by the stateless nature of HTTP and the hyperlinked nature of HTML. But this inversion of control can be reverted back again, so that an intuitive, sequential programming style can be achieved for web applications without losing navigability. This happens in the continuation based frameworks - at the cost of scalability. 

WASH the old but fine web framework from  Peter Thiemann ran  state as a sort of small log that is replayed after each request so the program find its right location of code to respond to each request, so a WASH program would run even as CGI extension. MFlow uses such a small log, but the process stay running between request (unless timeout, in which case replay the log) and uses backtracking to match the request when back button is pressed.  Because a log is made of events and the events can be easily synchronized among machines, MFlow is scalable.
 

Web frame-
How it works

How
state/navigation
Problems


work





works









Event model
- State transition machine model



MVC:

MVC,

mostly
Add
session
state as
Event-based:
spaguetti
ASPX,

stateless.

Page
hash
tables.
flash
ob-
code. back button usually
JSP,
Rails,
oriented


jects(Rails)


does not work (roll-back
node.js,
Yesod,
HappStack,
Snap









state hardly possible)





Struts, JSF
MVC page and ses-
Add
basic configurable
Event based, complex, no


sion oriented

navigation (XML)

checks
at
compile time.










No back button support











Seam,

Flow

oriented
add
conversations,
sub-
Event
based,
complex-
Spring
Web
via XML config
flows, back button sup-
ity,No checks at compile
Flow

and

language
port



time





extensions



















Apache
MVC
with
inter-
add
serializable
page
Event
based.
No
wicket

face in java ob-
state. support back button
back
button
detec-


jects+HTML

(with appropriate browser
tion,serialized state may






configuration)


be big



















Procedural, sequential style




Coccon, sea-
Continuation-
serializable
execution
compile time checks vary.
side, ocsigen
based,
flow
in a
state, support back button
serialized
state
may be


single

procedude




big.
no
bookmarkable


(javascript,smalltalk,




URLs,
scalability prob-


Ocaml







lems





respectively)

















WASH

Monad


for
Log recreate the execu-
Each request implies a re-


creation-replay
tion state


play of the log. log in the


of the log, flow in




browser can be hackedv


a single
procedure










(haskell)



















MFlow
Monad


trans-
Log may recreate the ex-
Under test




formers
for
log-
ecution state.
Execu-






ging/recovery

tion state stay in memory.






and

navigation
Back button supported by






backtracking,
flow
backtracking. bookmark-






in a single Pro-
able URLs








cedure(Haskell),










checked at runtime.






















Flow state management on different Web Framewors

No comments: