[sanderjd]

Well, to separate concerns. ActionController does what it's good at (routing and rendering), and your application does what it's good at (business logic). One tangible benefit of separating concerns in this way is that it makes it possible to use the application itself as a module behind different adapters. So you can put it behind a raw tcp api, or a 0mq bus, or a command line front-end, etc., without needing to change anything but the adapters.

It is very reasonable to question whether this is really all that useful or whether doing it from the start is a premature optimization, but it isn't pointless.

[matdes]

I hear this often but when the frack do you ever interact with a raw tcp api or a 0mq bus that's existentially the same application as your web app??

[sanderjd]

Well, it's interesting. My example is partly contrived and partly not contrived. I worked on a big application where the web front end was very much the tip of the iceberg. We had the Rails monolith problems that you frequently hear decried. One thing we at least thought we would really like to do was move to an architecture with a bunch of little services talking to each other. We thought about having them talk to each other over tcp or 0mq, and we thought it would have been really nice if it were easy to take our existing application logic and put tcp or 0mq adapters on top of it. I keep saying "we thought", because we never actually did any of that, which may have been the case either because our application logic was so tied up with Rails that it was impractical to pull it apart (as some of us thought), or because it's a silly idea to begin with.

We did have a good deal of success pulling out libraries though, and separating concerns helps with that too. (So maybe I chose the wrong argument to make in my comment before.)