Web Applications – Part 2: Too Many Cooks in the Kitchen?

Now that the roles have been established, we can assign tasks. For the Backend, the tasks are relatively simple to summarize and are (nearly) universally accepted: Databases store data and Services collect data.

Conventional wisdom dictates that web servers provide pre-populated views. Traditionally, this made sense—the medium through which web content (a View) was displayed was almost exclusively a web browser. Smartphones did not yet exist and web browsers were woefully underpowered. Enter the digital revolution —where data is shared between, and viewed from, any number of different devices using an ever-growing number of mediums.

Now, consider a Smartphone app. The app is installed on the user’s phone, it receives data from a central place, and it displays that data. It does not receive a pre-rendered view. This is because the Smartphone app could be running on an iPhone, an Android phone, a Symbian (Nokia) phone, a Blackberry phone, or a Windows Mobile/RT phone. It would be ridiculous for a web server to store and deliver views for all the various mobile operating systems (which all have different methods of rendering views/displays).

Similarly, given today’s sufficiently-powered web browsers, why should a web app be an exception? An API already exists (or should already exist) to provide data to other applications; why not use it to provide the data to a web application?

Some may argue that security is an issue but this concern can be easily mitigated: When a Client displays a view requested by an unauthorized user, the API will deny the request regardless of whether the Client is a web app or a smartphone app. Thus, no sensitive data will be displayed. The worst thing that happens is that the unscrupulous user will see an empty view or an error message. As a result, the View is free to manage its own tasks—templating and data-binding.

This means that the Controller is left with everything else. Since its role is to act as the gateway and gatekeeper through which the View and the Model communicate, the Controller has three main tasks:

1. Access control. Verify the data request was made with sufficient authorization.

2. Proxy. Relay the authorized request to the appropriate store or service that will ultimately perform the operation and return the result.

   1. It might also filter and/or reformat the Backend’s response to a scheme expected by the View.

3. File server. Provide the requested file (unique to web apps, which are cloud-based).

Overall, adopting a new way of thinking about web applications ensures that everything has a place and that’s in its place. The Service should deliver data in a universal format so it can be used in any way that the end user wants. This ensures that the application’s core remains small, is easily maintained, and scalable. In short, when done properly, the cause of bugs is easier to identify, development is faster (in the long-run), and overhead is lower.