In the past, I developed desktop applications in C++, Java, Delphi, C# and Visual Basic. Across all the languages and the frameworks, the development paradigm was quite straight forward. There is a Window (a.k.a. Form) with some controls on it and you wire up the actions for them. Those actions might perform calculations, access a database, a file or all of the above. So to sum up, a single desktop application will contain the logic for user interface, business rules and data access inside it. The down side of such stubby applications (a.k.a. thick clients) is, that the storage (database or file) has to travel with it. So sharing this application with multiple users is cumbersome, generating reports is not fun and puts pressure on the local network.
Later came the client/server applications. They introduced a distributed application structure. The concept is quite simple and it is as follows; the Window (Form) with the controls becomes a separate application called the Client, and the rest of the stack will be moved into a separation application called Server. The client can talk to the server over the network to perform actions such as save and load. This allows multiple users to, for example, process different orders simultaneously, as the storage now resides with the Server application.
When the Service Oriented Architecture (SOA) came into play, we started further separating the responsibility of a Server application into logical components called Services. We were able to segregate business logic into smaller more manageable pieces of code, for example a server performing booking flight tickets and giving out quotation for customers will be split into customer service, booking service and pricing service. This avoids the single point of failure, as in if the server is down, the client application will become useless. With the SOA paradigm, the client does not have to rely on a single server application for everything. If the booking service is down, the client can still provide quotation on flight tickets.
I feel that SOA really set the stage for web applications as we know it now. It made us ask some serious questions. Why do we need to install a desktop application on every user’s machine to allow them to access flight ticket quotation, if all that the desktop application doing is calling a service to provide you with the price? How great would it be if the user can get the quotation via the website? Wouldn’t I be able to book a flight ticket via the same website as well? Answering these questions in the IT industry, gave birth to protocols and frameworks that allowed us to develop robust web applications for example, Drupal, JEE and ASP.NET.
Then it sparked the question of what if I can charge the user for using my service, for example I have an International Address Locator service that a company putting orders through can use it to verify sender and receiver addresses? That gave birth to the paradigm Software as a Service (SaaS), a sales model based on SOA.
The evolution in software engineering teaches us that creating clearly defined separation in the layers of application development is profitable, manageable and maintainable for everyone involved. We have now come to a stage where a client application can access services in a plug-n-play fashion to provide more to the user as the application grows. We can call it a Client/Service paradigm.
From an architectural view point, we have been improving the back-end side of things by means of separation of concerns. What about the front-end, the presentation layer that is responsible for the user interface and user interaction? It feels like that we have been focusing a lot more on the business logic and data storage side of things than the user interface. The future, as I see it, will be introducing a standard will be separating presentation layer, as we know it now.
If we take ASP.NET MVC web application as an example, the presentation layer contains the Routing, Controller, View and the ViewModel. The routing mechanism is responsible for wiring up a certain URL to an action. This action is present in the Controller, which will perform the action by executing calculations or accessing web service. Once the action has for example fetched some data related to an Order, it will populate the ViewModel with that data. ViewModels are, as the name suggest, models that are purely used, for presentation purposes, to construct the View. View The View contains the mark up of the web page that is to be displayed to the user, with the data from the View Model.
The controller is written in C#, the View is written is ASP or Razor. Then we add some CSS to style the elements and JavaScript to provide animation or smooth user experience think of AJAX for example. The View written in ASP or Razor, is then converted into HTML code and it is sent to the user’s browser along with the CSS and JavaScript. The browser then interprets the HTML and renders the web page using CSS and JavaScript.
I find this whole experience of writing code in C#, then Razor and a bit of JavaScript is a a bit half-backed and from a business point of view, waste of developer resources. If HTML, CSS and JavaScript are the web programming languages, why mess around with intermediate languages such as ASP and Razor to generate HTML code if it can’t generate JavaScript as well? If the goal was to lure back-end developers to create web applications, yeah it kinda works. But as a business you still need to outsource the UI related slicing and initial CSSing to some other company and am pretty sure they will be happy to charge you big time.
Where am I going with this? With advances in HTML, CSS and JavaScript libraries such as JQuery, Knockout and Angular, we can move the entire presentation layer written in C# and Razor to client side using JavaScript only. Our machines can handle JavaScript games running on the browser, so having a web page run by JavaScript is not going to slow our machines down, and we will be consistent with having a single front-end development language. We can leave the business logic and data storage side of things to RESTful services, which can be written in any language depending on its goal.
This way you can employ front-end developers to focus on developing creative web sites with amazing user experience, while having your back-end ‘gun’ developers build up the services that represent the business domain and workflow accurately. Sometimes the back-end developers might not have to build services from scratch. It might be cost effective to have them use an existing SaaS service, for example SaaS Address Validation before putting an order through or MacAfee SaaS Virus Scan when user uploads a file.
Rajeev's Curiosity 