New post
AllAccepted answers
Rob Tweed · Apr 26, 2017

Regarding the installation of QEWD, it's worth pointing out that the Github/NPM repository includes an installers folder which contains a number of installer scripts for Linux-based systems. There's even one for QEWD + Linux + Cache, although it shouldn't be run as a script since you will probably already have Cache installed - use it instead as a guide for the commands you need to run in order to install the various bits and pieces.

See https://github.com/robtweed/qewd/tree/master/installers

There's even an installer for the Raspberry Pi, although that can't use Cache (sadly!)

Another alternative is to use the Docker appliance, but it would need to be adapted to work with Cache.  See https://github.com/robtweed/qewd/tree/master/docker

Rob Tweed · Apr 24, 2017

Very nice article, Ward!

For anyone wanting to create a Cache-based REST / Web Service back-end, QEWD + Node.js is definitely worth considering as a modern, lightweight but very high-performance, robust and scalable alternative to CSP.  I'd recommend that anyone interested should also go through this slide deck:

https://www.slideshare.net/robtweed/ewd-3-training-course-part-31-ewdxpr...

Rob Tweed · Apr 21, 2017

Chris Munt would be the person to ask, but I'm not aware that the lack of a resolution to the bottleneck issue is anything to with security - more that Google don't "get" the issue and see it as a priority, since it's an unusual requirement.

Anyway cache.node is an official InterSystems interface so why not just use it instead of rolling your own?  Ideally ISC should be pushing Google to fix the bottleneck.

Rob Tweed · Apr 21, 2017

cache.node will handle in excess of 90,000 global sets/sec in its in-process mode.  If that V8 bottleneck was sorted out, we'd have COS performance for JS accessing a Cache database (ie > 1,000,000 global sets / sec)

With QEWD (actually ewd-qoper8), you find that for simple message handling, optimum throughput is when the number of Node.js processes (master + workers) equals the number of CPU cores.  That's a Node.js context switching issue, nothing to do with Cache.

QEWD allows you to configure cache.node to work in networked mode, in which case you can have Cache running on a separate server to the Node.js machine.  I've not compared performance, but it's a simple QEWD startup-file setting change to switch modes, so easy to compare if you want to give it  a try.

QEWD is very quick and easy to set up on a Windows machine where Cache is already installed.  See:

https://www.slideshare.net/robtweed/installing-configuring-ewdxpress

Rob Tweed · Apr 21, 2017

Just to clarify - despite the bottleneck I've mentioned, cache.node will be a LOT faster than a TCP-based Node.js interface.  cache.node runs in-process with the Node.js process, and uses the Cache call-in interface.  As a result, QEWD is very fast and my guess is that it should outstrip an equivalent app using CSP.

Also, note that with QEWD, the socket.io connections are between the browsers and the QEWD master process, and NOT the child/worker processes that connect to Cache.  So Cache is decoupled from the web-socket and, indeed the HTTP(S) interfacing.

Rob Tweed · Apr 21, 2017

See my recent article on QEWD for the rationale behind its architecture:

https://robtweed.wordpress.com/2017/04/18/having-your-node-js-cake-and-e...

As to benchmarks, the ewd-qoper8 module comes with a benchmarking app - even on a basic Linux VM setup, I can easily get in excess of 10,000 message round-trips per second.  Of course, once you add QEWD's access to Cache via cache.node, that will drop.  cache.node is a bottle-neck currently, for V8-related reasons described here:

https://groups.google.com/forum/#!searchin/v8-dev/bottleneck%7Csort:date...

It would be great if Google could fix this as we'd then get native COS performance via JS

As to moving parts, QEWD is entirely Node.js-based, so no extra moving parts other than Node.

Rob Tweed · Apr 21, 2017

You're probably too far down the line in terms of CSP development, but this kind of multi-lingual capability was something that was available years ago in our (M/Gateway)'s original EWD product which could generate CSP pages as one of its many run-time targets.  In fact, multi-lingual support was there from the beginning as it was developed initially for a customer who needed 6 European language translations of the same CSP application. and needed to minimise the time and effort needed to create the translations (done externally by a third-party service) AND keep them all in sync whilst the application was still in active development and then in ongoing maintenance.

Here's the original documentation for anyone interested:

http://gradvs1.mgateway.com/download/multiLingual.pdf

Although my efforts are now focused on the Node.js/JavaScript based QEWD generation of products, the original EWD is still available - it's actually in production use by Quest Diagnostics as the basis of their Internet-based Care360 application, so it's rock-solid and still fully supported.  For information on EWD, go to www.mgateway.com and click the Legacy link.

Rob

Rob Tweed · Apr 21, 2017

QEWD (and EWD.js before it) has been using WebSockets for years with Cache at the back-end.  Of course, in this case, WebSocket support is provided by the Node.js socket.io module, so it avoids any COS-related issues.  It works extremely well and is very fast, stable and scalable.  Personally I'd always use WebSockets in preference to Ajax for browser to/from back-end communication.

However, one of the tricks QEWD pulls off is to allow you to transparently switch between Ajax and WebSockets as the transport for browser communication - for you, the developer, there's no difference in how you transfer messages, so you can choose the transport that is right for you via a simple configuration switch.  See:

https://www.slideshare.net/robtweed/ewd-3-training-course-part-14-using-...

Rob Tweed · Mar 23, 2017

Chris
 
I've not looked at the V4 Signature rules in detail, but the V1 & V2 rules were implemented in this SimpleDB Client that I created years ago for use with both AWS SimpleDB and my M/DB clone:

https://s3.amazonaws.com/rtweeddata/simpleDBClient.xml

Not sure if that helps, but feel free to adapt as needed if it provides a useful starting point - start around line 426 which is the createHTTPRequest() function that creates a signed HTTP request

Rob

Rob Tweed · Oct 12, 2016

You could go a further step and run a JavaScript-based terminal console in a browser and hooking it up to Cache via Node.js.

See https://robtweed.wordpress.com/2014/03/03/ewd-js-and-vista-adding-a-java... for an example implementation

These days, you could use something like Electron to create what appears to be a Windows application, but in fact is a packaged up Chrome & Node.js environment.  In fact, IMO, this is how Atelier should have been implemented.

Remember that as soon as you have something such as this running in a browser, security (ie who has / hasn't access to the application running in the browser) becomes a major issue - you're giving command-line access to your Cache database!