EWD.js for the Raspberry Pi

I’ve been wanting to be able to run EWD on the $35 Raspberry Pi for ages.  Not only is it an amazing cheap but surprisingly powerful and capable computer in its own right, the Raspberry Pi is very much targeted at the educational sector, with an aim of encouraging a new generation of developers to get into computing.  It has also become a key hacker’s platform, allowing all sorts of robotics experimentation and general cool stuff to be possible at a negligible cost.  With 2 million units already sold, the development community for the Raspberry Pi is already huge and continuing to grow at a rapid rate.

Node.js has been ported to the Raspberry Pi for quite a long time, and running EWD on top of Node.js on the Raspberry Pi has been my target.  What I’d been hoping for was a version of either the GT.M or GlobalsDB databases to be ported to the ARM-based Raspberry Pi: EWD relies on these databases in order to work.  Disappointingly, despite me raising some interest from the GT.M Open Source development community and InterSystems (the owner of GlobalsDB), I’ve been waiting, Godot-like, without any sign of progress in sight.  Personally I think the two camps are missing out on a huge opportunity: perhaps they just don’t “get it”.  Anyway, for now I’ve given up on either camp coming up with the goods.

At the end of last week I decided to have a think about possible alternative solutions to moving things forward.  EWD.js is now, of course, the variant of EWD that makes sense to port to the Raspberry Pi.  But how to do this without a Mumps database at the back-end?

I considered MongoDB, but I needed a synchronous interface in order for integration with EWD.js to be a possibility.  I also looked at a number of the so-called “text file” and “native JavaScript” databases that people have been playing around within the Node.js community, and whilst none looked suitable, they sparked a crazy idea in my mind.

EWD.js integrates with GT.M and GlobalsDB via an interface that was first developed on behalf of InterSystems by my fellow-M/Gateway director Chris Munt, and which was then reverse-engineered by David Wicksell for use with GT.M.  This interface defines a set of core, primitive JavaScript APIs that provide access to the basic operations needed to manipulate a Mumps database.  The “back-end” of EWD.js has been built on top of these APIs.

So, I thought, suppose I did another reverse-engineer of these APIs only with a twist: create a version of the APIs that didn’t actually talk to a database at all, but manipulated a JavaScript object in a way that  simulated the behaviour of a Mumps database?  EWD.js wouldn’t know that it wasn’t using a real Mumps database, so it should work!

Of course there was a key limitation to this idea: I’d only be able to use a single Child Process for EWD.js, but since this is a Raspberry Pi we’re talking about, that seemed a reasonable compromise to make.

The result of a few frantic days of coding is what I’m now calling noDB.js: a JavaScript simulation of a single-user Mumps database.  Along the way I added a sneaky trick to noDB.js: the APIs that change its contents (the set and kill APIs) set a flag that denotes that a change has occurred.  Every minute, noDB.js fires an event that checks this flag and if true, writes out the JSON object asynchronously to a text file (named noDB.txt).  When EWD.js is next started, the database open() API reads the contents of this file and parses the JSON it contains, effectively recovering the state of the noDB.js JavaScript object back to where it had previously left off.  In other words, noDB.js is a truly persistent database!

And so we now have EWD.js up and running on the Raspberry Pi: it’s pretty amazing seeing it running and at the same time looking at this tiny card connected up by a bunch of wires to a keyboard, mouse, my TV and network and with a 4Gb SD acting as its hard-drive.  All my standard EWD.js demo applications and the ewdMonitor application work perfectly, and they’re surprisingly fast too.

Although I can’t run, for example, a copy of VistA on the Raspberry Pi, here’s what I can do with it:

  • I can load the ewdliteclient module: this provides a secured JSON-based Web Service client for EWD.js running on the Raspberry Pi from which my applications can access an EWD.js-interfaced VistA system on a SOA basis.
  • Having retrieved data from a VistA system, I can save it locally on my Pi-based EWD.js system, building up a local database cache over time.
  • Alternatively I could build a copy of the noDB.txt file from data on another system and use this to pre-populate the database of a Raspberry Pi-based EWD.js system
  • I can also fire messages into another EWD.js system via the latter’s socket listener interface, and so the Raspberry Pi can send in data feeds to another EWD.js application on another platform.

Basically it puts EWD.js into the hands of hackers and, together with EWD.js-interfaced VistA providing the world’s only Open Source, Node.js-interfaced fully-fledged EHR, provides everything needed to kick-start a new era of Open Source innovation in the Health IT space.

If you’re interested in trying out EWD.js on the Raspberry Pi, I’ve added a new Appendix 4 to the EWD.js documentation that explains everything you need to do.  I’ve already added noDB.js and a Raspberry Pi-specific EWD startup file to the EWD.js repository.  And if you don’t have a Raspberry Pi yet, what are you waiting for?  At only $35 you have no excuse!

Let the hacking begin!



  1. Rob,

    It is very exciting to hear about this developments.

    The port of GT.M to the Raspberry Pi (and to ARM in general) is making some progress here:

    It is not going as fast as we all would like to go, but it is inch by inch making progress:

    Most of the development is currently happening in a Samsung Chromebook, using crouton:

    and it is being compiled regularly on the Raspberry Pi (since this Chromebook is armv7 and the Pi is armv6, we need to check portability often)

    This takes advantage of the adaptation of GT.M to use CMake, that was done during the packaging of fis-gtm for the Debian Linux distribution.

    Any help from Raspberry Pi and ARM enthusiasts out there, will be very welcome. 🙂

    at the State University of New York at Albany we had this Fall semester a class of 900 students using Raspberry Pis (each student) instead of a textbook for their introduction to “Information in the 21st century”. More details are here in this blog post at opensource.com:

  2. Luis

    That’s good to hear. I still think a port of GT.M to the Pi will be an important opportunity for this community so I would strongly encourage everyone to make it possible. Unfortunately it’s outside my sphere of knowledge, otherwise I’d definitely be participating and driving it hard.

    In the meantime, noDB.js provides a pretty sneaky alternative and only took 3 days to write 🙂

    Of course, noDB.js could be used on any platform, not just the Pi, if anyone is interested in experimenting with it


  3. Rob,

    this is great news.
    This really opens up EWD.js for everyone to start experimenting.
    I have already informed my family what I want for xmas so that I can start hacking.


  4. This actually would be really great for testing EWD.js applications or APIs. It looks like a very effective mocking framework. Since the text file presumable is just stringified JSON it would be easy to create mock test data too, and verify changes outside of the API.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: