Node.js is an open-source, cross-platform JavaScript run-time environment for executing JavaScript code server-side.
This post is intended to guide you through the new JSON capabilities that we introduced in Caché 2016.1. JSON has emerged to a serialization format used in many places. The web started it, but nowadays it is utilized everywhere. We've got plenty to cover, so let's get started.
This is the second part of my long post about package managers in operating systems and language distributions. Now, hopefully, we have managed to convince you that convenient package manager and rich 3rd party code repository is one key factor in establishing of a vibrant and fast growing ecosystem. (Another possible reason for ecosystem success is the consistent language design, but it will be topic for another day.)
In this second part we plan to discuss the practical aspects of creating a package manager in general and their projection to the Caché database environment.
MonCaché — MongoDB API implementation based on InterSystems Caché
The idea of the project is to implement basic MongoDB (v2.4.9) API features for searching, saving, updating and deleting documents in a way that will allow the use of InterSystems Caché instead of MongoDB without changing the code on the client side.
Perhaps, if we take an interface based on MongoDB and use InterSystems Caché for data storage, we may see a performance boost.
Something that shot up the popularity stakes last week was this article on a very interesting initiative: RealWorld:
https://medium.com/@ericsimons/introducing-realworld-6016654d36b5
I decided it would be a good idea to use this as a way of creating an exemplar implementation of a RESTful back-end using QEWD against their published API (https://github.com/gothinkster/realworld/tree/master/api)
The results are here:
https://github.com/robtweed/qewd-conduit
Actually it's the first 3rd-party implementation out of the blocks!
Reviewing my published packages, I identified a nasty bug in IRIS Native API
Full-Stack JavaScript development allows you to create state-of-the-art applications with Caché. With any (web) app you build nowadays, one has to make a lot of architectural decisions and you want to make the right ones. With the Node.js connector available for Caché, you can create a very powerful server side application server, allowing you to use the latest JavaScript technology and frameworks client- and server-side.
With all these new technologies, the most important is to integrate them in the most efficient way and to create a very productive development experience. This article willl get you started step-by-step with Node.js technology.
Developing a Full-Stack JavaScript web app with Caché requires you to bring together the right building blocks. In the previous part, we created a basic front-end React application. In the second part of this article series I will show how to choose the right back-end technology for your application. You will see Caché allows you to use many different approaches to link your front-end to your Caché server, depending on your application's needs. In this part we will set up a back-end with Node.js/QEWD and CSP/REST. In the next part we will enhance our basic web app and connect it to Caché using these technologies.
Those of you who keep an eye on developments in the mainstream of IT will be aware that a major upheaval has been occurring over the last 5 or so years, in which JavaScript has exploded in popularity and importance. Largely as a result of its server-side incarnation - Node.js - it has broken free of just being the scripting language that you use in web browser, to becoming the world's most popular language and enterprise technology of choice.
As soon as I started playing about with Node.
The typeorm-iris project provides experimental support for integrating TypeORM with InterSystems IRIS, enabling developers to interact with IRIS using TypeORM’s well-known decorators and repository abstractions. This allows a more familiar development experience for JavaScript and TypeScript developers building Node.js applications with IRIS as the backend database.
While the project implements key integration points with TypeORM and supports basic entity operations, it’s not yet battle-tested or suitable for production environments.
Globals, these magic swords for storing data, have been around for a while, but not many people can use them efficiently or know about this super-weapon altogether.
If you use globals for tasks where they truly shine, the results may be amazing, either in terms of increased performance or dramatic simplification of the overall solution (1, 2).
Globals offer a special way of storing and processing data, which is completely different from SQL tables. They were first introduced in 1966 in the M(UMPS) programming language, which was initially used in medical databases. It is still used in the same way, but has also been adopted by some other industries where reliability and high performance are top priorities: finance, trading, etc.
Later M(UMPS) evolved into Caché ObjectScript (COS). COS was developed by InterSystems as a superset of M. The original language is still accepted by developers' community and alive in a few implementations. There are several signs of activity around the web: MUMPS Google group, Mumps User's group), effective ISO Standard, etc.
Modern global based DBMS supports transactions, journaling, replication, partitioning. It means that they can be used for building modern, reliable and fast distributed systems.
Globals do not restrict you to the boundaries of the relational model. They give you the freedom of creating data structures optimized for particular tasks. For many applications reasonable use of globals can be a real silver bullet offering speeds that developers of conventional relational applications can only dream of.
Globals as a method of storing data can be used in many modern programming languages, both high- and low-level. Therefore, this article will focus specifically on globals and not the language they once came from.
Developing a Full-Stack JavaScript web app with Caché requires you to bring together the right building blocks. Previously, I outlined the basic steps to install and connect Node.js to Caché and make it's powerful multi-model database capabilites available for use with Node.js. You can use Caché as a NoSQL-, document- (with unique key-level access!), SQL- and object-database with Node.js. When developing JavaScript applications, you'll see how powerful this combination is and makes Caché a perfect fit for Node.js.
In the first part of this article series I will show how to get started with the React framework, one of the most popular frameworks currently taking over front-end development. In the next parts you'll learn how to connect a basic web app to a Caché back-end.
You'll see, it's very easy to get started with this technology - you can even compare the amount of basic knowledge you need to COS because you only need to know a few basic concepts to start!
Most server-client communication on the web is based on a request and response structure. The client sends a request to the server and the server responds to this request. The WebSocket protocol provides a two-way channel of communication between a server and client, allowing servers to send messages to clients without first receiving a request. For more information on the WebSocket protocol and its implementation in InterSystems IRIS, see the links below.
gj :: configExplorer is a new VS Code extension integrating with Server Manager and leveraging Structurizr to produce configuration diagrams of your servers.
Here's a short introductory video.
By using the InterSystems IRIS Native API for Node.js it avoids the need for any support code to be installed on the servers. This technology choice also qualifies it for entry into the current Developer Community contest.
The initial release focuses on two aspects of server configuration:
Suggestions for what to add next are welcome, as is general feedback.
Those of you who are following the FullStack competition here in the Developer Community will know that I submitted an entry named qewd-conduit. I wanted to summarise why I think it's something worth you taking a bit of time to check out.
qewd-conduit uses the Node.js-based QEWD framework alongside IRIS to implement the back-end REST APIs for something known as the RealWorld Conduit application:
Some time ago I got a WRC case transferred where a customer asks for the availability of a raw DEFLATE compression/decompression function built-in Caché.
When we talk about DEFLATE we need to talk about Zlib as well, since Zlib is the de-facto standard free compression/decompression library developed in the mid-90s.
Zlib works on particular DEFLATE compression/decompression algorithm and the idea of encapsulation within a wrapper (gzip, zlib, etc.).
https://en.wikipedia.
ˮ This is one of my articles which was never published in English. Let's fix it!
Hello! This article is about quite a practical way of developing InterSystems solutions without using the integrated tools like Studio or Atelier. All the code of the project can be stored in the form of "traditional" source code files, edited in your favorite development environment (for example, Visual Studio Code), indexed by any version control system and arbitrarily combined with many external tools for code analysis, preprocessing, packaging and so on.
The concept of low code development is getting more and more important across all industries. Everybody who is starting to get into low code programming, will inevitably come across Node-RED. InterSystems IRIS is renowned for its interoperability and so should be accessible via Node-RED.
For those who have not heard of Node-RED yet: Node-RED is a Low-Code programming application, which is based on so called nodes that are connected with wires. Nodes process incoming messages and forward them to the next connected node.
I've mentioned the QEWD project in this group before: it's a Node.js-based platform for web, Native and REST applications which tightly integrates with Cache. It uses a somewhat different philosophy to the use of Node.js than the norm, and I've now published an article that explains this approach and the unique benefits that arise as a result.
It turns out that, integrated via QEWD, Cache is an ideal bed-fellow for Node.js. QEWD makes the integration of Cache and Node.js exceptionally fast, simple and intuitive to use, but also extremely powerful.
Read the article here:
As a result of Evgeny's recent questions regarding the use of QEWD.js with IRIS in another post, I thought it would be a good idea to create a separate post focusing specifically on how to use QEWD.js to create REST APIs for IRIS.
QEWD.js is, of course, a Node.js framework, and all the REST API code can be written entirely in JavaScript.
The RealWorld Conduit reference application makes a great exemplar for this kind of thing, as the APIs are all published and there are numerous implementations of both front-ends and back-ends for it, using different technologies, frameworks and databases.
Hi Developers!
This is the second post on the resources for Developers. This part is about Open Exchange
Using Open Exchange to Learn InterSystems
InterSystems Open Exchange is a applications gallery of tools, connectors, and libraries which InterSystems Developers submit to share the experience, approaches and do business. All the applications are either built with InterSystems data platforms or are intended to use for development with InterSystems data platforms.
If you are a beginner developer you can take a look at applications in Technology Example category. All the applications in this category come with open source code repositories, so you are able to run the samples and examples in a docker container with IRIS on your laptop or in the cloud IRIS sandbox. Examples:
Here I’ll walk you through the process of creating a simple Node/Express API and connect it to a InterSystems IRIS instance.
I won't go into much detail about how to work with any of the technologies I will mention in this tutorial but I will leave links, in case you want to learn more.
The objective here is to give you a practical guide on how to set up and connect a node.js back-end API to IRIS.
Before we get our hands dirty, make sure you have Node.js running on your machine. So I'll check:
Version 8.12.0 is the current LTS (Long Term support) version of node.js.
There's a new and exciting enhancement to QEWD that has just been released - it's an additional layer of abstraction known as QEWD-Up. QEWD-Up hides away all the mechanics of QEWD itself, allowing you to focus on just your REST APIs and the code that implements them.
Additionally, and importantly, QEWD-Up simplifies the maintenance of your REST APIs, allowing you (and others) to quickly and easily understand their life-cycle and implementation.
QEWD-Up supports both monolithic application designs and MicroService-based architectures where APIs are broken down by, for example, functional role.
In my previous posting about the new support in QEWD for JSON Web Token (JWT) support, I mentioned that it was a key step in enabling Micro-Service support in QEWD. In this post I'll give some background to how they work and the thinking behind them.
If you haven't heard about Micro-Services and/or want to learn more, there's lots of information available if you do a Google Search. Here's a good starting point:
Developing a Full-Stack JavaScript web app with Caché requires you to bring together the right building blocks. In this third part of this article series I will show how to link our React app to our three back-ends we created in part 2.
Have you ever thought what could be a reason why some development environment (database, language) would eventually become popular? What part of this popularity could be explain as language quality? What by new and idioms approaches introduced by early language adopters? What is due to healthy ecosystem collaboration? What is due to some marketing genius?
I've posted this video on YouTube:
https://www.youtube.com/watch?v=gHUifpuav9I
Expand this article for some background to what it shows and what it's all about...
I've submitted what I've called qewd-jsdb-kit-iris to the Multi-model competition - it's a suite of applications and tutorials that demonstrate how IRIS Global Storage is used to provide the unique Node.
In this article I'll describe how to set up web services and/or REST services using EWD 3.
Since EWD 3 is designed to be modular, you can construct the environment that exactly meets your needs, but for much of the time you'll probably find that the pre-built EWD 3 ewd-xpress super-module does most of what you need because it hooks together all the core EWD 3 and other building-blocks you'll need:
We recently uploaded to OpenExchange a small application that I developed a while ago (and that @Jose-Tomas Salvador improved and refined) that I often use when I need to generate large volumes of HL7 messaging.
The application is developed in NodeJS and works by generating patient and doctor data from seed files that you can modify to your liking to personalize the generated patients. The application will use the generated patients to prepare different types of HL7 messages. At the moment the application can generate the following types of messages.
UPDATE: since version 0.0.4 of the extension was published on 2025-11-23 it is now possible to use gj :: configExplorer directly in VS Code on Windows.
In my previous article introducing gj :: configExplorer I flagged up how an apparent bug in the Windows elements of the Native API for Node.js means it's not currently available to run in VS Code on a Windows desktop. In a comment on that article I offered a workaround, but this requires a Docker-equipped Linux host you can SSH to.
If you don't have a suitable target it's now possible to leverage your local Windows Docker Desktop.
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.