Ruby on Rails vs. Single-Page Applications (React)February 17, 2020
To start, what is software architecture? How can it help a code base, and when is it useful? Take this simple script:
We could add more architecture to this program by writing an abstract class, Operation, and a subclass for +, -, *, and /. The operations could live in their own module, and each class could live in its own file in a separate subdirectory. However, this would clearly make the program harder to understand, not easier.
Conversely, let’s imagine we were to write a complex web application like we did this script. In our application we have to read from a database, connect to a remote API, generate HTML, and log user data. And we’re writing all of this in one file! The program would be impossible to understand, and difficult to update. If we put all of the database code in its own file, all of the HTML code in its own file, etc. it becomes much easier to manage. We can go further. For example, if we have a lot of different pages, we might put all of the HTML generating code in a folder and each page in its own file within that folder.
Let’s synthesize this thinking into some definitions and conclusions:
- Architecture is the structuring of a program into different modules, classes, folders, files, functions, etc. A program has more architecture if it has wider usage and deeper nesting of this structuring.
- An architecture, such as MVC, is a particular way of structuring a program.
- The amount of architecture that a program calls for is proportional to the program’s complexity and size. In other words, our architecture should be as simple as possible while allowing our code base to be organized and well designed.
- It is good to structure a program based on its concerns, e.g. working with a database and displaying HTML.
- The code dealing with each concern should in turn be architected proportionally to its complexity and size. If the HTML display code in a web application is only 100 lines, it should all live in one file. But if the database code totals over 100,000 lines, then it should have its own internal organization with its own subsystems.
MVC architecture splits the application into three main systems:
Following our early discussion, MVC is a good choice when these three systems are in balance in complexity and scope. If there’s no need to have a database in your application, or if you’re just serving a JSON API and not a full web page, then MVC might be overkill for your program. On the other hand, the structure that MVC gives you might not be enough to sufficiently organize your code base. For example, it’s a good MVC principle that views don’t directly depend on models. If you have very complex views which require a lot of data to render, this can become a problem, and you might want to consider an architecture like Model-View-ViewModel which better organizes this complexity.
As the internet has grown and more computing has moved off of desktops and onto the cloud, the View part of web applications has grown in scope. We now have full office suites, artistic software, and complex video games that run in native HTML 5/JS on the browser. Looking at how these kinds of applications would be constructed in MVC makes it clear that it does not offer enough structure for the view code:
Single-Page-Applications were invented to solve this problem. An SPA is best thought of as two separate programs, a client and a server, which communicate with each other. Here is one way that an SPA might be architected:
First, this has the flexibility to organize the view code better than MVC (the whole client application is the “view” code). Second, the SPA architecture is overall more complex than in MVC. There are more places that code could go, and more subsystems in our application. And most importantly, instead of having one application, there are two applications that communicate with each other asynchronously. As we noted earlier, this extra complexity either a good or bad thing depending on the scale of the view code. Third, domain code on the client is probably duplicating logic that also exists on the server. Say you’re writing a banking application. You might want your UI to prevent the user from over-drafting their checking account, but you definitely want the server to perform the same check before making the transaction. In MVC, both the view and the query could use the same model code for this, but in an SPA it will have to be written for both applications.
Here’s what we can say about the choice between MVC and SPA architecture:
- If the view code needs to be more complex than standard MVC tools can accommodate, SPA architecture can be a superior choice.
- If this is not true, then SPA architecture will increase the complexity of the application for no benefit.
Here are the cases I would recommend considering SPA over MVC. First, any application that involves generating complex content in the web browser. These applications will likely need UI code that rivals traditional desktop applications in scope, so SPA is a good fit for managing that complexity. Examples of this kind of application are office suites like Google Docs, UXPin.com (an in-browser UI prototyping program), and Vectr.com (an in-browser vector graphics editing program). Second, any application that has non-trivial client side functionality that relies on business logic. In this case, I think the best architecture is a Single-Page-Application that uses the same client and server language, as I discussed earlier.
To summarize, the architecture of your application should be complex enough that your code base is easy to understand and maintain. If the architecture is more complex than it needs to be, it makes the code base harder to understand and maintain. Single-page-applications written with a tool like React or Vue.JS are great for applications with rich client-side functionality and a large client-side code base. But for a web application that only need dynamic elements, such as forms that add or disable fields based on user input in previous fields, SPA is probably overkill, and MVC should be strongly considered, even in 2020.