commit | 4075fcbaedadc7e5f4f124af5295e9621e0b565f | [log] [tgz] |
---|---|---|
author | Adam Sadovsky <asadovsky@gmail.com> | Mon Jul 20 10:58:10 2015 -0700 |
committer | Adam Sadovsky <asadovsky@gmail.com> | Mon Jul 20 11:01:08 2015 -0700 |
tree | c490740c4740c1895629ad4f032a4267ccfc4948 | |
parent | 6e21f5de74ef2a25bb05a26b3300fd1390f58a2c [diff] |
todosapp: start of changes to support sharing/sync - redo css (i.e. make it sane & make it easier to extend UI) - simplify and improve JS state management (prepare for concurrent updates from sync) - various other things Also includes some tangentially related fixes and tweaks: - add keys where needed to avoid react warnings - use less for css - use autoprefixer and cssnano for vendor prefixes and css compression - switch to ctrl-L to open/close in-dom console log - show loading message even while dispatcher is being initialized Change-Id: I531649b521d41ef83f2a6d4903879e3daad9f531
Todos is an example app that demonstrates use of Syncbase.
The commands below assume that the current working directory is $V23_ROOT/experimental/projects/todosapp
.
First, build all necessary binaries.
DEBUG=1 make build
Next, if you haven't already, generate credentials to use for running the local Syncbase daemon. When prompted, specify blessing extension “syncbase”. Note, the value of --v23.credentials
should correspond to the $TMPDIR
value specified when running start_syncbased.sh
.
./bin/principal seekblessings --v23.credentials tmp/creds
Next, start a local Syncbase daemon (in another terminal). Note, this script expects credentials in $TMPDIR/creds
, and configures Syncbase to persist data under root directory $TMPDIR/syncbase
.
TMPDIR=tmp ./tools/start_syncbased.sh # Or, start from a clean slate. rm -rf tmp/syncbase* && TMPDIR=tmp ./tools/start_syncbased.sh
Finally, start the web app.
DEBUG=1 make serve
Visit http://localhost:4000
in your browser to access the app.
By default, the web app will use an in-memory (in-browser-tab) local storage engine, and will not talk to Syncbase at all. To configure the app to talk to Syncbase, add d=syncbase
to the url query params, or simply click the storage engine indicator in the top right corner to toggle it.
When using Syncbase, by default the app attempts to contact the Syncbase service using the Vanadium object name /localhost:8200
. To specify a different name, add n=<name>
to the url query params.
Beware that start_syncbased.sh
starts Syncbase with completely open ACLs. This is safe if Syncbase is only accessible locally (the default), but more dangerous if this Syncbase instance is configured to be accessible via a global mount table.
Todos is implemented as a single-page JavaScript web application that communicates with a local Syncbase daemon through the Vanadium Chrome extension. The app UI is built using HTML and CSS, using React as a model-view framework.
The Syncbase data layout and conflict resolution scheme for this app are described here. For now, when an item is deleted, any sub-items that were added concurrently (on some other device) are orphaned. Eventually, we‘ll GC orphaned records; for now, we don’t bother. This orphaning-based approach enables us to use simple last-one-wins conflict resolution for all records stored in Syncbase.
At startup, the web app checks whether its backing store (e.g. Syncbase) is empty; if so, it writes some todo lists to the store (see browser/defaults.js
). Next, the app proceeds to render the UI. To do so, it scans the store and sets up in-memory data structures representing the user's todo lists, then draws the UI (using React) based on the state of these in-memory data structures.
When a user performs a mutation through the UI, the app issues a corresponding method call against its dispatcher (see browser/dispatcher.js
), which ends up writing to the backing store and emitting a 'change'
event. The web app listens for 'change'
events; when one is received, it re-reads any pertinent state from the backing store (again, via the dispatcher interface), updates its in-memory data structures, and redraws the UI.
When changes are received via Syncbase sync, the dispatcher discovers these changes (currently via polling; soon, via watch) and emits a 'change'
event, triggering the same redraw procedure as described above.
Signature
$V23_ROOT/release/go/bin/vrpc -v23.credentials=tmp/creds signature /localhost:8200
Method call
$V23_ROOT/release/go/bin/vrpc -v23.credentials=tmp/creds call /localhost:8200 GetPermissions $V23_ROOT/release/go/bin/vrpc -v23.credentials=tmp/creds call /localhost:8200/todos/db/tb Scan '""' '""'
Glob
$V23_ROOT/release/go/bin/namespace -v23.credentials=tmp/creds glob "/localhost:8200/..."
Debug
$V23_ROOT/release/go/bin/debug -v23.credentials=tmp/creds glob "/localhost:8200/__debug/stats/rpc/server/routing-id/..." $V23_ROOT/release/go/bin/debug -v23.credentials=tmp/creds stats read "/localhost:8200/__debug/stats/rpc/server/routing-id/c61964ab4c72ee522067eb6d5ddd22fc/methods/BeginBatch/latency-ms"
For debugging performance issues, it can be helpful to use the JS integration test configuration. To do so, first run the integration test as follows.
cd $V23_ROOT/roadmap/javascript/syncbase NOQUIT=1 NOHEADLESS=1 make test-integration-browser
This command starts a local mount table, identityd, and Syncbase mounted at test/syncbased, then launches an instance of Chrome with a custom-built Vanadium extension configured to talk to the local mount table and identityd.
Scroll up in the test output to get the test environment configuration, in particular the mount table endpoint, V23_NAMESPACE
. Glob the locally mounted syncbase as follows.
$V23_ROOT/release/go/bin/namespace -v23.credentials=/usr/local/google/home/sadovsky/vanadium/roadmap/javascript/syncbase/tmp/test-credentials glob "/@5@ws@127.0.0.1:41249@7d24de5a57f6532b184562654ad2c554@m@test/child@@/test/syncbased/..."
Visit http://localhost:4000/?d=syncbase&n=test/syncbased
in the launched Chrome instance to talk to your test syncbase.
To run a simple benchmark (100 puts, followed by a scan of those rows), specify query param bm=1
.
All numbers assume dev console is closed, and assume non-test setup as described above.
Currently, parallel 100 puts takes 4s, and scanning 100 rows takes 0.6s.
For the puts, avoiding unnecessarily cautious Signature RPC and avoiding 2x blowup from unnecessary Resolve calls will help. Parallelism doesn't help as much as one would hope, need to understand why.
For the scan, 100ms comes from JS encode/decode, and probably much of the rest from WSPR. Needs further digging.