✨The final part of one of our most-loved series just dropped ✨
Some of you have been following as we build a real-time multi-user Kanban board with @couchdb and @sveltejs.
We’ve already covered requirements + manual and automatic conflict resolution. Post 4/4 delves into UI locking and fun features like audit trails.
Check it out: https://neighbourhood.ie/blog/2025/01/15/resource-locking-with-couchdb-and-svelte
I haven’t read the whole series, but will try to, but until I do I feel like I’m missing something. Why bother with locking at all in this case? Can’t you just check that the record hasn’t been changed and then tell the user if it has, or force a reload? What do you gain with the lock file here? I’m imagining just checking that the card record has the same timestamp you saw when you loaded the data the first time, or that a hash hasn’t changed, etc.
@tyler great question! This tutorial is less “here’s what we’re building in three steps” and more “here are three ways to achieve a goal, let’s explore trade-offs of each.”
In the series, locking is the last thing we explore to prevent conflicts and ensure no one’s data is overwritten. Not all conflicts are equal. Locking solves for some cases automatic resolution can’t catch, but also introduces complexity and adds limitations to the offline capabilities of CouchDB.
