Wednesday, February 15, 2012

Web Applications evolution to support multiple devices as clients

I wrote this a couple of weeks back on the evolution of web applications with respect to becoming web services and the need to support multiple devices as clients. Although there are many accounts on how web services came into existence, like through the evolution of middleware, this post is mostly about how web applications turned into web services over time.


When the World Wide Web came into existence, web applications were targeted at only type of client: a web browser. Although there was some variety among desktop computers and laptops, typically they wouldn’t vary much in terms of screen size or computational power. At that time, the clients would not perform much, and the web applications would generate a synchronous server request for the majority the user actions. The server, in this case, would process the request and return a view (typically an HTML page) ready to be rendered by the browser.
Over time, however, with the evolution of technologies like JavaScript on the client side, this synchronous model where each user request would need to wait for response from the server side started to give space a model where more functionality has been moved to the client side. Requests were made asynchronously, not necessarily related to a user action, and did not block while it waited for a response.
Since operations were performed asynchronously and did not block any longer, the logic to display a user interface moved to the client side, which knew how to react to asynchronous responses and update the UI accordingly. That removed the job from the server side to take care of views for the most part, and it started being a service that would take requests on some data (“model” in MVC framework) and return status codes and potentially some more data (“model”) to display. At this point, web applications were already moving into a data oriented direction.
While applications were mostly focused on the web and on one user interface, the way requests and responses transmitted data was not very revelant and could be specific to the application or the framework used. Some web application frameworks had their specific way of perfoming asynchronous requests, and as long as a browser was your only client, that was fine.
With mobile devices like smartphones, initially the typical solution was to have a mobile version of the web site, which would perform similar actions as the main website. However, in the past few years we’ve seen the uptake of mobile applications (“apps”) due to the huge success of smartphones, which introduced different user interface on the client side. A web interface as returned by the web server no longer sufficed as that wouldn’t be the preferred interface on these devices. In order to support both a web site and a mobile application, how data would come into the service and come out would need to be at least abstracted in a way that, irrespective of the client side, we could use the same server.
In addition to that, the fact that the mobile app was built and run on a different platform was another major factor to call for the right type of abstraction. In order to fetch data from server or submit data back to server, the requirement on the server shouldn’t be too heavy, as at this point our client is no longer only a powerful desktop or laptop computer, but also a mobile device without so much CPU power memory and memory.
And not only mobile apps, but a range of different devices (like tablets, slates, large screens) and different input methods (like touch screen or sensors) accelerated even further changes to modern applications that wanted to expose their functionality to multiple consumers seamlessly. Actually, even on the same device one can have multiple experiences, like on a smartphone one can access an app and a web application through its browser, or on a desktop PC one is able to access a web site, to have a regular application, or even have a new experience with Metro-style applications in Windows 8.
The answer was that these web applications would need to be turned into web service to be consumed by these different UIs, which would perform operations on the data. And that is the context for those that want to make available a service – the direction is to expose the data in an easily consumable format, using a practical protocol, and build the different interfaces around that. If this is only used by a mobile application, only the web service will be used. If this is also a web application, some web resources (like scripts) will need to be hosted. But irrespective of your customers, a good architecture is to pick the right technologies and abstractions to be ready for these challenges and future evolution.
Post a Comment