The idea of connecting Node.js to Cache is to write your logic in JavaScript, except for where you need to invoke legacy code.  It makes little sense to invoke COS built-in functions such as $h via cache.node.

With that in mind, have you looked at QEWD.js, which makes the integration of Node.js and Cache very much simpler? See:

https://qewd.js.com

To expand the concept of using JavaScript rather than COS as the language for your logic, you might want to take a look at this: https://www.slideshare.net/robtweed/data-persistence-as-a-language-feature

Probably a good idea to continue this thread here instead:

https://groups.google.com/forum/#!forum/enterprise-web-developer-community

The way I'd do this is to not do any JSON handling in Cache itself, but output the data into a temporary global whose structure reflected the desired JSON structure.  Then on the Node.js / QEWD side, point a DocumentNode object at the global and use its getDocument() method - that will generate a JS object containing your data.  Finally delete the global using the DocumentNode object's delete() method

Hi Malcolm - I hope you mean Node.js 0.10 :-)  0.1 predates even my earliest experiments with Node.js in 2010!

You'll need to talk to your ISC account rep to get the latest cache.node builds.

So the next thing you need to do is look at QEWD.js (http://qewdjs.com) to see how you can really begin to use Cache with Node.js productively

Rob

You need the cache610.node file for Windows 64 bit

Rob

My presentation made reference to a  Google V8 API bottleneck issue.  Here's the link to the bug tracker report:

https://bugs.chromium.org/p/v8/issues/detail?id=5144#c1

and the detailed benchmark tests that illustrate the problem

https://bugs.chromium.org/p/v8/issues/attachmentText?aid=240024

Slide deck for my presentation on "data persistence as a language feature" is here:

https://www.slideshare.net/robtweed/data-persistence-as-a-language-feature

Let me repeat this, a programming language MUMPS-Cache objectscript with a built-in database. I think this is a fundamental aspect that they have been missing when others invented new programming languages. They are missing the innate common characteristic that both databases and programming languages share which is the pointer, reference based logic. So I believe it's time to return back and fix this for new generation databases AND post-modern programming languages too.

This is a core part of the QEWD.js project: to make JavaScript a first-class language for Global Storage databases - and therefore give JavaScript a built-in database.  

The cache.node module provides the high-performance in-process connection needed to allow the intimate relationship between JavaScript and the Cache database engine.  The ewd-document-store module aims to provide the JavaScript equivalent of the ^ in COS (ie blurring the distinction between in-memory and on-disk JavaScript objects). 

JavaScript's dynamic, schemaless objects are a perfect fit with the dynamic, schemaless nature of Global Storage, making it an ideal modern substitute language instead of COS.  

For more information see the online tutorial at http://docs.qewdjs.com/qewd_training.html  - specifically parts 17 - 27

By the way, using cache.node as the interface gives the benefit of a high-performance in-process connection to Cache from JavaScript - significantly faster than using a networked connection, as it connects at a very low-level directly into the core global engine via Cache's C-based call-in interface.  

There's still currently a limitation however, due to a V8 API bottleneck, described here:

https://bugs.chromium.org/p/v8/issues/detail?id=5144#c1

My simple experiments comparing Global access performance via native COS versus cache.node and JavaScript show that connecting from Node.js via cache.node provides only about 10% of native COS performance - so a 90% performance reduction, apparently all due to this V8 bottleneck!  Nevertheless, my comparisons of MongoDB performance versus using Globals as a document database show that MongoDB is only relatively slightly faster.

If this V8 API problem was fixed, then access to Cache via cache.node would be as fast as using native COS.  The outcome, if my experimentation has been correct, would be that MongoDB would be significantly out-performed by Cache as a document database.  Additionally, my prediction would be that your MongoDB emulation could also outperform the real thing too - a rather interesting and somewhat startling result if true.

I would love to see this V8 bottleneck resolved.  I wonder if there's anyone in this community that could take on that challenge, or perhaps knows someone with the skills to take it on?  I think a lot of people would sit up and take notice of what could become the fastest Node.js-connected NoSQL database on the planet.

Rob

> The Caché Node.js driver could not access Caché classes, but could make program calls from Caché. This fact resulted in the

>creation of a small tool - a kind of bridge between the driver and Caché classes.

This is incorrect - cache.node can access Cache Objects. See:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

Also take a look at this:

https://github.com/chrisemunt/mongo-dbx

as an alternative MongoDB interface

You miss the point - Node.js / JavaScript is now one of the most used back-ends / languages.  By comparison, COS is almost unknown in the IT mainstream.  Sure, you can do everything in COS, but to do so, you need to learn COS.  If you have to learn COS to use Cache, most people in IT won't use it as the back-end to web applications.

Write your apps the way Ward suggests, and  you open up Cache to a massively bigger audience, and you can also recruit JavaScript guys to do the back-end development, without them having to learn COS, but they get all the benefits of the database.

Regarding performance, see my last comment for this article:

https://community.intersystems.com/post/building-qewd-nodejs-cache-rest-...

and see for yourself - look at the browser console network logs and look at the X-ResponseTime response header values to see the back-end response time using Node.js + Cache - here's the demo link:

http://34.201.135.122:8080/

Suggestion - put together a COS/CSP version of the RealWorld Conduit back-end and see how it performs by comparison, so you get an apples v apples comparison

> So far NodeJS is only used as a general dev environment and build pipeline manager.

This is just not true

Representing XML and JSON in Global Storage is an interesting area.

In the case of XML, things are a little more complex than described in your article, since there's something of an ambiguity between information stored in the text value of an element and an attribute of an element.  For this reason, the better representation is to model the XML DOM in Global Storage nodes.  You'll find a pretty thorough (and free, Open Source) implementation here:

https://github.com/robtweed/EWD

This article provides more information:

https://groups.google.com/forum/#!searchin/enterprise-web-developer-comm...

Once in DOM format you can apply cool stuff such as XPath querying.  See:

https://groups.google.com/forum/#!searchin/enterprise-web-developer-comm...

The DOM is essentially modelled in Global Storage as a graph.  DOM programming is extremely powerful, allowing all sorts of complex things to be performed very efficiently and simply.

JSON is much simpler, being a pure hierarchy.  The only ambiguity with Global Storage is that JSON only allows leaf nodes to hold data - intermediate nodes cannot.  However, Global nodes can be intermediate nodes AND store data.  So whilst all JSON trees can be represented as a Global tree, not all Global trees can be represented as JSON.

The Node.js-based QEWD.js framework uses Global Storage as an embedded database to provide Session storage, persistent JavaScript Objects and a fine-grained Document Database.  To see how this is done, see the training course slide decks:

http://ec2.mgateway.com/ewd/ws/training.html

..specifically parts 17 - 27

Keep up the great work on this series of articles!

Rob

Perhaps someone from InterSystems should respond with respect to Sean's views on cache.node?

I don't know why you don't use the cache.node interface?   It will support in excess of 100k global sets/second per connection.  Is there something you believe it doesn't do that you need?

Very good article - good to see Global Storage being discussed.  Thanks for the compliments!  We need this kind of discussion to be promulgated out to a wider audience, not just preaching here to the (largely) already converted.  

I despair when I go to technical conferences where not one single attendee I speak to has heard of Cache or Global Storage.  Yet it's a database technology and architecture that is ideally suited to todays requirements (and particularly suited to the burgeoning JavaScript world), and is crying out to be more widely known about.  I do my best to get new interest in the mainstream, but feel I'm something of a lone voice in the wilderness.

The other thing I'd love to see is to have at my disposal within Node.js a similar level of performance as the article has described when using native Cache Objectscript.  It turns out there's just one Google V8 bottleneck in the way - if that could be sorted out, the idea of having a database in Node.js that could persist JSON data at speeds in excess of 1 million name/value pairs per second would blow every other database clean out of the water.  I would LOVE to see this rectified , and if fixed, it could create a huge wave of interest (people at those conferences I go to might actually want to find out about it!)

Here's the issue:

https://bugs.chromium.org/p/v8/issues/detail?id=5144#c1

Anyway, looking forward to part 2 of the article.

Someone should do a talk at the Developers Conference.... ??