Sacha Greif

Actually maybe `find` should be `list` to maintain consistency with the resolvers and the client-facing API?

Maybe `update` and `remove` should take a `selector` rather than a `documentId`? We have the case of wanting to remove all dummy users in Vulcan for example.

Yeah I guess I hadn't thought about mutations… See https://github.com/binaryseed/graphql-spec/blob/3532cc6edc1cde132ad35e4ff9b1e9ed105a03f0/rfcs/InputUnion.md (discussion here: https://github.com/graphql/graphql-spec/pull/618/files) In that case should we leave this off until this gets resolved in the GraphQL spec? I...

This seems relevant? https://adamwathan.me/2019/10/17/persistent-layout-patterns-in-nextjs/

By "PWA" do you mean service workers? No, Vulcan doesn't use any at the moment.

That does seem a little tricky. Currently `onCreate`/`onUpdate`/etc. run completely outside of SimpleSchema, but maybe there's a way to "integrate" them into the SS validation? Assuming SS has equivalent callbacks....

Maybe "decorator" would be a better name than "template"?

Almost, it's: ``` articles: { type: Array, canRead: ['guests'], group: articleGroup, optional: true, blackbox: true, canCreate: ['members'], canUpdate: ['members'], itemType:articleSchema

Actually it'll be ``` arrayItem: { type: String } ``` instead of ``` itemType: String ``` This way you can just specify any property that would normally go on the...

> As @doronrk suggested, this could eventually also help dissociate the database and API fields It's probably worth digging into this further. For example, we could imagine a new format...