Atomic client side stores with server sync

whatIReallyReallyWant.md

At CampJS this week there were a lot of talks about frontend web components, mostly focused on views. It struck me, as a mostly backend engineer that we could do with some better abstractions around client side/server side data sync to go with the new view model systems out there. Here's a few thoughts I had over the weekend..

A client side, in memory data store:

1. Which is atomic (transactional?)
2. With data that is strongly typed (validated)
3. That syncs to a server (which is authoritative)
4. That syncs uncommitted content to local storage transparently
5. That is resilient to connectivity trouble
6. That is bounded by the developer
7. That is performant
8. That is easy to reason about
9. That lends itself to one way data binding
10. That lends itself to global (long lived) and local (throw-away) scoped stores.

Concept:

Strongly typed REDIS-like VERB actions on dot path, zero-setup stores. This is just a brainstorm not a finished api, I have no idea what models would look like yet:

Define a store, create an index

> STORE @catStore sync=wss://example.com/cats autosync=true localsync=IndexedDB://catStore ...
> INDEX @catStore.age

Create a new Cat, note the extra data/flags added

> APPEND @catStore Cat{name: "pixel", age: 12}
{
  Type: "Cat",
  Id: "a3c2388e11344e66446c09eef1a325f6",
  Dirty: true,
  name: "pixel",
  age: 12
}

Find our cat by index search, note Dirty is gone, can be used in view model data bindings to show state

> GET @catStore.age 12
[{
  Type: "Cat",
  Id: "a3c2388e11344e66446c09eef1a325f6",
  Syncd: "2017-08-07T06:23:10.590Z"
  name: "pixel",
  age: 12
}]```

what I really really want? I wanna, I wanna, I wanna really really stop losing user's data when systems fail