Node.js Series: Choosing the Web Container, or actually not even having one

Hello again and welcome!

[Versão em Português]

This is the second post on my “Node.js Series” so, if you did not read the first post, here it is, enjoy!

So, as mentioned on the previous post, a lot of bumps were met when we chose to deep dive into the #NodeJS world. Coming from a Java/SOA world, the landing into the microservices and #NodeJS paradigm is not exactly as suave as one should imagine and this is not #NodeJS or microservices fault at all! Oh no! The point is that one grows so accustomed into the verbosity and impracticality of more enterprise oriented languages that simplicity may actually strike as juvenile or even plain wrong.

My first sight into this happened once I started looking for what I perceive as web containers, even though Java and .Net nowadays actually offer a wide variety of frameworks where you do not need a web container at all to see your codes attending to HTTP requests. However you will most commonly see throughout the companies still very large instances of web containers and application servers running and no one is to be hit with surprise by this. Cloud serverless solution are growing bigger and bigger these days but the majority still could not find the correct balance for their own companies into implementing those, resulting into incredibly high bills by the end of the month or simply watch their cloud adventures fail for lack of knowledge or planning.

This could not happen right now, so even though serverless is our goal from the beginning, it was the team decision to bet on the reserved instances strategy, as this was already something o common knowledge throughout the infrastructure and development teams. What that meant is that a way to run those #NodeJS codes into a reserved instance had to be found, and after some research, one framework astonishing simplicity called my attention, the #ExpressJS. The code below was exactly the first code I ran for my tests. The goal of the code was simple: Get a HTTP/REST service to responde to a call, this is how it went:

var express = require('express');
var app = express();

app.get('/hello', function (req, res) {
  res.send('Hello! Server operational!!');

app.listen(3000, function () {
  console.log('Online on port 3000!');

This is it, seriously.

That is not just the code I used on my first attempt, it is actually the request I still use to check whether my servers are up.

My second well received surprise was how much virtual memory it took for the code to run. I just ran the code here so I could the exact number: 12MB

You can actually run basically the same code without using #ExpressJS, but what makes you WANT to use #ExpressJS is the amount of services they provide on their very wide API. It is worth it. And it is free and open source! Go check it out!

It is pretty clear by now that with the simplicity of this code, a lot could be delivered with a reasonable time frame.

That certainly the only problem we faced on our mission though. A LOT more had to be figured out.

Please follow me on my recently re-opened twitter account @vrsbrazil so you can stay tuned to the rest of our efforts through #Microservices and #NodeJS .

Thank you!


2 thoughts on “Node.js Series: Choosing the Web Container, or actually not even having one”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s