Hacker News new | comments | show | ask | jobs | submit login

> How often does that concept come up when you are tossing together a web app?

I end up using some kind of state machine just about every time I build a web app. If you're just tossing PHP together to make something work, you might never happen upon a pattern like that, but as a professional developer these things definitely shouldn't be a mystery, even if you "just" build web apps.

In fact, as someone who does not have a CS degree, a state machine seems like something that is difficult to avoid figuring out, even in web apps. Maybe it is just a bad example of something more underly though.

I rarely use state machines when composing web applications. Of the 20 or so times I've spotted an opportunity to use a state machine, only 2 or 3 of those opportunities actually were the optimal choice.

Like all things, state machines can be overused and over abused, even during times when they are not ideal.

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.

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