Meanwhile, in Nodeland…

Hieronymus Bosch, "The Garden of Earthly Delights", between 1480 and 1505.
Hieronymus Bosch, “The Garden of Earthly Delights”, between 1480 and 1505.

In India, we don’t call it “Indian food’. We just call it “food”.

Rajesh Koothrappali, “The Big Bang Theory”

It was always hard for me to make choices. In the archetypical classification of ‘satisficers’ and ‘maximizers’, I definitely fall into the latter camp. I research ad nauseum, read reviews, measure carefully, take everything into account, and then finally make a move, mentally exhausted. Then I burst into cold sweat of buyer’s remorse, or read a less than glowing review of the product I just purchased, and my happiness is dimished. It sucks to be me.

It appears it can be passed on as well. My 14-year-old daughter recently went to the mall to buy clothes (alone, a rite of passage of sorts). She returned empty-handed – ‘there was nothing nice’. I think we confirmed paternity right then and there.

Of course, this affliction carries over into my professional life. Readers who follow me for a while can attest my hemming and hawing about Node.js – should I stay or should I go, what if it is not ready, what if it turns out to be just a fad, what if I read a bad review after we port everything.

At least in my professional choices I appear to be more decisive than when looking at Banana Republic sweaters. After we jumped into Node.js waters in January this year, there was no turning back. It is almost April now and my mid-term report is due.

One of the beneficial things of ending the agony and giving Node a chance is that you stop worrying about HOW things are done and focus on GETTING them done. And once you do it, like Rajesh above, Node.js recedes into the background and the actual problems you are trying to solve become your focus (you are not solving problems in Node, you are just, you know, solving problems). Xenofobic people who get to know ‘the other’ are often surprised that under the surface of difference there is a sea of sameness – people around the world have similar worries, hopes, fears and joys. In Node, you still have to worry about security, i18n, performance, code structure, user experience, and Node is not the only player involved in this – just one tool in your toolbox.

One of the most important roles in converting an organization of any size to Node.js is that of influencers. People like myself who push for it, look for opportunities to get ‘camel’s nose under the tent’ (to borrow from Bill Scott), find a crevice where Node can squeeze and then expand like ice in the road potholes (I should know, I keep avoiding them this cold March in Toronto all the time). It is a startup of sorts, an inverted pyramid that can easily fall sideways if the founder flinches or loses hope and vision.

On the other hand, it can remind you of the locked potential of the people. There is a dark lake of passion in all of us, often trapped under a layer of dealing with day to day stress and ‘things that need to be done’. It is heart-warming to see that when you succeed in winning people over to the Node.js side, the passion bursts out and they jump in with enthusiasm and vigor that is great to experience.

Example: a member of the JazzHub team heard my pitch for Node.js and started experimenting with tutorials written in markdown. Like everything else, these tutorials are currently served using JSPs and client-side JavaScript. He wrote a small Node app that takes the tutorials, converts them to HTML using a nice little module and renders them using Dust.js. He did it in one afternoon and proudly demoed it the next time we met – it is one page of JavaScript – you don’t even need to scroll to see the entire code. Needless to say, he was hooked.

One of the most important jobs of an influencer is to prevent failure on stupid technicalities. People ready to yell ‘I told you Node was not ready’ are everywhere. Node is awesome,  but we all know that a single uncaught exception can crash the process. A JEE container can throw exceptions like a leaky barge, filling up the logs, but it will stay up. In Node, it is your responsibility to prop Node up, a Weekend at Bernies’s of sorts. Judging by the frequency of questions about this behaviour, it is hard to stomach by people moving over from the other platforms.

JEE is in fact not that different. When an uncaught exception is thrown in a simple Java program with ‘main’, it exits. When the same happens in a JEE container, the runnable running in a thread exits. The thread is reset, returned to the thread pool, and the next request is passed on to another thread. In a production system with Node.js, it is your responsibility to replicate this behaviour.

It is somewhat easier to end up with an uncaught exception in Node.js than it is in Java. Due to the asynchronous nature of Node, trying to surround a piece of code in a try/catch block is often futile. Exceptions can and will escape. This is such a tricky problem that it warranted the high priests of Node to huddle recently and release a detailed and super useful document that anybody trying to write production quality Node.js system should read and internalize.

It goes without saying then that you will never run ‘node myApp.js’ except during development. In production, you want to spread out to cover all the cores of the machine or VM you are running on. You want to restart the process when it exits (and it will, repeatedly). And finally, it would help to monitor CPU, memory and throughput of each running process. We are currently looking at PM2 for this, but as always with Node, there are other ways of addressing this need.

