Building a QEWD / Node.js / Cache REST Back-end

Something that shot up the popularity stakes last week was this article on a very interesting initiative: RealWorld:

https://medium.com/@ericsimons/introducing-realworld-6016654d36b5

I decided it would be a good idea to use this as a way of creating an exemplar implementation of a RESTful back-end using QEWD against their published API (https://github.com/gothinkster/realworld/tree/master/api)

The results are here:

https://github.com/robtweed/qewd-conduit

Actually it's the first 3rd-party implementation out of the blocks!

Although I state that it uses Redis as the database, you can seamlessly swap in Cache instead and it will work without any change apart from editing the QEWD startup to instruct it how and where to connect to Cache.

Watch this space for some tutorial articles on how I went about the implementation.  In the meantime, check out the code, see how it implements the APIs, and try out the back-end, particularly in comparison with the benchmark Node.js implementation (spoiler: I see > 4X the performance using QEWD.  I haven't tried it yet but I think it would be even faster if I used Cache).

 

  • + 4
  • 0
  • 918
  • 14

Comments

Rob! Do you plan to host a demo with Caché?

Or what are the steps to do that?

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-end

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

 

This is great news - this creates a lot of visibility for Caché to JavaScript developers! smiley

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

Rob

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

 

Hi Rob, this is great stuff - I think it's an excellent & more advanced "real world" example that shows how fast you can develop a REST back-end with Node.js, QEWD and Caché (compared to the Node.js basic web app with React example series I posted last week which is more of a "getting started")!

I think that by providing standardized examples, the JavaScript community allows you to compare different front- and back-ends easily and show the performance potential of QEWD (in terms of development time) and Caché (in terms of database capabilities and speed).

Let's increase the popularity of Caché in the JavaScript community and let everyone discover the "best kept secret in industry"! wink

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

 

Hi Rob,

 

My company is implementing a REST API for a browser-based client to interact with  our Cache database.  I found the example very useful, and I am happily able to get data from the database and present it to the client in JSON format.

As we are looking at separating customer data by namespace, I wondered if it is possible dynamically to change the namespace that QEWD is connecting to, without having to restart my QEWD Node application with a different set of configuration options?

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:

https://groups.google.com/forum/#!topic/enterprise-web-developer-communi...

Rob

 

 

Thanks Rob. 

I have implemented a function wrapper to change namespaces before an operation and then reset it again afterwards, and it seems to work reasonable well.  As we are intending to insulate customers' data from each other with namespace allocation, it does seem to make sense to have a battery of QEWD instances with one running for each namespace, as it will reinforce the separation of services between customers.  This will be a topic for discussion with the rest of my team.

 

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:8080

Rob