My new project has me looking at the use of Node.js and socket.io to send data between two (or more) independent web pages. Let’s not worry about why for now. The point is, I want to be able to have web apps receiving and sending streams of data without having any other awareness of each other. Node is great for this, and socket.io provides the abstract mechanisms for establishing connections (streams) and sending JSON style data structures to and from the server, very quickly. The server effectively becomes the telephone exchanges between the two, rather than adding any actual fuctionality to the distributed app. There are a couple of roles Node has to perform in order to enable this: handshake and setup of the connections (both for socket.io’s needs and for the application itself), and then to simply connect messages or streams from sending web app to receiving web app.
The js code in the web page has to be socket.io aware, but you also have to establish a kind of protocol of your own about what messages are going where, and what will happen to them. Lots of handshaking and console.logs needed to debug this, and for me, understanding just how Node and the socket.io scheme works in the first place.
This has all been a huge learning curve for me, as a newbie even to any web programming. I am probably stretching myself a bit, but it is a very current way of looking at the web, so it seems to be worth the investment.
One of the biggest challenges I find is the idea of asynchronous, event based programming. You just cannot make assumptions about the order of code in the way you can in a strictly linear program. But there is nothing stopping you from writing in a linear way, only to discover certain lines are never reached or not run when you expect them. I get the reasons why asynchronous is good, but it is hard to read and hard to code, for me at least. Assuming I get this enough to get my Node back end and JS front end to talk to each other (tick), I have a new problem. I want to generate some streams of data in a blocking, tie-up-the-CPU way on my front end. This does not really work with the rest of the model, so now I have to consider the ways in which I can write JS loops as asynchronous code with callbacks. I have not yet tinkered with web-workers. The time may have come.
I am pleased with where I have got to today in a purely academic, UoD sense. But as with much of my learning, it just uncovers a lot more that I don’t know.
Sources I have used for Node, socket.io and asynchronous coding generally.
A very simple, newbie friendly, demonstration of Node and realtime data in the client from Scott Blaine’s Blog
A discussion of the benefits of Node and streams generally
Socket.io official site’s own quick-start guide to using socket.io
And of course my notes from CodeSchool Node course: http://node.codeschool.com
A discussion of asynchronous and event based coding
All about web workers
About the deferred promise model of asynchronous JS programming
No comments yet.