Perhaps it’s because I’ve been around IT for quite a while: since the late 1970s in fact. Perhaps I’m just jaded and cynical. I’ve watched so many technologies come and go, and I’ve watched IT trends circling in and out of fashion. I’m sorry to say that most times when the “next big thing” coming along, I watch the new guys first really excited about it, watch it progress to either dying a death or becoming “mainstream” and therefore “safe”, at which latter point the management consultants start recommending it to their customers. Normally, throughout the process, I feel completely underwhelmed by the whole thing. What they’re all raving about is normally, in my opinion, nothing to get excited about.

Suffice to say, I’ve never been interested in technologies as fads or fashions, or as a means of furthering my career in IT. I’ve always been interested in technologies that are capable of doing what they really should the there for: allowing me and others to achieve more with less effort. Just like my colleague back in Hull University who first got me into programming in the first place used to say to me: at the end of the day I’m lazy. I really don’t want to be laboriously doing stuff that the damned computer can be doing for me instead – that’s its job! Yet, so often, I see technologies that require too much effort, require me to instruct the computer about what I want to do in far too minute detail, require me to state essentially the same thing over and over again in a ludicrously redundant way. Too many steps involved, too much work. I like instant gratification. I’m impatient and lazy. If there’s one thing I hate more than anything else, it’s writing more code than I think I should need to write.

