> writing all the data mutation logic within a reducer that can be easily shared on both the client and the server
This part… makes me feel odd. Is it actually realistic? Reducers for everything, keeping WASM and backend code in sync. Sounds like a lot of work and cognitive overhead.
The idea is that the reducer is your backend code. Think about it like writing your normal API layer. You handle requests and make changes to the database. Since it's Wasm, SQLSync automatically runs it on both the client and the server. Thus you've written your backend once but ran it everywhere.
As for the question of "what if my backend should access stuff that the client doesn't have access to" - the answer is that the reducer doesn't need to do the same thing in both environments. It's easy to call out from the Reducer into an Auth API which only runs on the server. SQLSync will guarantee that everyone reaches a consistent state even if the same mutation results in different outcomes when run locally vs remotely.
Good start but it's a bit single rainbow right now.
It will take a looong time to become as useful as Campfire because all of the hooks/apps for it that already exist. Opensource is nice but Holla needs some kind of passion-creating feature/vision that would attract a decent community of contributors.
Oh, and I have to add that I'm a 'product guy'. I do see that the tech behind it is both cutting edge and solid but I tend to drift towards the market fit thoughts whenever I see new apps.
