Rails and Node.js – Interaction and Architecture Explained

Architecturenode.jsruby-on-railssystem

I and my co-worker are developing a web application with rails and node.js and we can't reach a consensus regarding a particular architectural decision.

Our setup is basically a rails server working with node.js and redis, when a client makes a http request to our rails API in some cases our rails application posts the response to a redis database and then node.js transmits the response via websocket.

Our disagreement occurs in the following point: my co-worker thinks that using node.js to send data to clients is somewhat business logic and should be inside the model, so in the first code he wrote he used commands of broadcast in callbacks and other places of the model, he's convinced that the models are the best place for the interaction between rails and node.

I on the other hand think that using node.js belongs to the runtime realm, my take is that the broadcast commands and other node.js interactions should be in the controller and should only be used in a model if passed through a well defined interface, just like the situation when a model needs to access the current user of a session.

At this point we're tired of arguing over this same thing and our discussion consists in us repeating to ourselves our same opinions over and over. Could anyone, preferably with experience in the same setup, give us an unambiguous response saying which solution is more adequate and why it is?

Best Answer

Seeing your clarification, and since you want developers' opinions, here's my $0.02. I would call Announce from inside your controllers, for two reasons. First, I tend to see ActiveRecord callbacks as being a kind of "implicit"/"passive" calling of an action. ActiveRecord makes sure to run those callbacks for you and -- unless they break -- you don't really pay much attention to them again. You don't have to call them manually; they tend to minor, routine sorts of matters.

This working assumption I've always had leads into the second reason for me: returning a response client-side is an "active", realtime process, and by rights should be something explicitly invoked and viewable in the more "active" side of your codebase (viz., the controllers). Returning responses back to a browser (whether via Rails, Node, &c.) are more of a controller's responsibility, and the Rails framework is geared toward that kind of setup.

Related Topic