Excellent news! This makes Caché & Globals technology really visible to Node.js developers - most of them are using #NoSQL technology - an excellent match! wink

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! :-)

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:

  • as I wanted to show in this article series, you develop using the same programming language at the front- and back-end, JavaScript is very popular for several years now and it's much easier to find JS developers
  • you can use all readily available functionality in Node.js standard modules in your back-end code: e.g. if you'd choose a front-end framework in the future that pairs out of the box with a standard Node.js back-end module, you'd need to re-implement this from scratch in COS ... modern development tends more and more to the use of existing building blocks instead of re-inventing the wheel
  • the same goes for all kinds of modules to external services you'll find on npm providing you with many thousands of building blocks out of the box
  • you even have the freedom to choose what you implement in JavaScript and what stays in COS - e.g. call a COS wrapper function from your JavaScript back-end in Caché - the function can contains parts of your business logic with all specific COS functionality you need like SQL, classes, ... communicating JSON (a temp global) in and out from/to your Node.js back-end - giving you the best of both worlds
    Additionally - IMHO - if Caché would also support JavaScript syntax internally one day as a develoment language you could really develop full-stack using one single mainstream language and allow Caché to come out of its market niche

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!

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!


This is great news - this creates a lot of visibility for Caché to JavaScript developers! smiley

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"! wink

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.

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.

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?).


If your Node.js version is 4.4.7, you need the Node.js connector provided in the latest field test. If you have a WRC login, you can find it under "developer download". Be aware this is a field test version - not ready for production use.

The existing versions you'll find in the latest official release (2016.1) are cache0100.node (for Node.js version 0.10.x) and cache0120.node (for version 0.12.x). If you install a on a 64-bit Windows, you also need to install the Node.js 64-bit binary and use the corresponding 64-bit cache.node connector you'll find in the Caché bin directory - as Caché follows the OS architecture version, everything needs to be of the same architecture version - Node.js itself and also the cache.node connector. Just put the connector in your node_modules directory (where you install your other Node.js modules using npm) and rename it to cache.node, that's all! You then just put require('cache') in your Javascript code and you can open a Caché connection.

If you need the cache.node connector for the current Node.js LTS version 4.x from the field test, you don't need to install the Caché field test completely - you can also extract it from the field test installation package (cache-2016.3.0.640.0-win_x64.exe) using e.g. 7-Zip: first extract the field test installer exe to a temp dir and next, also extract the other_~1.cab file in the temp dir to another temp dir. You'll find there a cache421.node connector you can use with Node.js version 4.x (currently v4.5.0).

One more tip: to determine if a certain cacheXXXX.node connector version will work with your Node.js version, you can check the Node.js release table: you need to look at the NODE_MODULE_VERSION column. As long as the module version number is the same, it will work with that Node.js version. E.g. in the field test installer, you'll find a cache421.node connector for version 4.2.1. As this is module version 46, it will also work on Node.js 4.4.7 and 4.5.0. But it will not work on version 6.x (module version 48 is required for that).

And in addition, always remember the OS architecture (x86 or x64) needs to be the same for Caché, Node.js and the cache.node connector! wink