Feature: Database Load/Save/Synchronize Persist with Multiple Apps

[daveseah]

WHAT'S NEW

You can now:

• run multiple instances of the app
• all apps read/write from the same database
• all apps update in real time as data changes
• Data persists on the server, and is autosaved every 4 seconds if the database changes.

We do not yet have support for sessions, but this should be pretty straightforward to implement once we discuss and approve a design for sessions is approved. The preliminary design document is in located in the wiki.

TESTING

The goal is to experience the multi-app networked database features, using it as a springboard for refining features as well as continuing to gather feedback/report bugs. To test, try the following:

(1) RUN TWO INSTANCES

• run the build from the terminal of the hosting Macintosh
• use Chrome to open localhost:3000
• note the "remote IP address" (e.g. *** CLIENTS - http://192.168.1.182:3000) then use Chrome on another computer on the same LAN to access it.
• try running on MORE computers (this should work, but I haven't tested this extensively)

(2) EDIT DATA

• use the GUI to update nodes/edges on one computer
• see that the node/edge update on other computers

(3) INSPECT DATABASE

• the database file is stored in build/runtime/netcreate.json
• watch the database file change as data is updated

(4) LOAD A FRESH SET OF DATA

• browse to http://localhost:3000/#dev-db on the host machine, or select DEVELOPER/DATABASE TESTS from the dropdown menu on the upper right
• open the javascript console with CMD-OPT J
• type the command ncPushDatabase('empty.json') in the console and press ENTER
• reload the prototype apps with CMD-R to reload the data
• inspect the database file in build/runtime/netcreate.json to see how it changed
• restore the original test database by typing ncPushDatabase()
• note that all the database json files used for initializing data sets are located in build/app/assets/data

KNOWN ISSUES

• REACT ERRORS and GUI BUGS - With recent updates to the REACT GUI library, a lot more warnings are being thrown in the console. Will need to confer with Ben to see if these were already in the build prior to this work, and figure out what to do about them.

• MULTIPLE DATABASE WRITES - Each client sends a database update of the same data, because of the way that I patched-in to the existing demo by "shadowing" some internal message calls. Thus, when one instance updates a node, the 'SOURCE_UPDATE' message is captured by the database layer and forwarded to the server. UNISYS also forwards 'SOURCE_UPDATE' to all connected apps, so those instances ALSO respond and THEIR database layers push the same data to the server. This is obviously not the way it should work, but it was the quickest way to make the demo happen without trying to rewrite the existing demo. Again, will need to confer with Ben to replace the current approach that's in use.

NEXT STEPS

It might be useful to write a reference for how to think about UNISYS' features for researchers. Because it's an asynchronous and sequential messaging system that works without explicit endpoint addressing, it can be used to model complex interactions fairly easily with a handful of basic concepts.

[daveseah]

to test:

git clone https://github.com/daveseah/netcreate-2018.git TEST-NC
cd TEST-NC
git checkout dev-ds/unisys-dataserve
cd build
npm run dev

• tested DevUnisysTest: runs correctly, no RegisterMessagesP undefined error
• tested deployed default database runtime/netcreate.json is present and loads initially
• tested (1), (2), (3) in Pull Request description
• tested (4)

[benloh]

One additional note: Running ncPushDatabase on Safari does not seem to update the database.