Web Sockets: Random Number Streaming

I have recently been playing with web sockets because I wanted to get a better understanding of how to use them. A web socket is a full duplex TCP connection between web browsers and web servers. This is not to be confused with earlier techniques with similar aims like long-polling and Comet. Web sockets actually have their own RFC. They are a standard. All the major browsers have implemented it. This means web sockets are not tied to any particular language or server. Below I will show using web sockets in plain JavaScript, Node.js, and Java.

Node.js Server

Here is a Node.js server that sends a random number to everyone connected to it, every second, on the same channel. Obviously this is not that useful, but it could represent a stock price for example. I found the ws module to be easy to use for the web socket server implementation. Another module socket.io seems to be more popular but you need to use it in the client as well. For this learning exercise I wanted to use native web sockets in my client.


Java Server

Here is the same random number sender implemented in Java. I ran this on the recently released WebSphere Liberty Profile 8.5.5.2 which added a web socket feature (full disclosure I work closely with this product at IBM).


JavaScript Client

My client can talk to both servers. I probably went overboard, but I used the same MVC-style from my Client-side MVC with JavaScript blog. The important part is lines 9 through 12.


A screenshot of the client receiving random numbers from the Node.js server:

Client-side MVC with JavaScript

Continuing the JavaScript theme from my previous two posts, there was one more JavaScript idea I wanted to investigate. I have to admit, I have been confused by what I've seen in the MVC space recently. It did not match up with what I thought of when I thought of MVC. Now, I'm not a web developer, this is not a topic that concerns me on a regular basis, but I feel like any self-respecting developer should have an understanding of these sorts of things.

Reading the Model-view-controller Wikipedia article actually made a light bulb go on in my head. See, I was stuck in the past and was thinking of all three components living on the server, but as client-side technologies have matured (read AJAX) the components have shifted to the client. This makes a lot of sense as MVC does not prescribe the exact implementation, rather MVC is a design pattern.

Whether it's client-side or server-side, you still have a controller that manipulates the model and a model that updates the view. With client-side MVC all three components would be written in JavaScript. With server-side MVC the model is a JavaBean, the view is a JSP, and the controller is a servlet. The latter is how I originally learned MVC and it is shown in the image below:

So what I decided to do was create a pure JavaScript MVC example whose model talks to the Node.js app from my last blog. There appear to be many existing frameworks for this, but they all looked way overkill for such a simple example.

The HTML


It simply has a few forms to trigger the different CRUD operations.

The JavaScript


I think it seems strange I need to refer to so many HTML elements in my controller. I could initialize the controller with the IDs it needs. That would be better, the controller would be less coupled. I still wonder if I separated my components correctly though. Is there a better way?

It's Alive

I ran everything on my laptop and dropped these files into a "public" directory at the same location as my my Node.js app. They are served as static files and this conveniently eliminates cross domain AJAX issues since both are at localhost.

The result of clicking "List All Wines":

Testing (in theory)

In my first blog I talked about how to get started testing JavaScript, so naturally I wanted to see if those principles could be applied here. It seems like the model and the view (with minor refactoring) would be easily testable. The AJAX requests to my Node.js app could be mocked as I demonstrated. I would say those components turned out really well. The controller would require more effort. I would have to pass the controller a mock view and mock model, but it's definitely possible. I think this conclusion gives merit to the design even though this was a simple example. I like the way it separated the unrelated parts of my code.