✨ Wrote an essay about Riffle, a new project I've been working on w/ , and Daniel Jackson!
Guiding question: could we simplify app dev w/ a new kind of reactive local-first database?
Here's why I'm excited about this work:
Conversation
Great concept and essay! And thank you for so many inline resources!
I really appreciate how the essay is well scoped to focus on using sql as a state management, and yet, there are many golden nuggets and hints to more research areas and open questions.
1
3
About migrations: They could probably be automatically generated from code changes to the schema variable, either at compile time or runtime (with hot reload).
This could enable the state to be persisted between refreshes, even if the schema changes!
1
On the side note about your reactivity approach, what do you mean by table-granularity reactivity?
2
I also found interesting that by compiling query dependencies into a single one, you can delegate part of the dependency graph to SQLite.
In the sortedTracks example, would tracksQuery be computed twice if their deps change? (one for tracksQuery and another for sortedTracks)
1
Ideally not! You're right that the reactive graph semantics are super subtle; we're actually in the middle of a rewrite right now, trying to clean up all the mistakes we made the first time. 😅
I think we'll try to write up some of those details some day.
I ran into so many edge case scenarios when building reactive systems, it's the kind of field that keeps expanding the more you look at it.
I have a few notes on those edge case scenarios, and I'd be happy to share it!
I also hope to write about it one day.
1
1
Show replies