If you're familiar with software architecture patterns or work in the industry you'll know the term Model View Controller design. I had an encounter recently that helped visualize the overall design of a software system in a new light. Here's a brief explanation of the abstraction.
I am going to compare to Ruby on Rails because of its structure and popularity. Here we have a classic example a MVC, but there is another component you don't see on the diagrams and that is the router (routes.rb). When one specifies endpoints in the router on Rails, we define addresses and the request is directed to a corresponding controller to handle the response. Let's take a step back and redefine the word "Route".
Rails provides a path to take in the router. I was stuck on a problem when developing a node.js application where the existing codebase was throwing me off due to the file naming convention. After understanding what my colleague's goal was, we ended up having our files constructed not as an MVC framework but as a SRS framework. The server-route-server framework was not obvious at first but once understood makes a great deal of sense.
The first part here is the server, represented by a UI (on the server) where a user interacts. The server.coffee file in this case performs the duty of a typical routes.rb file in Rails. It receives the request and directs where to process this request. The directive points to a class within the "routes" directory and how we process the request is defined here. It's more intuitive, the route in our case defines where and how we persist input data from the user. A big improvement on naming convention, when one is presented with a route, they are given the full set of "directions" on how to get there, not jus the destination.
It's a holistic design and it really simplifies data exchange services in an abstract way. The route determines which path to take and removes a step in MVC. The route now includes all code to process the request, and directs us to the next server that we need. In this case, our next server was mongoDB for persistent data stores. The advantage and takeaway here is simple; we combined the actions of the model and controller into a single file and we reduced the overhead of processing incoming requests.
Some may argue that this is breaking MVC and it is, but here's why it's advantageous. Rails controllers get bloated quickly, and everyone has their own idea of what code should go where in the model vs the controller. Here we ignore that, simply use our route to exclusively save user input and chain us to the next step. Any manipulation to the data is done in the background giving a big performance gain and enables greater horizontal scaling.
