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 Socket.io 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.
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 Socket.io 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.
help full article trevor attridge
ReplyDelete