Before I begin, here is a bit of background for those unfamiliar with web applications. Web applications consist of three basic components:
Backend: Database(s) and Service(s)
Middleware: A web server (for example, Apache, NodeJS, Tomcat, etc.)
Client: Google Chrome, Mozilla Firefox, Apple Safari, Mobile app, etc.
In modern web application architecture, the Model-View-Controller (MVC) model dominates. This software architecture separates the representation of information from the user’s interaction with it, where:
Model = Data
View = User Interface
Controller = Processor that facilitates input
However, the improvement of Internet browsing software has largely outpaced web-based applications. Historically, web standards have been developed slowly and have not always been universally implemented across browsers. Additionally, the key tool in the web-app toolkit, Javascript, was painfully slow. But with the fall of Internet Explorer and increased competition, Google Chrome and Mozilla Firefox have vastly improved support for web standards and JavaScript engines.
The conventional wisdom of MVC has meant that web servers take on the responsibility of both Controller and View by delivering HTML pre-populated with data. However, this is not the best way to design web apps. Consider the following:
The Model represents data; databases store data; databases are Backend; therefore the Model is effectively the Backend.
The View displays data (the Model) in a human-friendly way, with color, graphics, stylization of text, etc. The View can be rendered by multiple, mutually exclusive means (web browsers render html, iPhone apps render C, Android apps render Java), but stored data cannot feasibly maintain versions for all possible means of display. Therefore, the View must be independent of data and specific to the method of render (Google Chrome vs. iPhone app vs. Android App). The closest place to Client is the client itself — thus the View is analogous to Client. This is a key difference to traditional thinking.
Given the above, the Controller must be the glue in the middle that holds them together. In order to service multiple, varied views, the Controller must be removed from the view — and the only place independent of both Backend and Client is Middleware. Therefore, the Controller is analogous to Middleware.
With the above points in mind, essentially today we have a new way of building web applications, where:
Model = Backend
View = Client
Controller = Middleware
In Part 2, I’ll discuss what these conclusions mean for the implementation of web apps and what do with them.