Well of course you can use the mg-dbx interface for IRIS which is available on NPM and which provides equivalent functionality to the Native API interface.

https://github.com/chrisemunt/mg-dbx

Otherwise, in terms of complexity of getting IRIS working with Node.js for multi-user environments, the qoper8-fastify approach I've described makes it about as simple and easy as you can get, and all you need to focus on is the logic for each REST request handler and how it interacts with and uses your IRIS data.

Use glsdb's even higher-level abstraction and it becomes even simpler for a JS/Node.js developer

https://github.com/robtweed/glsdb

So the solutions are all there.  It's the means to communicate at appropriate scale that's missing.  I've tried relentlessly over recent years, but a single lone voice doesn't get things very far, sadly.

I wonder how many people are actually using Node.js with IRIS? My hunch is, sadly, not many, yet JavaScript is a really great modern alternative language to ObjectScript, and IRIS is potentially a really natural database for JavaScript/Node.js deveopers.  How to get IRIS developers to check out and adopt Node.js, and how to get Node.js developers to check out and adopt IRIS?  It's an incredibly potent combination for anyone willing to try!

Hi Ward - I too have wondered about the built-in IRIS Native API for Node.js.  It does, indeed, appear to be synchronous which is good in that it makes it easy to use and understand, but very bad for the reasons you describe that relate to Node.js concurrency, and effectively unusable as it stands for production multi-user settings.

Conversely, I know from experience that asynchronous versions of the APIs can tie you in horrible knots, and if you need to use locks or transactions, the fact that every concurrent user is sharing the same physical thread of execution makes them pretty much impossible to use.  So having async versions of the APIs isn't really the solution either.  So does this mean the Node.js API is effectively unusable?  No - there's a solution!

First some quick background: I've grappled with and specialised in Node.js integration since the earliest days of Node.js (all the way back to 2010/11!), and long ago concluded that the best solution was a queue/worker architecture, whereby access to IRIS could be limited to Worker processes, within which only a single task would execute in isolation.  Remove the concurrency issues of Node.js and you'd have an ideal scenario of being able to use synchronous APIs to access a database such as IRIS without any downsides.

I even wrote an article about this: 

https://medium.com/the-node-js-collection/having-your-node-js-cake-and-e...

That article describes my solution in the context of our QEWD.js framework - now, to be fair, QEWD is a somewhat monolithic, all-or-nothing framework/solution which locks you into certain key building-blocks (eg Express as the web framework, mg-dbx for the Node.js APIs to IRIS etc) and particular ways of working.

Recently, however, as a spin-off from other stuff I've been working on, I decided it was time to revisit the core ideas of QEWD and not only modernise its logic to use the latest JavaScript constructs and features where relevant, but also break it down into a set of "building blocks" which would allow people to customise how they use and assemble them - a "buffet menu" instead of a "set meal" as it were. 

One such building block is the queue/worker piece, now named QOper8: actually there are two variants - QOper8-cp for Child Process Worker and QOper8-wt for Node.js Worker Thread Workers.  Both work identically and have almost identical APIs and configuration.  You can read about them here:

https://github.com/robtweed/qoper8-cp

https://github.com/robtweed/qoper8-wt

So these provide a potential queue/worker solution for making the IRIS Native API for Node.js acceptable and workable in a multi-user Node.js environment, but how, you might ask, would you make use of them in practice?  What, for example, would be a likely use-case?

Well, the most common scenario for using Node.js in such a multi-user environment is as the back-end of an interactive web application or a REST-based web service.  Node.js excels at this: it's exceptionally fast, highly scalable, lightweight in terms of hardware resource demands.  A real benefit is you have a single language - JavaScript - describing both the front-end and the back-end logic.

Ask any Node.js practictioner these days what web framework they use and they'll pretty much all now say the same thing - something called Fastify, which, as its name implies, provides an extremely fast web server platform.  Furthermore, Fastify has been designed to be easily extensible via a standardised plug-in architecture. 

I've therefore used this to create a Fastify plug-in for my QOper8 modules, which, as a result, makes it extremely quick and simple to build out a Fastify/QOper8 back-end whereby incoming HTTP/REST requests can be automatically forwarded to QOper8 which queues and dispatches each request to be handled in isolation within the first available Worker process.  You can read about this plug-in, known as qoper8-fastify, here:

https://github.com/robtweed/qoper8-fastify

So then take this one step further: initialise each QOper8 Worker Process by loading the IRIS Native API for Node.js, connecting to your IRIS system and making the APIs available for your handler methods, and you have a high-performance, highly scalable back-end with direct access to your IRIS database, and allowing all your logic to be written in JavaScript (actually you can even use the Native API to invoke ObjectScript functions and procedures on your IRIS system), and safely using the synchronous IRIS Native API for Node.js in a production multi-user environment. 

