And here you'll find an example how you can customize your Node.js based Web- and REST services to integrate with reporting engines like JasperReports using XML data adapters or return XML responses for EDI purposes:
https://groups.google.com/forum/#!topic/enterprise-web-developer-commun…
Hi Stephan, that's really great news! Is there any progress on the npm release of the Node.js connector?
Currently I need to use the field test connector version in my production environment (!) because I need the Node.js 4.x version - many npm modules already require a much more recent Node.js version 4 to install. In the latest official 2016.1 release there is only a v0.10 and a v0.12 connector available.
Thanks in advance!
This is not a strange idea at all, a "Caché Globals Edition" would be a perfect fit for the Raspberry Pi (it just needs an ARM build with a Node.js interface as full Caché - similar to GlobalsDB in the past).
This would create a huge potential on the IoT market as it typically needs fast and big data storage. This can be done easily with such an edition running on a Pi for raw data storage. And IoT developers would have the possibility to keep using the same database (a full Caché) on their IoT server platforms for data processing and analysis (DeepSee?).
Supporting an RPi 2/3 would be possible without major code rewriting these days with Windows 10 IoT Core starting from the same codebase as Caché for Windows (built to a different target: ARM). For Linux, the default Raspbian OS is based on Debian.
The full Caché is probably too heavy, but a "lite" version as GlobalsDB would be a perfect fit for such a device. In IoT, data coming in from sensors (at a remote location e.g.) typically needs a lot of storage and filtering out before it's sent to a server (located elsewhere). Network bandwidths and in-memory storage are not sufficient to hold and send all data in real-time.
I saw these problems already many years ago in several industrial automation projects (even before IoT existed). In IoT applications these days, the incoming data stream for an RPi collecting data remotely is much heavier now - real (lightweight) database storage would be a blessing and can be an excellent stepping stone to full Caché on the server for decision makers and developers. I'm very confident that IoT developers would welcome this because the current offering on the market is sparse.
Hi Rob, this is great stuff - I think it's an excellent & more advanced "real world" example that shows how fast you can develop a REST back-end with Node.js, QEWD and Caché (compared to the Node.js basic web app with React example series I posted last week which is more of a "getting started")!
I think that by providing standardized examples, the JavaScript community allows you to compare different front- and back-ends easily and show the performance potential of QEWD (in terms of development time) and Caché (in terms of database capabilities and speed).
Let's increase the popularity of Caché in the JavaScript community and let everyone discover the "best kept secret in industry"! 
This is great news - this creates a lot of visibility for Caché to JavaScript developers! 
For an excellent, more in-depth application example, there is now a very useful RealWorld platform available, made by the people of Thinkster allowing you to easily compare many different modern web app technologies (front-end and back-end solutions).
This example app is a quite advanced real-world example you can use as a reference app to write your own apps and get the idea what development with modern app technology is all about.
The best news: Rob Tweed created a Caché Node.js back-end using QEWD/Express REST calls for this example app and also made a React/Redux demo version available to test using Caché as the underlying database.
Please check out this example as the results with Caché in terms of performance and development speed are really impressive!
You can also perfectly communicate with the back-end using CSP/REST, using Caché as the application server (as you can see in parts 2 & 3). This is a choice the developer has to make.
However, using Node.js as the application server (and Caché serving as the database - or even application server too) gives you a lot of advantages:
In terms of comparing performance: if someone - as Rob suggests - can write the RealWorld Conduit example back-end in CSP, you'll have a very realistic comparison between the two options!
This is a very cool concept and a nice application of the WebSocket technology used in QEWD! It allows you to build very modular resilient systems using Node.js with Caché at the back-end. Love the idea! :-)
Excellent news! This makes Caché & Globals technology really visible to Node.js developers - most of them are using #NoSQL technology - an excellent match!
I completely agree Herman! Vue.js looks so "natural" once you start coding with it that you ask yourself the question: "why didn't I think of this before?" ...
IMHO, there's also one big difference between Angular and Vue.js: Angular is a "complete" framework in the sense that it contains all functionality you may need (what makes it big and heavy - 452 kB minified!) while Vue.js is a library for your view + business logic (what makes it so compact and lightweight - only 16 kB minified). With Vue.js, you only include functionality you need for your application. One would argue that with current hardware devices this is no longer an issue, but the performance hit lies in the execution of this amount of code at runtime, which makes it slower the bigger the framework code is.
In fact, the guy who started Vue.js (Evan You) was first working at Google Labs with Angular where he saw the need to make an easier to understand, much more compact library allowing you to do the same with a flat learning curve. When you see Vue.js now with it's companion libs like Vuex, I think he did a really great job!
To compare them in terms of GitHub stars:
Vue.js has an exponentially growing popularity, compares well to Angular but is much more compact and is nearly as popular as React (but React came out one year earlier!).
Last week I found this excellent blog article comparing the most popular JavaScript libraries and frameworks.
I must say I'm currently using React/Redux for my projects, but last week, Vue.js drawed my attention by coincidence. When I started trying out some examples, this library felt immediately like "this is it" and "why didn't someone else think of this before?" to me. It comes very close to HTML + vanilla JavaScript and the way of coding is very intuitive.
I completely agree - Vue.js uses the more modern features in JavaScript cleverly (btw which finally rules out IE <= 8). But anyway, Vue.js is a great initiative taken by an Angular developer to create a much faster, more natural and lighter library - keeping the good parts of Angular.
To use SQL from Node.js - keeping the advantages of both worlds (JS & COS) - I created a small helper module you can use in your own Node.js handler modules.
The way it works is:
you call a function/method in COS from your Node.js handler, passing all necessary parameters in
the helper module puts them in a temp global (this means you don't have any limits on the amount of data you pass to Caché)
your COS code uses the input data (parameters) in the $$$jsData("params", ...) global (I defined a macro for readability)
your code fills the $$$jsData("json", ...) global with the result data (remember that JSON maps 1-to-1 on a Caché global)
I released a new module for this: qewd-cos - it's explained in detail in the module how it works with a working example. This module defines a standardized way of calling your own functions in Caché - take a look at the source code to see how you can call Caché functions and return standard responses in QEWD.
Btw, you can also use QEWD in the other direction: you can call from your COS code your own QEWD REST (or microService) endpoints using HTTP calls using ##class(%Net.HttpRequest). This is e.g. very useful to send e-mails using standard NPM modules allowing you to use templating engines (like handlebars, ...). It allows you to create more advanced e-mails much easier. Or more in general, to make external Node.js modules/functionality available in Caché which is not built-in.
Hi John,
I'm happy to hear the course was useful for you!
Btw, I can also recommend the YouTube channel from the Frontend Developer conference lately in Amsterdam:
https://www.youtube.com/channel/UC1nBp6ouBB1o5P8YvPznPOw
You'll find a featured video there from the creator of Vue.js (Evan You) about how Vue.js will go forward. Btw, in terms of GitHub stars, the Vue.js project currently has 88k stars while React has 91k - it became quickly one of the leading frameworks and adoption is comparable to React.
I'm also more and more convinced Vue.js is a very complementary front-end for Caché/IRIS (and a natural fit) because of it's simplicity, flexibility and feature richness:
) to make your client side application code reactive by designIt's very easy to learn and allows to bind your front-end to your back-end using the technology you prefer like WebSockets (using QEWD), REST, GraphQL, ...)
Hi Evgeny, Rob asked me to post his demo app he created as he's not around ATM.
The demo is the IRIS implementation variant of a very popular example app: https://github.com/gothinkster/realworld
The IRIS demo is at: Conduit on IRIS using QEWD.js
The app is a Medium.com clone (called Conduit) which is implemented with all sorts of front- and back-ends. Which makes it very easy to compare different technologies.
Enjoy!
Ward
Hi Evgeny, sorry but I can't attend Global Summit.
Hi Evgeny, I'm using this technique for sending e-mails (using a template engine like handlebars) in my own applications, but I don't have an easy example stripped-down to the bare essentials right at hand. But I'll write an example post how to do this as soon as I have some spare time and I'll add a link to it in this post too.
Hi Evgeny, yes I have problems uploading a file (pdf) in my post - I updated the link in my answer to point to my own server for the Caché User Group website.
FYI, the ImageMagick library can be natively integrated as a Node.js/Express (REST) endpoint using the magick-cli module in the same way as suggested in my previous answer for highest performance.
A few more things to check:
If the module still refuses tot load, I'll upload an example test.js file I use myself to test basic functionality.
This is a basic test script I'm using to test basic connectivity from Node.js v8.x, the iris.node module version included is meant for an IRIS x64 instance on Windows with Node.js v8.x x64 installed.
It contains everything you need, you can immediately run it - you should see the same results. The test script assumes IRIS is installed in C:\InterSystems\IRIS and the _SYSTEM user contains the default password. If not, you need to change this in the example script iristest.js in the db.open() parameters.
Btw, if you're developing a React Native app and you need a back-end server for IRIS, you can try the react-qewd module for Node.js for use with the QEWD.js back-end server for IRIS.
Btw, I just noticed there is a small error in the documentation Using Node.js with InterSystems / Using iris.node NoSQL Methods:
To instantiate the connector, the code line:
var mydata = new irisobj.Iris();
should be:
var mydata = new irisobj.IRIS();
In that case, I'd go the $ZF(-100) route with ImageMagick. You can run this from shell and Perl, building from source will be necessary I suppose.
Very strange - did the test script work on your machine from the example zip?
When I look at the error you post: is the path in db.open() method pointing to:
path:"C:\\InterSystems\\IRIS\\Mgr"
It must point to the Mgr directory.
Btw, as the error occurs in the require() already, I still suspect there is a Node.js module version mismatch:
https://npm.community/t/node-module-version-confusion/2982
https://github.com/kelektiv/node.bcrypt.js/issues/635
You need to double check which Node.js version and iris.node version you have. I suspect there is a mismatching iris.node version somewhere on your machine that require() finds in the module search path.
Reading the comments here, it seems as we'll be short on time to show & discuss everything during the CUG meeting!
I'm looking forward to see these nice add-ons & howto's.
See you all at the symposium!
@Fabian Pie one thing I forgot: you should also build an index from the Customer global, e.g. based on Robert's code snippet:
set id="" for {
set id=$order(^Customer(id)) quit:id=""
set city=$get(^Customer(id,"Address",1))
set name=$get(^Customer(id,"Name"))
if $length(city)&$length(name) set ^CustomerIndex(city,name,id)=""}Now you can easily filter on the selected city and loop over the (sorted) customer names by iterating over the ^CustomerIndex global using similar JavaScript code as above. By using globals, you get sorting for free! And you don't need to traverse the whole customer global anymore.
To iterate over just the global nodes you need, see my other comment below. You need an index global to do this.
Please note that QEWD.js and the Node.js adapter are very different: the Node.js client is a low-level adapter to access the Caché/IRIS database, while QEWD.js is a full multi-process back-end application server (in the underlying code, QEWD is using the ewd-document-store abstraction and, in turn, uses the IRIS node.js client to access Caché/IRIS). In fact, it removes you from writing a lot of system "plumbing" code to get your front-end code working with Caché/IRIS. You'll find QEWD examples for use with React apps at react-qewd and with Vue.js/Nuxt.js apps at vue-qewd.