This is a very similar philosophy to the MobX library (normally paired with React), and also to the programming language I'm building: https://github.com/brundonsmith/bagel
Yeah, MobX is a great tool for fine-grained reactivity + managing state outside UI tree. I haven't seen anyone try relational querying in MobX, would be curious if that's a thing.
I've just skimmed the article but I'm definitely going to give it a proper read.
We've built an architecture somewhat like this where we're using MobX objects in the frontend (a graph of the db objects effectively) that's patched by subscriptions to tables via hasura. So we effectively have all the data on hand locally all the time and use the reactivity on top of that.
We actually played around with sqlite in wasm because I really really miss having a real relational db in the frontend. We decided that there was just a few too many unknowns to proceed further with the idea. Initially we were using indexdb as a frontend cache but dropped that since without adding more layers to it it doesn't provide much value.
(Also played around with using Solid's direct mobx -> jsx library without having react inbetween https://github.com/ryansolid/mobx-jsx but, again, too much unproven tech to build on).
The work you're doing here is super exciting. The developer experience of what we currently have is pretty nice and I can definitely see your model working out well in the future.
That is an interesting question. Theoretically it should work - it's all just data - assuming you could implement relational querying efficiently in JavaScript itself
I agree with your assessment, and it's just the younger generation catching up to older established wisdom.
The tragic irony is how hard many of that generation badmouthed the old ways of doing things. For instance ADO.NET with datatables/dataviews was often looked down upon, but through working more with people who did so it turned out that they just didn't understand it, so often that it's basically ten times out of ten.
Because you usually link it to a DataView and then the DataView updates when the underlying data changes. Same for QSqlTable, it links up with a QTableView.
Yeah, Svelte or Solid is probably a more natural fit than React. But at the end of the essay we propose a weirder alternative, which is to implement the UI templating itself as just part of a DB query.
I've always had a soft spot in my heart for PHP style "raw query in the template". Even as we've moved away from that I feel like GraphQL recapitulates a lot of the reasons why having queries tightly bound to views is convenient.
It feels like "put the template in the query" is a great Uno reverse to "put the query in the template" and the associated issues it brings, but I'll have to think on the consequences more. Thought provoking article!
https://www.hytradboi.com/