An observation: the administrators of this forum regularly report the size of this community, currently an impressive number in excess of 12,000 developers, yet, as can be seen from the OP, numbers of views of even the most popular posts is tiny by comparison.  From what I've seen, a typical post will get around about 50 views, and each comment will add a further 50 - a meagre 0.4% of the total community.  This leads me to believe that there is actually only a small core (~50?) of regular contributors and readers (many of whom, I suspect, are actually ISC employees)

It does make me wonder what, if anything, most of those 12,000 Cache/IRIS developers read, and what site(s) they use instead. Perhaps they don't read anything? 

My reason for raising this is that, for a third-party developer of solutions for these technologies, reaching and informing those 12,000 developers is a significant issue and problem, and it's fairly clear to me that this forum currently doesn't provide a very effective solution to that problem.

My question/challenge for 2023 is therefore what do folks here (the regular 50?) think can be done to provide a more effective way to reach that reported developer base?

If the applications you're providing to users are REST/web/browser-based, you can make use of connection/process pooling, eg via an implementation in another back-end language, to avoid/minimise these issues.  A good example is the Node.js/JavaScript-based QEWD framework or its recent evolution  - qoper8-fastify - I've described the latter in another recent posting here on Node.js. 

Another alternative is to use our mg_web interface (you may want to check out our mgweb-server framework which packages up mg_web for ObjectScript-based REST APIs to save you a lot of effort): this uses modern web servers (eg Apache/NGINX) to manage connections to IRIS in a parsimonious way.

Some holiday reading:



Using QOper8-Fastify with IRIS:



Take a look at our other language interfaces and front and back-end solutions too -  see

Well, if it was me, I'd keep that and the rest of my logic in JavaScript/Node.js and access the Cache database using the mg-dbx interface.

... well they don't need to develop their own.  They could actively support and work with third party experts in this area and simply make available suitable public interfaces.

I should point out that if you use the in-process API connection to IRIS from mg-dbx, you don't need to install anything on IRIS - just enable the call-in interface and away you go.  You do, of course, need Node.js running on the same physical hardware as IRIS for such a connection, but it's significantly better performance than a networked connection.

Ideally yes, I would agree, but you're up against the publicly available interfaces for IRIS. What would you suggest?

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.

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

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!