mbilokonsky / deltadog Goto Github PK

Having the entire utility of this tool explained in a single long example.js file is not the best way to do this.

We should have a suite of tests that make assertions against state at time T, and all of our examples should be implemented in isolated tests.

Finally cracked the conceptual nut that was so obvious in retrospect. Let's consider a person with a name and a set of friends, each of which is also a person.

type Person = {
  name: String!
  friends: [Person]
}

In DeltaDog terms, we have (1) a set of empty entities representing people, (2) a set of deltas that assign names to those people, and (3) a set of deltas that assign friendship among these people.

  // empty domain objects
  myk = createDelta()
  han = createDelta()
  david = createDelta()
  alex = createDelta()

  // name relationships
  nameMyk = createNameRelationship(myk, 'myk')
  nameHan = createNameRelationship(han, 'han')
  nameDavid = createNameRelationship(david, 'david')
  nameAlex = createNameRelationship(alex, 'alex')

  // establish some friendships
  mykHan = createFriendshipRelationship(myk, han)
  mykDavid = createFriendshipRelationship(myk, david)
  mykAlex = createFriendshipRelationship(myk, alex)
  hanAlex = createFriendshipRelationship(han, alex)
  davidHan = createFriendshipRelationship(david, han)

Ok, so far so good, right? So how do we use that GraphQL schema defined above to allow us to interface with this set of deltas?

We'd need a resolver that looks something like this:

{
  person: id => universe.lookupById(id),
  name: (_, parent) => universe.lookupNameById(parent.id),
  friends: (_, parent) => parent // this flow returns a set of IDs for friends of the parent
                                       .pointers
                                       .(filter for those that set friendship and target other deltas)
                                       .map(pointer => pointer.target) 

}

Does that make sense? I'm not sure that this is all valid GraphQL but conceptually I think it works. It's just a question of encoding the DeltaDog level semantics inside of the resolvers. Users don't need to know that there's such a thing as a pointer ID that represents 'setting friendship' - they just want the list of friends, right?

Does this get us there? (@orta no pressure to weigh in but if you're interested, does my reasoning here make any sense?)

GraphQL is a powerful query language that allows you to declare a single flat declarative schema for your queries which it then fills. This is exactly what I'm trying to capture with my flattening rules and reconciliation logic - queries can contain custom resolvers that flatten the data into any shape desired.

Workflow should be:

DD.createRelationship() as the core behavior of the data module.
DD.createStore() as the core behavior of the store module.
Store.query(gql) as the core behavior of the query module.

A store provides a unified interface over a universe of facts. The API should look something like this:

  const store = DD.createStore();
  const some_delta = DD.createEntity();
  store.write(some_delta);

  const query = {
    search: some_delta.id
  };
  store.executeQuery(query);  // returns some_delta;

  const query2 = {
    search: some_delta.id,
    schema: some_schema_id,
    flattener: some_flattener_id
  };
  store.executeQuery(query2); // returns some flattened materialized view of some_delta

  const stream = store
    .subscribeToQuery(query2);

  stream.on('data', e => {
    console.log(e); // an updated materialized view. This emits whenever materialized view changes.
  });