go to post Rob Tweed · May 31, 2017 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#c1Anyway, looking forward to part 2 of the article.Someone should do a talk at the Developers Conference.... ??
go to post Rob Tweed · May 27, 2017 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?
go to post Rob Tweed · May 20, 2017 As far as the underlying database storage engine is concerned, yes:https://www.slideshare.net/robtweed/ewd-3-training-course-part-18-modell...http://mgateway.com/docs/universalNoSQL.pdf
go to post Rob Tweed · May 11, 2017 I've just pushed out a new set of enhancements to QEWD that are described here:https://robtweed.wordpress.com/2017/05/11/qewd-now-supports-koa-js-and-u...I've upgraded the Cache-based RealWorld Conduit demo to make use of Koa.js. As suggested in the article, take a look at the X-ResponseTime response headers in our browser's JavaScript console to get an idea just how fast the combination of QEWD, Koa.js, Node.js + Cache really is. The URL for the live demo is: http://34.201.135.122:8080Rob
go to post Rob Tweed · May 10, 2017 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 goesBTW 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:https://groups.google.com/forum/#!topic/enterprise-web-developer-communi...Rob
go to post Rob Tweed · May 4, 2017 I've set up this instance of the Conduit Application:http://34.201.135.122:8080 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-endNote: no changes were needed for the application to run with Cache.
go to post Rob Tweed · May 4, 2017 QEWD has now been accepted as one of the official RealWorld Conduit back-ends:https://github.com/gothinkster/realworld
go to post Rob Tweed · May 2, 2017 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
go to post Rob Tweed · May 1, 2017 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/tagsqewd-conduit returns JSON responses, not HTML
go to post Rob Tweed · May 1, 2017 I wasn't planning on it - perhaps someone should. All the instructions for setting up QEWD with Cache are here:https://www.slideshare.net/robtweed/installing-configuring-ewdxpressRob
go to post Rob Tweed · May 1, 2017 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 responseRob
go to post 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/installersThere'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
go to post 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...
go to post 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.
go to post 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
go to post 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.
go to post 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 JSAs to moving parts, QEWD is entirely Node.js-based, so no extra moving parts other than Node.
go to post 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.pdfAlthough 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
go to post 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-...
