• Home
  • blog
  • Creating a Battery viz Using Node.js: Getting Started and Server

Creating a Battery viz Using Node.js: Getting Started and Server

If your initial reaction to the title of this article was something like WHAT?, I want to reassure you. You don’t have to take my word for it! What I’m going to do is to show you how to build a fine piece of software that can run on multiple operating systems, interact with them and present the results in a pleasant way. The whole task will be achieved by using JavaScript and a small amount of bash/powershell commands.

Said that, you might be wondering why I want to make this experiment. It might come as a surprise, but “winter nights are long and lonely and I needed something to kill some time” is not the answer to this question. Maybe something on the line of “I wanted to refine my skills and master JS” would be closer.

Although this project does not carry a hight value on itself, my humble opinion is that it will:

  • provide you the skills (and some basic design) to build a RESTful service and any interface you’d like for your favourite OS
  • let you focus on cross-OS compatibility
  • introduce you to valuable design patterns for JavaScript and useful Node.js modules.

With this in mind, let’s start talking about the server. What we need is to create a (RESTful) service that provides us, in real-time, the last readings from our OS.

Why do we need a server? And why RESTful?

The answer to these two smart questions is simple. Firstly, we need a server because, for security reasons, there is no way a browser would allow you to execute a command on the OS (I bet you wouldn’t be too happy if any creepy website was able to erase all your files, would you?). Secondly, we’ll have a RESTful service because there are several advantages in using REST interfaces. This is out of our scope, but I’ll point interested readers to a few good resources to learn more about this topic at the end of this article.

Now, what we want is at least one endpoint that can be called from any service over the HTTP protocol, hence decoupled from the actual representation of the data it’ll provide, and in response sends data back to the caller.

To send this data back, we’ll certainly need to agree on a format. We could send back some raw text and leave parsing to the client or, as an alternative, we could send structured data (using XML for instance). I ended up choosing JSON. The reason is that we’ll have structured data but far less redundant than XML. Note that by agreeing on a format for the data we introduce a certain coupling for the client, that now has to adhere to our formatting. Nevertheless, this choice gets several advantages:

  • We can specify the format as part of our interface: clients naturally have to adhere to APIs of any service they use (for instance, the name of the methods or the endpoint exposed) and as long as we don’t change the format, there will be no difference. Obviously we should still think this format through before hitting version 1. In fact, we should (almost) never change a public interface in order to avoid that clients will be broken.
  • We would sensibly slow down clients by delegating parsing to them.
  • We gain decoupling from different OSs by providing a common format for all of them. To support a new OS, all we need is an adapter for the data we receive from it.

At this point, we need to start talking about how and where we’ll get the data we send to the client. This is maybe the trickiest part of the game, but luckily there are plenty of modules for Node.js that allow our server to talk to our OS, and even understand which OS is running on our machine.

Continue reading %Creating a Battery viz Using Node.js: Getting Started and Server%