The Case for IRIS and JavaScriptContestant

Introduction

My guess is that most IRIS developers create their applications using its native ObjectScript language or, if using an external language, then most likely using either Java, Python or perhaps C++.

I suspect that only a minority have considered using JavaScript as their language of choice, which, if true, is a great shame, because, In my opinion and experience, JavaScript is the closest equivalent to ObjectScript in terms of its ability to integrate with the IRIS's underlying multi-dimensional database. 

In this article I'd like to lay out the case for JavaScript as a first-class language for IRIS. You never know: I might even change a few made-up minds on the issue!

Server-Side JavaScript

JavaScript was famously written in just 10 days by Brendan Eich in 1995 for the then Netscape browser. It is now, of course, the de-facto language for client-side web applications, supported natively by all mainstream web browsers.

An early incarnation of server-side JavaScript was created by Netscape around the same time, but it wan't particularly successful.  It wasn't really until Ryan Dahl created Node.js in about 2010 that server-side JavaScript really took off and became "a thing".  More recently a serious competitor to Node.js - Bun - has emerged: its main advantage over Node.js is its stellar performance.

So, of course, when I refer to the use of JavaScript with IRIS, I'm meaning server-side JavaScript, using either Node.js or Bun.

JavaScript has many detractors: you often hear criticisms that it's somehow a "toy language" or that it has too many quirks and idiosyncrasies to make it a viable language for serious production systems.  Most of those criticisms, however, are unfounded if you take a close and serious look at JavaScript.

Yes, JavaScript does have its quirks, but they are all avoidable.  As a language, it actually has some incredibly powerful features such as closures and the ability to pass functions as arguments into other functions.  It's also got everything you need for modern event-driven programming.

It's fast - particularly when you see Bun in action.  And it's massively scalable (an interesting example: apparently the recent Superbowl portal back-end was built on Bun and handled the crazy volumes of traffic without barely breaking a sweat).

The other key benefit of server-side JavaScript is that the full front- and back-end application stack can be developed with one single language skill and resource: no need for separate teams of developers with different language skills and expertise.

Why JavaScript is a Good Fit for IRIS

IRIS Language and Data Characteristics

I won't go into historical details in this article, but I think it's fair to say that IRIS's native language - ObjectScript - was designed around the idea of an intimately close relationship between data that was in-memory and data that was on disk, with the language able to manipulate both in a near-identical way.  The native data structure is hierarchical and is conceptually identical whether that data is in-memory or on disk.  As far as the language is concerned, the only difference between an in-memory "local array" and and on-disk multi-dimensional data store (historically known as a Global) is a ^ symbol.

The native IRIS language is interpreted and is also inherently loosely-typed - everything is essentially strings or numerics.

ObjectScript is also extremely fast.

And finally, the multi-dimensional data store is schema-free.

JavaScript Language and Data Characteristics

Now let's examine the equivalent features of JavaScript.  Of course, JavaScript doesn't natively include a database (but more on that later!)

However, as a language, it has interesting similarities: it is interpreted, and is loosely-typed.  If you're comfortable working with ObjectScript's loose typing, you'll be comfortable with JavaScript's approach to types.  The strict typing zealots won't like either of course, but some of us aren't in that camp!

The native data structure of JavaScript is its Objects which are inherently hierarchical and schema-free. 

In fact JavaScript's native data structure is now ubiquitous outside of JavaScript itself: JSON is now pretty much the de-facto data interchange structure that is used whatever language you use, and yet the acronym tells you its origin: JavaScript Object Notation.  

For most/many languages, the parsing and serialisation of JSON data can be something of a struggle.  For JavaScript it's the native data structure and parsing and serialisation is fast, efficient and simple.

In terms of performance, in my experience JavaScript is on a par with IRIS ObjectScript.

JSON and Multi-Dimensional Data Storage

Whilst IRIS now has its own specialised JSON storage capability, the similarities described above actually make the mapping of all but the most complex JSON data in and out standard IRIS multi-dimensional data storage a fairly trivial and efficient exercise.  Put simply, if ever there was a database designed for the storage of JSON and persistence of JavaScript Objects, it would be IRIS! 

Making the Connection: the Challenges

So how do you use JavaScript with IRIS, and how can you achieve a seamless mapping of in-memory JavaScript Objects with on-disk JSON storage in IRIS multi-dimensional storage?  For example, would it be possible to envision a JavaScript equivalent of the ^ symbol to denote in-memory versus on-disk objects?

You can make a start by trying out the IRIS Native API for Node.js.  However, you'll discover that the integration it provides is very basic - too basic for the kind of things I'm envisioning, and, as its name implies, is limited to the use of Node.js.  It's also not a very performant interface: thereby losing and wasting most of the inherent performance of the JavaScript language.

What's needed, then, is an interface between Node.js and Bun that can access IRIS multi-dimensional storage with a similar level of performance to IRIS ObjectScript: on even relatively basic hardware that means being able to handle millions of database nodes representing key/values per second.

There's also another piece of the puzzle that needs addressing if we want to use JavaScript as a first-class language for IRIS: JavaScript is a single-threaded language.  To support concurrent use by multiple users, the standard approach is to access resources such as databases and files via asynchronous callbacks, all from a single process with a single thread of execution.  That's a very unusual architecture and a tricky bed-fellow when using the IRIS database which is designed for synchronous use from within a multi-threaded architecture for handling concurrency.

The Solutions

It's these challenges that have interested me ever since Node.js first appeared, and suffice to say they are all possible to address.  How that's done is beyond the scope of this article, but almost all my work these days involves the use of JavaScript and the use of persistent JavaScript Objects held in multi-dimensional storage and I've written lots elsewhere about how the challenges can be addressed and the resulting benefits achieved.

To me, it's all about a perfect marriage of a modern language with all sorts of incredibly powerful features, yet having all the productivity characteristics I loved about ObjectScript, with a powerful, incredibly fast and scalable schema-free database in which I can save, access, manipulate and retrieve JavaScript objects seamlessly and directly from disk.

The JavaScript equivalent of ^ to distinguish in-memory and on-disk Objects?  Yes, it can be done, and it's like magic to see it in action.