✨ 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
thanks for sharing! as someone who's deeply afraid of backend and sql, i wonder if one route isn't pushing state towards sql/db, but rather the other way: pulling persistent storage toward json/common app data structures
1
3
when i was using darklang a few years ago i remember at one point asking how the data i was writing was stored, and at the time they were simply stored as json blobs (within a db, but as far as my apps data was concerned, everything was json) that make things easier to reason
1
also as i worked on multiplayer apps like sprout and felt, so much of the state work was taking updates/patches over websockets and merging it to local client state JSON
1
1
anyway, this is more implementation detail i suppose, but the general spirit of bringing app state and db into one place i find compelling! i end up doing that with most of my personal app experiments (in frontend, bc i always avoid using dbs)
1
1
yeah makes sense! curious if you have opinions on tools like yjs / automerge that help manage JSON data?
Also hear you on being afraid of SQL. Some of that is SQL's fault for being weird in various ways. But I'd like to see the core idea of relational used more in frontend...
2
3
Eg, any time you have flat normalized collections in JSON (eg, array of authors and array of books, instead of embedding books inside authors), that's starting to approach something where the relational model can be so helpful!!
1
1
100%, spoke to this in my other reply but thats kinda what i'm driving at — is what if riffle used json instead of sqlite (and sure, it can store the json in a sqlite or indexdb or whatever, but the SQL-ness is completely hidden from the app dev)
2
2
I think a lot of "SQL-ness" is off-putting not because of the core conceptual ideas (relations, joins, normalized data, declarative queries) but because SQL itself is just old and weird. I'm a big fan of relational queries but I kind of hate how the queries look in our demo.
It's fun to think about what a query language that's actually as nice as (or even nicer than?) working with JSON in Javascript would look like.
1
1
I think that GraphQL sets the bar for the projection language (i.e., the SELECT clause where you describe how the results are shaped).
I like the vibe of PartiQL for working with tree-structured data (like JSON) in a relational context: partiql.org
1
1
Show replies