That depends on your definition of "REST API on the IRIS side". That IRIS provides the HTTP interface? and/or the code that does the work of the API is within IRIS and therefore ObjectScript? As far as QEWD is concerned, IRIS is simply a persistent JSON store with no other role (though you still can invoke ObjectScript methods and access classes if you want), so a REST API is implemented in JavaScript and handled by Node.js/QEWD.
So, provided IRIS is used as the back-end database for the data persistence of the APIs, the competition allows the use of any other technologies in front of it? eg QEWD/Node.js + browser UI?
These competitions appear to demand the use of Cache ObjectScript rather than any other language. Is this correct? And if so, why can't other languages be used instead?
These APIs appear to be synchronous, and therefore will not be usable in a standard production Node.js environment where all concurrent users coexist in the same physical process.
This is precisely the reason why QEWD was created - ie to allow the safe use of synchronous APIs, but, then again, if you use QEWD, you won't need or use the APIs described here
They aren't products as such, more repositories that focus on particular aspects of / components within QEWD, to help people get up and running with them. They are linked from the main QEWD repository, which, in turn, is linked to your Open Exchange.
Use QEWD instead - for example, if you want to build REST APIs with Cache + Windows: https://github.com/robtweed/qewd-microservices-examples/blob/master/WINDOWS-IRIS-1.md
You say "All this processing runs asynchronously." but from what I can tell from the Native Node.js API, they are all synchronous.
The Node.js-based QEWD-JSdb can be set up to work against IRIS. Here's how you can access its Global Storage:
https://github.com/robtweed/qewd-jsdb/blob/master/REPL.md
In that case I'll wait for a different competition :-)
That depends on your definition of "REST API on the IRIS side". That IRIS provides the HTTP interface? and/or the code that does the work of the API is within IRIS and therefore ObjectScript? As far as QEWD is concerned, IRIS is simply a persistent JSON store with no other role (though you still can invoke ObjectScript methods and access classes if you want), so a REST API is implemented in JavaScript and handled by Node.js/QEWD.
So, provided IRIS is used as the back-end database for the data persistence of the APIs, the competition allows the use of any other technologies in front of it? eg QEWD/Node.js + browser UI?
These competitions appear to demand the use of Cache ObjectScript rather than any other language. Is this correct? And if so, why can't other languages be used instead?
Try using this interface module instead: https://github.com/chrisemunt/mg-dbx
These APIs appear to be synchronous, and therefore will not be usable in a standard production Node.js environment where all concurrent users coexist in the same physical process.
This is precisely the reason why QEWD was created - ie to allow the safe use of synchronous APIs, but, then again, if you use QEWD, you won't need or use the APIs described here
They aren't products as such, more repositories that focus on particular aspects of / components within QEWD, to help people get up and running with them. They are linked from the main QEWD repository, which, in turn, is linked to your Open Exchange.