go to post Rob Tweed · Oct 9, 2020 For these to be "bonuses", they imply that there is something better about using them than doing the equivalent in other ways and using other technologies. They therefore rig the competition to favour solutions that use what's built-in to IRIS, and penalise systems that still use IRIS but use other technologies for achieving the same results just as effectively. So, for example, since qewd-conduit's logic is all in Node.js and not inside the IRIS programming environment, things like ZPM are not relevant, but I'm penalised for not using it. Ditto the REST API within the IRIS programming environment. And no, QEWD doesn't use the Native API for Node.js which is provided within IRIS, but uses the Open Source mg-dbx interface and the APIs it provides, so I guess that means qewd-conduit will be further penalised and lose that bonus too! :-) I suppose it comes down to what is trying to be demonstrated and promoted in the competition, but it doesn't seem to me to be a level playing field for demonstrating what's possible in terms of a full-stack application that makes use of IRIS for data storage.
go to post Rob Tweed · Oct 9, 2020 qewd-conduit could easily be set up to run in the Dockerised version of IRIS. For simplicity, the version I shipped assume you'd be running on a Windows machine on which IRIS was installed - the commonest set-up out there in my experience. It's somewhat mean to deny qewd-conduit a bonus for not using IRIS's built-in REST APIs - it clearly implements REST APIs against an IRIS system, just not using the proprietary IRIS-specific APIs. I'm not sure why their use warrants a bonus if REST APIs can be implemented just as effectively by other means.
go to post Rob Tweed · Oct 9, 2020 QEWD-Conduit is a QEWD application, which means it's a Node.js application - 100% JavaScript. As a QEWD application, it means it uses the mg-dbx connector to attach to an instance of IRIS or Cache. For simplicity and to make it easy and convenient for readers to try out, the version I've made available for the competition assumes it's going to be run on a Windows machine on which IRIS is installed - that's the most common set up out there. However, as a Node.js application, qewd-conduit is capable of running on any machine on which Node.js can be installed and run - so that means Linux, Unix, Mac OS and Windows. Since the Dockerised version of IRIS is based on a Linux OS, then yes, of course, qewd-conduit could be installed and run on it, eg by modifying the Dockerfiles setup, or simply shelling into the running container, installing Node.js, copying in the qewd-conduit repo files, running npm install and npm start. The key to modifying how/where qewd-conduit runs is just 2 configuration files: - the Node.js-specific package.json file. For Linux, Unix and MacOS systems, add "mg-dbx" as a dependency and make sure that the OS has a C++ compiler installed, since mg-dbx needs to be built from source during the npm install. For Windows, leave mg-dbx out as a dependency - QEWD will automatically download and install a pre-built Windows binary of mg-dbx when it is first run. - the QEWD-specific /configuration/config.json file which is used by QEWD to configure itself. In particular, the "database" section defines how the connection is to be made to IRIS or Cache, so that's where you define the path, namespace etc as appropriate for the instance of IRIS you want to connect. Note that the config.json file I've shipped assumes that you'll run qewd-conduit on the same physical machine as your instance of IRIS. However, you can change the settings to tell mg-dbx to connect to a separate IRIS (or Cache) instance via a network connection. Just explore the QEWD and mg-dbx documentation and you'll discover how to run qewd-conduit in any configuration you like on anything you like. It's a shame there's no publicly-available version of IRIS for a Raspberry Pi, because you could run qewd-conduit there too. You *could*, of course, run qewd-conduit on a Raspberry Pi and change the config.json to make a network connection to an IRIS system on a separate machine. QEWD really does provide the ultimate in flexibility for implementing IRIS/Cache REST services
go to post Rob Tweed · Oct 6, 2020 Yes, it would be possible to do so - it would be a simple matter of writing a process that invoked the appropriate Conduit REST APIs to create the articles, comments and links to authors/users from your data export. The one thing that might be tricky would be the user password property, which would be required for a user to log in and view/edit their own articles, and to follow other users and/or favourite their articles.
go to post Rob Tweed · Jun 2, 2020 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
go to post Rob Tweed · Apr 26, 2020 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
go to post Rob Tweed · Apr 14, 2020 That depends on your definition of "REST API on the Intersystems IRIS side". That Intersystems 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, Intersystems 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.
go to post Rob Tweed · Apr 13, 2020 So, provided Intersystems 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?
go to post Rob Tweed · Apr 10, 2020 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?
go to post Rob Tweed · Apr 10, 2020 Try using this interface module instead: https://github.com/chrisemunt/mg-dbx
go to post Rob Tweed · Mar 24, 2020 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
go to post Rob Tweed · Dec 23, 2019 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.
go to post Rob Tweed · Dec 22, 2019 Take a look at QEWD: This is a good place to start: https://github.com/robtweed/qewd-baselineThere are instructions on how to try it out with IRIS, but Cache is also supported (all versions) Both REST APIs and interactive browser-base applications (and Native Mobile apps also) can be quickly and easily developed. Security is built-in and it's all Open Source. QEWD main repository: https://github.com/robtweed/qewd See also QEWD-JSdb: https://github.com/robtweed/qewd-jsdb
go to post Rob Tweed · Dec 11, 2019 An update: the QEWD-baseline repository now also includes a fully-detailed tutorial on creating interactive, WebSocket-based browser applications If you want a very rapid way to develop your IRIS applications using WebSockets, and where all your logic is written in JavaScript, and where your IRIS data is accessed as QEWD-JSdb multi-model persistent objects, this is the place to look. For more info see: https://github.com/robtweed/qewd-baselineand specifically: https://github.com/robtweed/qewd-baseline/blob/master/INTERACTIVE.md By the way, the same techniques can be applied to Native Mobile application development
go to post Rob Tweed · Dec 4, 2019 I guess I'd summarise the "so what?" about QEWD-JSdb as follows: The "conventional" approach to database thinking is that your data is "over there" somewhere in some strange and alien technology called a "database", which also forces a particular type of data model on you and via APIs or protocols you have to learn. It tends to result in two types of developers: application developers who know a language, eg Node.js/JavaScript and build application logic,; and database developers who understand the black arts of data management but don't get their hands dirty with application development. The key concept in QEWD-JSdb is that the underlying IRIS database is accessed as JavaScript Objects that happen to be on disk rather than in-memory, and can be modelled how I, the developer, wants to handle it - which may differ depending on how I want to deal with the same data. There's no "database", just JavaScript objects that happen to persist in IRIS by means that I neither know nor care about. That kind of concept may ring a bell with some older IRIS developers, but to a modern audience it's potentially mind-bending, radical stuff. Perhaps so, but QEWD-JSdb now makes it possible in a modern Node.js / JavaScript setting. I suspect, also, for many developers new to IRIS, it will demonstrate ways of using its underlying physical storage that they never realised were possible. If that's piqued your interest and you have 5 minutes spare, that's literally all it will take to have it up and running and ready to play with. The browser-based viewer application will give you a real-time view of the IRIS database items you're playing with and how they change as you use QEWD-JSdb, so it's all "instant gratification!" and lots of (hopefully jaw-dropping) fun. Just the thing for long, dark winter evenings by the fire-side :-)
go to post Rob Tweed · Dec 3, 2019 Perhaps in time, but all the data models are described in detail in the associated documentation, plus you can try them out for yourself using the Explorer apps and associated viewer app. For now, therefore, I'd encourage people to take the time to read and follow the docs and take the tutorial Rob
go to post Rob Tweed · Apr 7, 2019 One limitation I can see straight away is that this version only includes outdated files for Node.js (ie the iris*.node files). All I see is iris610.node and iris700.node. Is there a reason why the Node.js version 8 and version 10 interface files haven't been included?
go to post Rob Tweed · Feb 8, 2019 Why aren't they made available using NPM, which is where a Node.js developer would expect to find such modules?