If you want to find out more about how you can implement such a solution, I've written it all up, complete with a simple worked example that you can easily extend to build out your own web/REST back-end solution:

https://github.com/robtweed/qoper8-fastify/blob/master/IRIS.md

Enjoy, and do provide me with feedback!

If you're wanting to use IRIS with Node.js, you might want to also look at QEWD.  Rather than using the IRIS Native Node.js APIs, it uses the alternative Open Source mg_dbx interface and its APIs (https://github.com/chrisemunt/mg-dbx), and QEWD creates an architecture that allows the synchronous APIs to be used safely (via a queue/dispatch architecture which gives QEWD its name).  With QEWD and the mg-dbx interface, you can run Node.js on either the same machine/system as IRIS, or on separate machines/systems via a networked connection, and you can run QEWD either as a native installation or you can use a pre-built/configured Dockerised version, so it's extremely flexible.

QEWD can be used to develop both Node.js REST services and interactive web applications, the latter connecting users' browsers and your back-end over WebSockets.  QEWD does all the tricky technical work for you, leaving you to just focus on your application or API functionality.

Here's a few ways to get started with QEWD:

Native IRIS/QEWD: https://github.com/robtweed/qewd-baseline/blob/master/IRIS-WINDOWS.md

Using Dockerised IRIS: https://github.com/robtweed/qewd-baseline/blob/master/IRIS.md

Networked connection between QEWD/Node.js and IRIS: https://github.com/robtweed/qewd-starter-kit-iris-networked

Although it allows use of IRIS via its standard Object and SQL architecture, and APIs QEWD can also abstract the IRIS database as persistent JavaScript Objects/JSON, which allows you to access and use an IRIS database in a completely unique and powerful way that makes it a natural fit with JavaScript.  To explore this aspect of QEWD with IRIS, check out:

https://github.com/robtweed/qewd-jsdb-kit-iris

These repositories and the documentation/examples/tutorials they contain should get you started

Rob

Something that isn't, I think, widely known/realised is that if you install a 64-bit version of Linux on a Raspberry Pi (eg Ubuntu 20.04 64-bit for ARM), and then, if you have an M1 Apple Mac, install Parallels on it and install a Ubuntu 20.04 VM, the two environments (Raspberry Pi and M1 Mac VM) are functionally identical.  Literally you can move the exact same code from the M1 Mac VM to the Raspberry Pi and it will work.  Make it all even simpler by then installing Docker on both the Raspberry Pi and the M1 Mac VM, and a container built on one will, again, work identically on the other.

The only difference, of course, is the massively faster speed of execution you'll get on the M1 Mac (and the huge difference in cost!).  

I've had a lot of fun with the various QEWD-related Docker containers I've created: there's something quite magical about watching a container built on the M1 Mac working, without any change, on a Raspberry Pi!  It's what, IMO, makes ARM-64 a very interesting platform for the future

Take a look at QEWD.js - it works extremely well (and fast!) with IRIS on the Raspberry Pi, and you'll be able to build REST APIs and interactive apps using it.  See:

https://github.com/robtweed/qewd

but also look at the QEWD-related postings I've put in here on Open Exchange:

https://openexchange.intersystems.com/package/QEWD-js

https://openexchange.intersystems.com/package/qewd-jsdb-kit-iris

https://openexchange.intersystems.com/package/qewd-conduit

Take a look at the ObjectScript functions $NAME, $QUERY, $QSUBSCRIPT and $QLENGTH

https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=RC...

The simplest way is to use QEWD.  It will save you a lot of time trying to sort out all the moving parts required.

Start here:

https://github.com/robtweed/qewd

and check this out: https://groups.google.com/g/enterprise-web-developer-community/c/HQK-THx...

Rob

We have two Open Source products that will look after JWTs for you in the ways you are asking about (ie REST services with IRIS):

- QEWD, if you want to implement everything at the back-end in Node.js / JavaScript

- mgweb-server if you want to use ObjectScript logic for your back-end logic

For QEWD and IRIS, see:

https://github.com/robtweed/qewd-starter-kit-iris-networked

In particular for REST services, see:

https://github.com/robtweed/qewd-starter-kit-iris-networked/blob/master/...

and specifically this section:

https://github.com/robtweed/qewd-starter-kit-iris-networked/blob/master/...

For mgweb-server, see:

https://github.com/robtweed/mgweb-server

specifically using with IRIS:

https://github.com/robtweed/mgweb-server/blob/master/IRIS.md

and within that document, this section on JWTs:

https://github.com/robtweed/mgweb-server/blob/master/IRIS.md#using-json-...

