I agree that this should probably be an opt-in, per-model thing, especially to isolate any possible breaking changes to the existing query and mutation APIs.
I see content versioning as distinct layers of functionality, which could be implemented together or separately, depending on how people might actually use it.
- Add a reserved field name to every model, like
revisionId, which just tracks the revision count. Other than handling any possible conflicts with existing users, this shouldn’t break anybody’s code, and would add the benefit of tracking how many times a model has been saved (might be useful).
- Start recording revisions on the backend. Exposing a
revisionId input to the query and mutation API would give you basic version tracking, reverting, etc.
- Enable/enforce conflict detection. Systems like CouchDB require every write operation (mutation) to provide a
revisionId, and the server will reject any writes where they don’t match, because that means the client has old data. Supporting this on the server is simple (if
revisionID‘s don’t match, throw version mismatch error), but it would require work on the client side to display the error and help the user resolve the conflict(s). GraphCMS could do that in its own client, and leave it up to customers to handle themselves if they want conflict detection.
You could probably implement point 1 pretty silently, unless some customers are already using the field name you choose. Implementing point 2 is a lot more work, but making a per-model checkbox to enable it would prevent confusing existing users.
I think point 3 is a bit tougher, but would also serve double duty in providing a mechanism to edit-lock content, which is critical to provide atomic safety in write-heavy environments. Heck, I only have a handful of editors on one of our teams, but they still mess up each other’s content on occasion (think multiple editors rushing to get a new article or issue out; it gets hectic). It would be nice to see GraphCMS prevent that (see request #40 ).
Question: should revisions cascade up or down relations? It’s much simpler to say no, but then you could no longer trust revision ID’s to reflect overall change status, making it useless for stuff like cache management.