@f0a this looks interesting.

Is it intended for single-user databases/content?

Or, if it's for multi-user stuff, then how is the resource ownership and access-control handled?

Where sits the business logic?

@kravemir thank you! Graft supports multiple writers to the same Volume, although it uses optimistic concurrency. So if you have a high number of writes from multiple users to the same database it may not be the right fit. However, Graft can easily handle a Volume per user, which can work well when your data can be sharded. Think of Graft like a building block which you can use to build distributed systems.

Business logic wise, Graft embeds directly in your application just like SQLite!

Hope that helps :)

@f0a how does the optimistic concurrency work in combination with "Offline-first & mobile apps".

What if transaction fails due to optimistic lock issue? And, this is delayed - once client becomes online (which can be long enough for user to do other actions or even create depending depending).

Does the application need to implement a mechanism to handle these delayed rollbacks? The (user's) data shouldn't just silently disappear.