Magnificent Events

Magnificent Events
------------------

A backend event-based websocket/REST database and Javascript app-development framework.


### Seriously? Isn't that just a bunch of buzzwords mashed together? ###

Yeah, I know. I still think it might be useful. 

### What does it do? ###

Javascript clients get access to a local database. This local database is called a "Workspace" and is kept synchronized across all Javascript clients subscribed to the same Workspace. This database is an abstraction sitting on top of localStorage data, a REST service provided by Magnificent Events, and a WebSocket connection to Magnificent Events for getting updates.

### What are the underlying technologies? ###

I was fiddling with Google App Engine, GAE-ndb, GAE-Webapp2, GAE-Channels, but it feels like Cassandra+Flask+Autobahn might provide similar umph but with less vendor lock-in. This is seriously not nailed down yet. 

### How do you imagine it working? ###

* Client Andy creates a new connection to Workspace Arglebargle
* Client Andy creates a Model for `/thing` , a list of things
* `/thing` doesn't exist in localStorage
* `/workspace/arglebargle/thing` is requested from a data snapshot on the REST server. `/thing` is put into local data
* `/workspace/arglebargle` was last updated on the REST server at timestamp <five minutes ago>. 
* `/workspace/arglebargle/thing/events?after=<five minutes ago>` is requested from the REST server. `/thing` has received 2 updates since the last time it was snapshotted. These updates are applied to local data. 
* `/thing` is up to date, and returned to the user, possibly in the form of a lucidJS event. 
* Client Bob creates a new connection to Workspace Arglebargle and requests `/thing` and `/otherthing`
* Client Bob changes `/thing/<thing-id>`.
* `/workspace/arglebargle/thing/events` is sent a POST with an 'update' event containing the change to `/thing/<thing-id>`
* The update to `/thing/<thing-id>` is saved to the database
* Workspace Arglebargle is added to a queue of workspaces whose REST data is dirty
* Client Andy receives an event with an 'update' event containing the change to `/thing/<thing-id>`, which is immediately applied to the /thing model, triggering a UI update.
* Client Bob changes `/otherthing/<thing-id>`
* The same server foofaraw happens. Client Andy recieves the update to `/otherthing/<thing-id>`, but without a `/otherthing` Model to apply that update to, simply discards it. 
* Client Andy closes the browser and gets lunch.
* Client Bob changes `/thing` about 1000 more times.
* A scheduled job applies all events after /workspace/arglebargle's last snapshot to a new snapshot, then sets the last-snapshot time to now()
* Client Andy opens the browser.
* Client Andy creates a Model for `/thing` , a list of things
* `/thing` exists in localstorage and is usable right away! 
* `/thing`'s last update was before lunch.
* `/thing` undergoes the same update process as before to get up to speed. 

... and so on and so forth.