There are other things we discovered while getting serious with Node. For example:

  1. WebSockets – one of the first things you will try to do after getting the CRUD down is server push – after all, Data Intensive Real Time (DIRT) is what initially catapulted Node into our consciousness. After you get the code working on your machine, inspect the entire path to the browser on your system – proxies are surprisingly cranky when it comes to support for Web Sockets. NGINX didn’t have it until version 1.3. If you are using Apache, note that it will not let the Web Socket connections through unless you install and configure mod_proxy_wstunnel. Of course, this is not Node-specific, but chances are you are most likely to hit it with Node because of its affinity to server push.
  2. DevOps – make them your friend. If you thought Continous Integration and Continous Deployment was a neat idea, you will find it absolutely indispensable once you start getting real with Node. A well established pattern here is a system composed of micro-services, and it is not uncommon to juggle dozens upon dozens of separate Node apps performing a role in the system. You will go mad trying to manage micro-services by hand. Of course, once you get your DevOps going, the ability to deliver new features into a micro-service with surgical precision will bring no end of joy, particularly if you are replacing a JEE pig that takes minutes to restart. Zero downtime is a reachable goal in a micro-service based system comprised of Node processes. In IBM Rational, we use Urban Code, which is natural to us since we bought them recently. Do what you need to do to go automatic.
  3. Storage – Node will make you re-evaluate the rest of your system. When I started this blog, I was characteristically wishy-washy about databases. With Node.js, we noticed that we naturally lean towards JSON-based NoSQL databases. Many people use MongoDB with success due to the smooth transition from SQL, but if you don’t like its scalability characteristics or your lawyers don’t like its AGPL license, CouchDB is an easy choice. IBM recently bought Clodant (hosted CouchDB fork with Apache Lucene tossed in) so it is hard for us to say ‘no’ to a free, Cloud-based and professionally managed NoSQL JSON DB. Again, YMMV – use what works for you, but give JSON-based NoSQL databases a try – going JavaScript all the way down is liberating.
  4. Authentication and Single Sign-On – if there is anything that will remind you of the Ford Model T (you could order it in any colour as long as it was black), it will be authentication and SSO in your system. Nothing will uncover unnecessary complexity of the authentication schemes used in the system like trying to move it to something that is not JEE-based. The complexity is normally hidden in the JEE filters, and is uncovered as soon as you try to replicate it in Node.js. It is technology agnostic as long as you use Java. The good thing is that with a sympathetic team on the other end, this serves as a catalyst to finally simplify and clean up the protocol or switch to something saner.
  5. Legal – if you are in an enterprise of any size, you will not be allowed to just use whatever you find on the Internet (even startups find software promiscuity to have side-effects as soon as they grow enough to attract legal attention). Our legal department probably hates us – the amount of Node.js modules they need to vet is staggering, but the mountain of requests is tapering down. For example, the Markdown app I mentioned earlier in the post needed to vet only the markdown module – all the other modules were already encountered by the apps before it. At this rate, the flow will slow down to a trickle soon.

So there you go – three months after our foray into Nodeland, we are lining up several new Node micro-services, the sky didn’t fall, we are learning new things every day and worry more about what we are building than how we are building it. Every once in a while we are forced to solve a problem for the first time. We agree on the best practice together, write it down for others coming after us, and move on. Where we can, we rely on the efforts of people before us, allowing suites such as Kraken.js to let us focus on what is really unique about our code, rather than the boilerplate. Our lawyers hate us, but if ‘tried and true’ was the only criterium when choosing our tools and languages, we would be still writing everything in Cobol.

If only I was this decisive choosing my last Home Theatre receiver.

© Dejan Glozic, 2014

Of Mice and Men


The best laid schemes of mice and men
Often go awry.

Robert Burns, 1785.

Dear readers of this blog, you may have noticed a lapse in the rhythm that I faithfully followed from the very beginning (a new post every Tuesday, more recently switching to Monday). You may have inferred that I am ‘recharging’, away or simply taking a holiday break.

Far from it. I had a plan to look back at the blog and the topics I have covered over the last six months. For example, looking back at the post on databases, I have second thoughts about using SQL database in a way that is a better fit for something like MongoDB. Our practical experience is that schema changes in a rapid evolution environment are a real drag and being able to evolve the data on demand in a schema-less database would be really beneficial to us.

Other posts are holding up. We are as averse to the Extreme AJAX as ever, but we are now seeing use cases where some client-side structure (possibly using Backbone.js) would be beneficial, particularly when using Web Sockets to push updates to the client. We are still allergic to frameworks and their aggressive takeover of your life and control over code. And we are still unhappy with the horrible hacks required to implement client side templating. One day when Web Components are supported by all the modern browsers, we will remember this time as an ugly intermezzo when we had to resort to a lot of JavaScript in lieu of first class Web composition that Web Components provide (you can bookmark this claim and come to laugh at me if Web Components do not deliver on their promise).

