Replies

You need the cache610.node file for Windows 64 bit

Rob

 

The version of cache.node must match:

- the OS you're using (in your case 64-bit Windows)

- the version of Node.js you're using - you haven't specified that

Unfortunately InterSystems so far haven't done the sensible thing and publish cache.node in NPM, so you may or may not find that the versions of cache.node included with your Cache distribution support the version of Node.js you wish to use.

 

 

If any of you are in the London area on Wednesday evening this week, why not come along to the LNUG meeting?  I'll be giving a presentation, based on my "Cake" article.  See:

https://lnug.org/

 

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

 

I've now implemented the functionality for JSON Web Tokens and QEWD-based MicroServices.

All the detail is described in the following parts of the Online Course:

https://www.slideshare.net/robtweed/ewd-3-training-course-part-43-using-json-web-tokens-with-qewd-rest-services

https://www.slideshare.net/robtweed/ewd-3-training-course-part-44-creating-microservices-with-qewdjs

https://www.slideshare.net/robtweed/ewd-3-training-course-part-45-using-qewds-advanced-microservice-functionality

 

If you're just getting started with QEWD. t's a good idea to understand how to use it as a straightforward REST Server first:

https://www.slideshare.net/robtweed/ewd-3-training-course-part-31-ewdxpress-for-web-and-rest-services

As you'll see once you start to delve into these tutorials, this is a very powerful technology, aimed at delivering massively scalable, high-performance, highly-secure distributed and federated solutions - all available today for your Cache-based applications today with Open Source software.

----------------------------------------------------------

As a reminder to anyone new to QEWD: an introduction on the thinking and architecture behind QEWD: 

https://medium.com/the-node-js-collection/having-your-node-js-cake-and-e...

For an overview of the whys and hows of QEWD's JWT and MicroService Architecture:

https://www.slideshare.net/robtweed/qewdjs-json-web-tokens-microservices

 

 

 

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