Digressions of a research engineer

Node.js Makes You Strong... Within Minutes

I’ve never been much of an “interpreted” languages guy. I’ve grown up
with C, C++ and Objective-C, OpenGL, GTK, Qt and Cocoa, and have
always fancied performance over simplicity, compilers and linkers over
interpreters, even though I must admit that one can see a certain
beauty in low level languages, I still remember that I use to read the
Free BSD kernel source code on the bench of my university.

However, and especially, when it came for the web, I have always
picked up the right languages and schemes: HTML, Javascript and CSS,
RESTful APIs and MVC patterns. That gave me a medium experience in web
development, but also introduced me to other interpreted languages
such as Python for the Django framework, and most of all, Ruby for the
RubyOnRails framework.

With such achievements as Electron, Atom and especially Node.js
together with its huge package system, npm, I’ve come to reconsider
Javascript as a real option for whatever development I want to start,
especially when it involves a hybrid infrastructure (such as web
services or so).

Unsurprisingly, I came to learn Javascript more in depth when using
Qt’s QML, and reading the excellent book “Eloquent JavaScript”:
http://eloquentjavascript.net.

Recently, I came to consider the refactoring of a significant
scientific application on bio mechanical models that uses CORBA in a
remote-address space configuration, essentially to make Remote
Procedure Calls (RPC), for which CORBA is way too heavy and difficult
to maintain. Here came the thought of JSON-RPC, which seemed like a
lightweight, cross platform and simple alternative that fits the needs
of this application infrastructure. That is to say that JSON-RPC calls
are a design, a formalization, a protocol, that can be achieved with
many languages, including C/C++ and Javascript, which is enough in my
case.

So I gave Node.js a sceptical look, with its shy 37 classes (as of
v6.3.1), I’ve counted them all ;–)

At first look, it reminded me of the C/C++ wrappers I used to generate
for my own C++ frameworks using the excellent SWIG, but with an intent
over the operating system primitives, with classes such as Buffer,
Console, FileSystem, Path, Process, Readline, Stream,
ZLIB and so on. So far so good.

Also, it has a serious concern on the web, with its HTTP, HTTPS or
Net classes. The “Hello World” example is, by the way, a web server
implemented in no more than a few lines. At this point, I remembered
the burden of installing the right ruby version in order
to get the right RubyOnRails version that fits the dependencies
needed. As an example, thanks to rbenv, I have many ruby
installations: one for my Octopress instance, another one, up to date,
for my various packaging scripts. If Gemfile(s) exist, they do not
prevent you from installing many versions of ruby.

Once the “Hello World” example run, after a brew install node (which
gives you npm), I focused on my current problem, which was first: RPC
calls, then: a web front end to display current calculations and
results. So I dug up the plethora of packages available and choosed
the one I preferred (for the mention, the one that inherits from the
“native” http server implementation, as to know: jayson).

After 30 minutes of googling and reading, I had an RPC mechanism that
worked, using two procedures, namely an addition and a subtraction, as
a proof of concept for more complex implementations, comforted by the
fact, that using Node.js, I have a Process class (as well as Cluster
and Stream ones) that can make benefit of different binaries.

When starting a project using Node.js, it is recommanded to start with
the following command:

1

$ npm init

This command prompts for some values and generate a file called
packages.json that contains many information on your project but
also its eventual dependencies. Here is mine.

12345678910111213141516

{"name":"odin-js","version":"0.0.1","description":"Poc at providing both JSONRPC clients and servers.","main":"server/index.js","scripts":{"start":"node server/index.js"},"author":"Julien Wintz","license":"BSD-3-Clause","dependencies":{"express":"latest","jayson":"latest","ejs":"latest"}}

Many additional fields can exist, refer to the documentation for their
description. What is relevent so far is the fact that my packages
files sates that my project depends on express, jayson and ejs
(which stands for embeddedjs). So the next step is to install these
dependencies that will end up in a directory at the root of your
project named node_modules (I’ve tried to change its name and
location but it is explicitly stated in the documentation that it is
strongly advised not to do so).

1

$ npm install

As this point, npm start will start to interpret
server/index.js. As my full project hierarchy is as follows.

So let’s start at looking the client side. In its minimum state it
consists in setting up jayson as to connect to a host, and to
perform to minimal RPC calls, with a callback that prints out the
result of the call.

The code is self-explanatory. We setup a router that gets “/” to serve
the index.html page (that is the expressjs part), using “ejs” as an
view engine (that is the embeddedjs part), and everything else as a
404.html page.

Using embeddedjs, we have an acces to our model, so we will be able to
display the current value after our remote procedure calls, that is to
say, that within our index.ejs file, we can inject javascript values.

This is a simple as that! Note the use of the <% include ... %>
directives that allows for partials, other parts of the html document
that are repeated for multiple files (namely index and 404 in our
case).

For the sake of completeness, here is the header.ejs, where we retrieve bootstrap by the help of a Content Delivert Network (CDN), and the footer.ejs that finalizes the HTML page.