Make sure the design works well for nesting server-side GraphQL with client state about apollo-link-state

[jbaxleyiii]

@glasser @stubailo this is a great sample to have written as a test and documented! It also brings up an interesting question about data resolution in this space.

Given the above query:

query list {
  list(name: "my list") {
    items {
      name
      isDone
      isSelected @client
    }
  }
}

I would imagine determining the isSelectedStatus may need to come from the sibling data. On the server, a resolver like isDone would be called with the source data of the fetched items. On the client, something like an id would most likely be the link between some level of local saving of data.

I think when applying the resolvers for types, we need to ensure server data is passed at its level to extend server data into calculated values.

This would also give the ability to an idea @evans pitched to me at Summit which would allow the local state link to augment the server schema with virtual fields. For instance:

query Me {
  user {
    firstName
    lastName
    fullName @client
  }
}

Where fullName is a calculated value of firstName + ' ' + lastName

[jbaxleyiii]

@glasser test added here

One thing I am concerned about is writing to the cache for sibling client fields as this should ideally be batched into a single write operation. This would be beneficial for updates as well so maybe a dataProxy api for batch writes?