[grey-area]

My thoughts exactly. On reading:

Controllers actions are allowed a single line of code

I wonder, why do these controllers exist at all?

    def show
      app_of_things.show_thing(rails_adapter)
    end

Is code like this really useful code? It looks like it was written by a very short perl script. Why is he using rails at all at this point, rather than ditching the framework and using a simpler router which talks directly to his app endpoints? What does this controller add aside from a level of indirection which will never be useful?

The lack of an example with code running in production makes it very hard to judge where all this is leading or why you would want to do this.

[hawleyal]

Exactly. If they are only one line, why not just have the "app code" handle the routing as well?

[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.)

[bestie]

It is useful, the controller in this case handles web concerns and translates a HTTP message into a message that is meaningful to application.