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

Have you tried some tests just using a simple test harness Node.js file built around cache.node, and building out your example that uses cache.node's invoke_classmethod, extending it step by step until it fails?