Hi David


Glad to hear your success in getting it working for you.

There's a right way and a somewhat dodgy way to do what you want to do.

The right way is to have separate instances of QEWD, each connected to a particular namespace and listening on a different port.  You could probably proxy them via some URL re-writing (eg with nginx at the front-end)

The dodgy way which I think should work is to have a function wrapper around $zu(5) (or equivalent) to change namespace, and make a call to this in each of your back-end handler functions.  If you do this you need to make sure that you switch back to the original namespace before your finished() call and return from your function.  If an unexpected error occurs, you need to realise that your worker process could end up stuck in the wrong namespace.

Your namespace-switching function would need to be callable from all your Cache namespaces - use routine mapping for this.

Doing this namespace switching will be at your own risk - see how it goes

BTW for these type of situations where you want to do the same thing before and after every handler function, you might find the latest feature (beforeHandler and afterHandler) described here very useful:!topic/enterprise-web-developer-communi...




I've set up this instance of the Conduit Application:

It uses: 

- Cache 2015.2, running on Ubuntu  Linux and Node.js v6.10, on an AWS EC2 instance

- QEWD with 2 child processes

- qewd-conduit RealWorld Conduit back-end

- The React/Redux version of the front-end for Conduit, with its data served up via REST calls to the qewd-conduit back-end

Note: no changes were needed for the application to run with Cache.


Thanks Ward!

I've now added a "Guided Tour" to the ReadMe of the qewd-conduit Github repo, which people will find helpful as an explanation of how the app works and is put together.

Please use this as a guide to building your own QEWD/Cache applications


Yes - qewd-conduit is a pure REST back-end.  As such it has no front-end markup (though it could).  The /api endpoint does not, in itself, have any meaning - it's just the root URL for all the valid Conduit endpoints, eg GET /api/tags

qewd-conduit returns JSON responses, not HTML


Yes - there is no actual endpoint at /api, hence the error response.

Try one of the unauthenticated endpoints that is documented in the RealWorld Conduit API document, such as /api/tags and you'll get a proper response


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.


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



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:


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.