Rob

If it was me I'd use the persistent DOM of QEWD-JSdb

https://github.com/robtweed/qewd-jsdb/blob/master/DOM.md

QEWD includes access to this.  

Rob

I would add that it is worth remembering that you're not limited to using the technologies built-in to IRIS (or Cache for that matter).  There are also proven Open Source alternatives available for building web applications that use IRIS/Cache as a back-end environment (or simply an ultra-high-performance database).  So, if you want to develop applications in JavaScript/Node.js and use IRIS as a persistent JavaScript Object store, QEWD should be on your list.  Alternatively, check out mg_web and mgweb-server as an alternative to the built-in REST solution.  For more info see:

https://github.com/chrisemunt?tab=repositories

https://github.com/robtweed?tab=repositories

https://github.com/robtweed/qewd-conduit/blob/master/IRIS-windows.md

You might want to take a look at QEWD?  See my recent posting in the article on the IRIS Community Edition for AWS

See also 

https://github.com/robtweed/qewd

https://github.com/robtweed/qewd/tree/master/docker-server-iris-ce-aws

https://github.com/robtweed/qewd/tree/master/up/docs

For an example where it's being used in the NHS (in a pilot) with both desktop and mobile devices: https://ripple.foundation/

Rob

Ward is correct - ewd-document-store is the way to go.

For background on this module, the thinking behind it and some of the considerations you need to be aware of when using it (which ultimately explain what QEWD.js is all about and why it is what it is), see this presentation that I gave a couple of years ago at the UK Symposium:

https://www.slideshare.net/robtweed/data-persistence-as-a-language-feature

Also see here for pointers to further info on the persistent JSON / Document Database abstraction provided by ewd-document-store:

https://github.com/robtweed/qewd/blob/master/up/docs/InteractiveApps.md#...

Note that ewd-document store will work with any version/build of Cache, Ensemble or Iris

Rob

Everyone else makes Node.js modules such as these available via NPM. 

The version of cache.node must match:

- the OS you're using (in your case 64-bit Windows)

- the version of Node.js you're using - you haven't specified that

Unfortunately InterSystems so far haven't done the sensible thing and publish cache.node in NPM, so you may or may not find that the versions of cache.node included with your Cache distribution support the version of Node.js you wish to use.

As far as the underlying database storage engine is concerned, yes:

https://www.slideshare.net/robtweed/ewd-3-training-course-part-18-modell...

http://mgateway.com/docs/universalNoSQL.pdf

Chris Munt would be the person to ask, but I'm not aware that the lack of a resolution to the bottleneck issue is anything to with security - more that Google don't "get" the issue and see it as a priority, since it's an unusual requirement.

Anyway cache.node is an official InterSystems interface so why not just use it instead of rolling your own?  Ideally ISC should be pushing Google to fix the bottleneck.

Just to clarify - despite the bottleneck I've mentioned, cache.node will be a LOT faster than a TCP-based Node.js interface.  cache.node runs in-process with the Node.js process, and uses the Cache call-in interface.  As a result, QEWD is very fast and my guess is that it should outstrip an equivalent app using CSP.

Also, note that with QEWD, the socket.io connections are between the browsers and the QEWD master process, and NOT the child/worker processes that connect to Cache.  So Cache is decoupled from the web-socket and, indeed the HTTP(S) interfacing.

You're probably too far down the line in terms of CSP development, but this kind of multi-lingual capability was something that was available years ago in our (M/Gateway)'s original EWD product which could generate CSP pages as one of its many run-time targets.  In fact, multi-lingual support was there from the beginning as it was developed initially for a customer who needed 6 European language translations of the same CSP application. and needed to minimise the time and effort needed to create the translations (done externally by a third-party service) AND keep them all in sync whilst the application was still in active development and then in ongoing maintenance.

Here's the original documentation for anyone interested:

http://gradvs1.mgateway.com/download/multiLingual.pdf

Although my efforts are now focused on the Node.js/JavaScript based QEWD generation of products, the original EWD is still available - it's actually in production use by Quest Diagnostics as the basis of their Internet-based Care360 application, so it's rock-solid and still fully supported.  For information on EWD, go to www.mgateway.com and click the Legacy link.

Rob

In answer to your question: 

"Can anyone recommend any tutorial or code example with installation instructions?"

I'd recommend reading through the comprehensive training course on EWD 3 at http://www.mgateway.com - click the Training tab there for details

The EWD 3 module called ewd-xpress provides a ready-to-run and easy-to-use Node.js-based platform for your Cache applications.  It uses cache.node to provide the connection to Cache and abstracts its APIs to make Cache behave as persistent JavaScript objects and a fine-grained Document Database. The online course will explain all!