go to post Rob Tweed · Nov 1, 2022 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.
go to post Rob Tweed · Oct 31, 2022 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!
go to post Rob Tweed · Oct 27, 2022 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!
go to post Rob Tweed · Jan 2, 2022 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
go to post Rob Tweed · Jun 16, 2021 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
go to post Rob Tweed · Jun 16, 2021 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
go to post Rob Tweed · Jun 9, 2021 Take a look at the ObjectScript functions $NAME, $QUERY, $QSUBSCRIPT and $QLENGTH https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=RC...
go to post Rob Tweed · Jan 26, 2021 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
go to post Rob Tweed · Jan 18, 2021 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
go to post Rob Tweed · Nov 30, 2020 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
