[NilMostChill]

That's....certainly a take.

it hurts that it's not exactly wrong.

but i don't think it's 100% right either, there are some things that you just can't do reliably, in current db engines at least.

As soon as you start baking this kind of support in to the db all you have if a db engine that has all the other bits stuffed in it.

They'll still have most of the issues you describe, it'll just be all in the "db layer" of the engine.

[jiggawatts]

I'm not thinking of "current" DB engines, but an entirely new stack that is end-to-end JavaScript (or WASM).

Something like Java's Akka or .NET Orleans combined with React.

So the "data" would be persisted by stateful Actors, which can run either on the server or in the browser, using the exact same code. Actors running in the browser can persist to localStorage and on the server the actors can persist to blob storage or whatever.

Actors have unique addresses that can be used to activate them. In this system these become standard HTTP URIs so that there is a uniform calling convention.

[NilMostChill]

It sounds interesting, but its still just moving the problem surface elsewhere.

Bringing model definition and usage closer to the storage layer thereby reducing the need for translation and transport might cut down on the need for repeated and variant definitions across layers but it doesn't remove the other issues related to data storage.

There will need to be a system for storage and that will have to deal with transactional state management as well as consistency schemes, having that in an actor layer that is shared with other parts of the system might solve some issues, but it'd need to be really carefully managed so as not to inflict the solutions to those problems on the other parts of the system using the same transport mechanisms.

i dislike javascript with a passion but I'd be down for using a wasm based system that does what you say, my skepticism is usually just me shouting at clouds so it'd be interesting to see a working model.

[corey_moncure]

Yes inside the DB where it cannot be debugged or optimized

[NilMostChill]

If you're putting advanced feature support into a db engine , you're probably also putting in semi-competent debugging support (at least i'd hope so).

But again, at that point you're really just moving the surface rather than addressing the issues.