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

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

This is just not true

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

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

You need the cache610.node file for Windows 64 bit

Rob

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

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

Probably a good idea to continue this thread here instead:

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

As I release my code as Open Source, I've no idea of usage stats.  There's growing interest in the use of GraphQL in the community I work within these days, for all sorts of reasons.

QEWD is a re-badging of EWD 3, so yes, it is supported in QEWD - which of course is straightforward since QEWD is JavaScript/Node.js and can just use the Facebook JavaScript GraphQL module.

Just making the point that GraphQL and support for it in Cache isn't something new, as those who follow our work at M/Gateway will know :-)

Rob

QEWD supports Cache Objects for those who wish to use them via the cache.node APIs for Cache Objects.:

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KE…

Your handler logic (which runs in a QEWD Worker process) has access to these APIs via the "this.db" object, eg this.db.invoke_classmethod()

The following post is a bit old and refers to how you used these APIs in EWD.js.  However, change the invocation to this.db.xxx() and the examples should work in QEWD:

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

Personally I prefer to use the Cache database as a persistent JSON database / Document Database, via the ewd-document-store abstraction that is used by QEWD, and integrate that storage into JavaScript Objects.  But Cache Objects will work with QEWD and GraphQL just fine

Rob

This is one of those things that becomes dead easy when you use Node.js (and use QEWD to integrate Cache with Node).  There's almost always a tried and tested module out there already that will do the stuff you want, eg in this case:

https://www.npmjs.com/package/csvtojson

And once in JSON format, you can transform it to whatever other JSON format you want using:

https://github.com/robtweed/qewd-transform-json