Every now and again, though, along comes a technology that hits me between the eyes. I give it a try and very soon a smile appears on my face and/or I mutter to myself: “Holy s***t!”. “Getting” Mumps way back in the early 1980s was probably my first experience of this. Seeing that first web page coming up in a flaky Cello browser (http://en.wikipedia.org/wiki/Cello_(web_browser)) on my home PC in about 1993 was the second, followed by jumping onto Javascript when it was first released by Netscape around 1994/5.

Lots of tedious, underwhelming technologies have gone under my bridge since then, and it wasn’t until about 2 years ago that I had another “Holy s***t” moment. I’d been watching a video of Douglas Crockford’s (http://en.wikipedia.org/wiki/Douglas_Crockford) latest video on Javascript and he started talking about something called Node.js. I’d seen this technology being mentioned and talked about here and there but hadn’t spent any time investigating it. However, here was the main man, the Javascript guru, getting excited about it. Time, therefore, to investigate, and – wham! – I’m hooked!

I shalln’t dwell here on what Node.js is. A quick Google search will take you to all the information you need on it. Suffice to say it’s a server-side implementation of Javascript. Basically they’ve taken Javascript, whose natural home was previously the browser, and moved it server-side, to create a programming language ideally suited to network programming. It’s event driven, all I/O (and resource handling generally) is asynchronous, and, courtesy of Google’s V8 Javascript engine, it’s one of the fastest, most scalable technologies I’ve come across since Caché and GT.M (eg see http://highscalability.com/blog/2012/10/4/linkedin-moved-from-rails-to-node-27-servers-cut-and-up-to-2.html).

A key reason for my excitement about Node.js was the timing. Taken in isolation, there’s maybe nothing too exciting, per se, I suppose, about Node.js. But my discovery of Node.js coincided with the peak of the early interest in the NoSQL movement.

In my opinion, the NoSQL movement was the best thing that could have happened and it was long overdue. For years – since the early 1980s in fact – “experts” in IT had deemed that the only database model worth giving any consideration to at all was the relational model. Anything else was looked down on as some antiquated and worthless idea that should have been confined to the IT dustbin of history years ago. This “mainstream” thinking, based more on fad, fashion and industry inertia than on technical merit, was one of the factors that kept the Mumps database technology in the shadows for several decades. Indeed, it’s a sad fact that many’s a great and highly efficient and effective Mumps-based application has been expensively ripped out and replaced by an underwhelming half-baked “mainstream” technology as a result of “safe” recommendations of a management consultant: “well there’s your problem – that old Mumps stuff. You need a proper database, mate. I’m a consultant guru who specialises in databases, and I’ve never even heard of Mumps, so go figure!”

So the NoSQL movement that burst onto the scene in 2009 came as a breath of fresh air. Suddenly the relational database was no longer king. Suddenly other database models were in vogue: key value, document, columnar, graph. An lo and behold, those same management consultants who, years earlier, had been responsible for chucking out Mumps databases, were starting to recommend to their customers that they really needed to be looking at NoSQL databases. The irony was, of course, that the Mumps database they’d been recommending to be replaced a few years earlier was, in fact, a truly great NoSQL database that had pre-dated the NoSQL movement by several decades (http://www.mgateway.com/docs/universalNoSQL.pdf).

So I saw the growing wave of interest in NoSQL as a great way of bringing the Mumps database – whose primary modern implementations are Caché and GT.M – back into vogue. There was a major stumbling block, however. Pretty much every other database, the new NoSQL ones included, are just databases, and are accessed via most modern computer languages. Mumps, however, has its own integrated language that is used to access and manipulate the database. Unfortunately, as I’ve discussed elsewhere in this blog (A Case of Mumps), mention the word “Mumps database” and very soon someone would poison the idea by pointing to numerous articles rubbishing the Mumps language. No matter how good or powerful the database, it was being subverted by opinion about its associated language.

Many who know Caché and GT.M will, of course, be thinking: but it’s been possible for ages to access the underlying Mumps database from mainstream languages. That’s true, and, for example, our own company has created numerous language bindings for GT.M as part of our MGWSI technology (eg PHP, Python, Ruby, Java, .Net) (http://gradvs1.mgateway.com/main/index.html?path=mgwsiMenu). However, in my mind, those “mainstream” languages have never quite gelled with the Mumps database – it’s difficult for me to put my finger on it and define properly what I mean: it’s more a gut feel I have about them.

But along comes Node.js and the possibility of server-side Javascript in a massively-scalable, super-fast environment. Javascript, it turns out, has many of the characteristics I’ve always loved about the Mumps language (see A Case of Mumps). They are both what I describe as “fast and loose”. I can do lots of stuff very fast with them both. I don’t end up fighting them and they don’t fight me. I guess it’s because they both allow me to be lazy and give me that instant gratification.

Additionally, it was clear early on that Node.js was going to become massive. Sure enough, that’s come to pass. A year ago, Javascript surpassed Ruby on Github as being the most popular Open Source development language: all the result of Node.js. The trendy language for young developers to learn is now Javascript. Microsoft have been closely involved with the development of Node.js for quite some time. It’s available for Windows, OS X and Linux. Put simply, Node.js is huge, and still gaining momentum. Expect to see the management consultants recommending it as a “safe” bet any time soon.

And so we have the potential for a perfect marriage: Node.js providing Javascript as a scripting language for the universal NoSQL database.

I’ve done a lot of work in this area: I think it’s fair to say I pioneered the whole idea of integrating Node.js with Caché and GT.M. You’ll find my work on Github (https://github.com/robtweed). It’s proven to me that the combination is extremely potent and powerful. Probably the coolest thing I’ve managed to achieve in this area is to have persuaded InterSystems to include a native Node.js interface to Caché . Actually, that interface is the work of my colleague Chris Munt, but carried out on behalf of InterSystems. InterSystems first released it as part of their free Globals database (http://globalsdb.org/), but they’ve now made it available for their latest version of Caché.

The really special aspects of this Node.js interface to Caché are:

it makes use of a very high-performance , low-level call-in interface to Caché’s global database engine;

Caché runs in-process with Node.js, so there is no network-layer bottleneck. It’s blindingly fast. It’s such a close binding that Javascript becomes the scripting language for Caché;

Chris provided synchronous versions of the APIs which make it possible to build properly-layered high-level APIs on top of the low-level ones provided by the raw Node.js/ Caché interface. For example, I’ve implemented a persistent XML DOM, with the DOM modelled as a graph database in global storage, and manipulated via the DOM APIs implemented in Javascript.

These things add up to something very special, and something where the whole is definitely greater than the sum of its parts.

Whilst this ideal level of close integration is currently limited to the proprietary Caché, there’s no reason why a similar in-process interface couldn’t be built for the Open Source GT.M. I’m hoping someone will get on and do this. In my opinion this model represents the future for the Mumps technology: a super-fast, highly-scalable, ultra-flexible NoSQL database, accessed by the hottest and coolest, most trendy language out there. Instant gratification guaranteed.

Holy s**t!