Are Days Counted for MVC-based Web Applications?

Today, if I am tasked to lay down the architecture for web application, I would no longer be blindly choosing MVC based architecture. Additionally, if this is a migration project from legacy to web application, I would no longer be blindly going for MVC based architecture and choose related MVC frameworks. Not sure if you would agree with me or not. But please read the following and share your thoughts. I would be happy to hear from you.

Why am I getting paranoid regarding MVC for web applications?

Following are criteria for my considerations for deciding on whether I would select MVC architecture for delivering business functionality on the web:

1. Is it an enterprise application catering to the needs of serving functionality for different line of business (LOB) on different channels such as mobile devices, web etc?
2. Is it a web application which has to be delivered both on web and mobile devices?
3. Is it a simple web application in terms of a single set of functionality, it has to serve to a particular class of users?

For option 1 and 2, I shall rather do a deeper analysis before choosing MVC based architecture. For option 3, I would want to choose MVC based setup but that too a bit hesitantly. The primary reason for me started getting uncomfortable with MVC are some of the following:

• Need for the businesses to deliver the services on multiple channels including desktop, smart phones, iPads etc leading to the need of having to maintain APIs for native mobile apps to work with.
• Limitation with web applications to deliver business functionality seamlessly on different channels without much intervention such as porting web application to HTML5, having a sub domain for the mobile version of website etc.

Gone are the days when we used to talked high about the advantages that “webification” of enterprise applications used to bring. In this age, it is no more a subject of pride to tell that your enterprise applications can be accessed on the web. This is because of the entry of mobile devices, which is going to be key delivery channel and the game changer, enterprises would have to consider to deliver their business offerings.

So, What alternatives do I have?

Look at the diagram below to get an understanding of current MVC-based web applications and the shift which can happen in near future.

The above diagram represents the current state of affairs where web applications are delivered as website, mobile-compatible website and native mobile apps. Note the separate set of APIs that needs to be maintained for mobile apps. This acts as a disadvantage owing to the fact that MVC based web applications need to be maintained along side APIs for mobile applications.

The diagram above represents the to-be state of affair where MVC based website gets converted into light-weight web UI which accesses the functionality via centralized API. This approach brings advantage of maintaining centralized APIs and application components without the need of having different versions maintained for different channels. Looking at the trend that users are using web applications through mobile devices, this makes much more sense to move to above model.

Thus, one of the recommended alternative for delivering the business functionality on different devices while ensuring seamless & consistent experience is moving the API way. The API way would ensure following advantage:

1. One set of APIs to deliver business functionality to different devices unlike maintaining MVC website, and separate APIs for website and mobile device respectively. With this setup, website shifts to light-weight UI more than anything else with no need of components developed on MVC pattern. Read about how Twitter website became users of their own APIs, thereby, moving away from need to maintain MVC website components and APIs separately.

Few years back, while working with one of the banking startup, I remember one of my colleague being a strong proponent of API based development thereby leading to creation of PHP based UI front end talking to APIs (on top of Java application) for various different functionality. There were many who simply laughed on his approach. However, when I think today, he looks to me as thinking ahead and laying down the architecture appropriately.