As I said, I planned to cover all that, and also lined up a holiday project. We had recently implemented nice dashboards for our needs in Jazz Platform and Jazz Hub, and I was curious how hard it would be to re-implement the server side using Node.js and MongoDB (instead of JEE and SQL DB). The client side is already fine, using jQuery, Bootstrap and Require.js, and does not need to change. I also wanted to see how hard it would be to configure Express.js to use LinkedIn fork of the Dust.js templating library. PayPal team had a lot of fun recently moving their production applications to exactly that stack, and I was inspired by Bill Scott’s account of that effort.

The plan was to write the blog post on Sunday 22nd, and play with Node.js over the next two weeks. On Saturday 21st, eastern US and Canada were hit by a nasty ice storm. The storm deposited huge amounts of ice on the electrical wires and trees in midtown Toronto where I live. Ice is very heavy and after a while, huge mature trees that are otherwise great to have around started giving up, losing limbs and knocking down power lines in the process. By Sunday 22nd 3am we lost power, along with about a million people in Toronto at the peak.

Losing power in a low rise means no heat, no Internet or cable, no cooking and no hot water (add ‘no water’ for a high rise). We conserved our phones, following the progress of Toronto Hydro power restoration using the #darkTO hashtag on Twitter (everything else was useless). Toronto Hydro outage map crashed under load, resulting in Toronto Hydro posting the map via Twitter picture updates (kudos for Twitter robust infrastructure, which is more than I can say about Toronto Hydro servers). After a while, we drained our phones. I charged my phone from a fully charged MacBook Pro (an operation I was able to repeat twice before MacBook Pro lost its juice). We had four laptops to use as door stops/phone chargers. I could read some eBooks on a fully charged iPad, but somehow was not in the mood. Dinner was cold sandwiches by the candle light. Not as romantic in a cold room.

By Sunday night, the temperature in the apartment dropped to 19.5C (that’s 67F for my American friends). We slept fully clothed. On Monday morning we packed up and went to IBM building in Markham that had power to shower, get some core temperature back, eat a warm meal and charge all the devices. We also used the opportunity to book a hotel room in Toronto downtown (no big trees to knock down power lines – yey for the big soul-less downtown buildings). When we went back home to pack, the room temperature dropped to 18C. The temperature outside dropped to bitterly cold -10C, and going to -14C over night.

Over Monday night, the power was restored. We returned on Tuesday morning, only to find Internet and cable inoperative. Estimated time for repair – 22 hours. In addition, our building is somewhat old and its hot water furnace does not like going from 0 to full blast quickly, resulting in a temperature that was 2-3 degrees less than usual. It was a matter of time until I succumbed to common cold.

Internet and cable was restored on Wednesday, 4 days after the outage started. Over the last couple of days the winter outside let up a bit, allowing the ice on the trees to melt and furnace to bring the temperature to the normal levels. My cold is on the downswing, enough for me to write this blog post. I will still need to wait for the cold-induced watery eyes to return to normal before taking the planned photos for my 2014 Internet profiles.

Why am I writing all this? Just to show you that the real takeaway message for 2013 is not horrible first world problems we grapple with daily (should I use Node.js or not, should I use MongoDB or Couch DB or just stay with RDBs), but that most of us are privileged to live with the trappings of civilization allowing us to not worry about warm water, heat, food and clean clothing. On Wednesday when my daughter was seriously unhappy that internet was not back yet, I felt a bit like ‘the most ungrateful generation’ in the Louis CK show (“Everything is amazing and nobody is happy”). As I am writing this, there are still my fellow Torontonians without power. Their houses are probably icicles by now. My heart goes to them and hope they get power as soon as possible.

As for myself, I can tell you that the fact that when you write Node.js code you may find yourself in a callback hell didn’t mean much when I was sitting in a cold room, lit by candle light and frantically refreshing the #darkTO thread, while my battery was slowly draining. A lesson in humility and a reason to count your blessings delivered in the time of the year we normally see the re-runs of It’s a Wonderful Life on TV (if you still watch TV, that is).

Therefore, all of you reading this, have a great 2014! If you are in a warm room, have clean clothes and a warm meal, and can read this (i.e. your wifi is operational), your life is amazing and you are better off than many of your fellow human beings. Now go back to the most pressing topics of your lives, like this one:

© Dejan Glozic, 2013