Wednesday, October 2, 2013

WebSockets is the way forward

One of the great frustrations of developing any Web based software system is the request driven paradigm that the HTTP protocol demands. The user sends a request and the server responds, based on some further user interaction further requests are sent and responded to.  There are clever ways of circumventing this behaviour, but they have all been rather messy.

One big problem is that a request is generated on the client side either in HTML code or in some Javascript and then handed off to a handler on the server, there maybe many such handlers for different types of request. The response is then handled on the client side somewhere. It all get`s rather messy keeping track of where the request responses are handled and maintaining state. It reminds me of the bad old days of BASIC, where the GOTO command caused execution of the program to jump around. As code grew in complexity it became very difficult to track or debug. Developers were always discouraged from using GOTO unless absolutely necessary. The current web architecture is effectively a mesh of such GOTO statements.

WebSockets re-introduce a much more logical networking paradigm. A connection is opened, where two-way communication can take place. It is much easier to maintain state between the client and server and the resulting code is much more logical in it`s flow. Effectively a client browser session becomes a two-way messaging session, where either side can request and respond. Not only does it open up new possibilities, in terms of functionality but it also makes the resulting code much more intuitive and maintainable. A standard client-server architecture can now be applied to Web applications.

I have recently started learning Node.js and which has the added advantage of being almost entirely Javascript based. This has the added advantage of not having to switch between client and server side languages. Whilst Javascript is no doubt "quirky" (Closures, Callbacks and Functions passed around like potato's)  , the consistency gained from sticking to one language is in itself very valuable. For one thing developers don`t have to master two or more languages. Furthermore patterns used on the server side can be reused on the client side which creates a far more homogeneous code base.

Another interesting effect, is in the design phase. Whereas previously web application design involved a seemingly complex set of interactions (depending on your design methodology), it now boils down to designing a messaging protocol. For example a standard POST (sending back form data) would involve creating an HTML form with some action (a URL) and on the server side a handler to process the data and send back a response (which may have been a new HTML page or something simpler). Over a WebSocket the same form data can just be sent as a message to the server and the server can respond (or not) as defined. The actual coding although arguably slightly neater, is not the main consideration here, rather the concept, which becomes much simpler to understand and hence design.

I am very excited to see where we can take WebSockets and the effect that it will have on development time, functionality and maintainability of Web applications.

Wednesday, August 14, 2013

Client responsive design

We are no longer in control of the devices on which our media and services are being consumed. They are becoming more varied and numerous in their differences. This is not a new problem, we have been faced with this issue for some time. Previous best solutions revolved around detecting the device capabilities at the server side and making intelligent choices to render the appropriate, fit-for-purpose content on the user device.

This solution requires constant updating of the server side logic to account for all the new devices, this is a complex activity, prone to error and cannot possibly account for all the possible variations. Most recently there have been changes in the capabilities of most modern devices. (1) They have sufficient computing power to work out how to render their own content (ignoring legacy devices for now) (2) Most modern devices can run client side scripts to interpret data and render this data appropriately (3) We can define all web applications as services that create update or delete data based on some user action.

As computing power increases, the solution to the problem of an eco-system of differently capable devices is to develop the rendering technology that allows the device to render the multi-media content based on it`s capabilities. This removes the complexity of having to make smart choices on the server-side and having to maintain such heuristic information.  We are certainly not there yet. Many, many companies face the burdon of having to develop their Internet/Mobile offering a number of times to meet the demands of the current devices on the market. Often they can only target those devices that are most popular and have to ignore those that have less market share. This has the unintended consequence of further marginalizing the small players in the market, since their users cannot consume the media that users of the more popular devices can.

Although it is not in the best interest of the major players to do so, I believe that we will move to a more "open" system where media will be delivered and interpreted and finally rendered by the device. This requires some significant work in defining standards and frameworks that will allow this to happen.

Friday, August 9, 2013

Coming Soon ....

It's all about data ! Bandwidth will become more freely available at lower cost. Mobile Bandwidth will increase also with cost reduction as technology scales (4G, WiMax etc).

As this is all happening the Mobile device, Tablet, Laptop, PC and TV are converging. They are currently different devices, however the operating systems (e.g Android) and the user interfaces are going to continue to converge. Cloud (or remote) storage and services will mean that devices are less dependent on physical hardware on-site and almost entirely dependent on the Internet connection and local processor (see for example Dell's USB stick PC, Rasberry Pi or BeagleBone Black)

As the operating systems converge and thus the user experiences, developers will have more incentive to develop frameworks that work across all devices. Already technologies like WebRTC are being developed to allow complete media transfer between browsers on any device. This means file sharing, video, photo's without any special plugin software or application. Furthermore the possibility of phone calls direct from the browser (goodbye Skype ?) with technologies like SipML and Phono, built on WebRTC. So we are not far off making voice and video calls direct from our Internet enabled TV's.

The standard house or office phone is not going to be with us for much longer and the trend for telecommunications companies to handle more data rather than voice is going to accelerate. There will be a tipping point when the browser and device support is good enough to mean most households and businesses will be changing their telecommunication systems to be purely Internet (VoIP) based. How long after will most mobile calls also be delivered over IP ? Eventually new mobile specifications will be purely data based, i.e there will be no signalling and protocol for standard voice calls as there is today.

Touchscreens, gesture sensitive devices, voice recognition will integrate these new user experiences further into our daily lives, less typing and more speaking, moving ? Nod to call mother, cough to see webcam of the garden etc ...