I might be wrong here but it just dissecting this two principles I can see few issues: All data is realtime and reflects the latest database state: Local s

I might be wrong here but it just dissecting this two principles I can see few issues: All data is realtime and reflects the latest database state: Local state management is fundamentally hard as it's dealing with distributed system problems. Best to avoid it alltogether. Local state is hard because of state management available. MobX largely addresses the issue and it's not really related to distributed systems. All database operations go through a unified standard interface, IHP DataSync in our case. Yikes. Absolutely do not want to replace an established, transparent, "boring" process with some Rube Goldberg machine that I'm held hostage to. This looks okay for building MVP, as most of these tools seem to be aimed at. However, companies with existing product or looking to make their APIs as a core product wouldn't want to lock it down and be held hostage by a Rube Goldberg machine. For full stack developers, it really isn't too much of an effort to create backend API endpoints separately and hooking it up to your frontend either. I invite you and others to share their points but just from the get go, perhaps I'm older now and have become wary of the next shiny solution favoring boring tech, the problem you are solving appears to be a non-issue for most live world existing API/Frontend products, as well as full stack developers (for ex. scaffold crud generators are a thing). The cost of moving faster by taking on hidden technical debt especially in a core, essential part (the api) of the product by a 3rd party looking to remove that have typically ben risky. Also, I couldn't quite understand what was happening underneath the hood so might be good to share more technological risks/debts that is implicit.