Hacker Newsnew | comments | show | ask | jobs | submit login

A state machine really isn't a great design for a web app.

For HTTP to work best, you should try and keep it as stateless as possible. Keeping state consistent between multiple servers is very much non-trivial. If your web app takes off and needs to be scaled to more than 1 server, design choices such as state machines can really cause you very nasty issues down the line. You either have to keep state across a memcache system, which can get wonky with multiple requests hitting multiple servers, or you have to keep the state encoded inside a cookie which opens up security issues.

Sticking to stateless webapps is nearly always a better choice. Check out some guides to RESTful services to get started.




You likely don't want to use a state machine to manage the state of the application here, but there are many other places a state machine comes in handy. If one of your models has several boolean variables, it may benefit from a state machine. Even HTTP parsing itself is often done with a state machine. None of those impact the statelessness of the connections.

-----


Very often state machines are the best representation for domain objects which have a life cycle. If you have a lot of user submitted content shared among other users, a common set of states could be:

"new", "approved-by-other-user", "verified-by-admin", "hidden", "promoted".

I agree that at the HTTP level you shouldn't be using FSMs.

-----


Definitely not for application state, but for resource state, a FSM can be invaluable. Take for instance something as simple as a blog comment system, where any administrator needs to be able to transition a "comment" resource into either accepted or rejected states.

They also work great for transactional resources like a shopping cart order.

-----




Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: