Hacker News Reader

Comment by toasterlovin | Hacker News Reader

You still need to do all the same things as before. Some things you move to the client, other things you move to the dbms. There isn't some functionality that magically disappears when you no longer have, for example, a PHP/Ruby/Python/JS/whatever server mediating between your client and your database.

View on HN

My proposal is that almost nothing moves to the dbms, everything moves to the client except perhaps authorization. Unfortunately I can't fully defend my line of reasoning without saying, here's a link to my fully described or developed alternative architecture, which I don't have. However that doesn't mean it's not possible, it seems to me to be achievable. Even if it would require changes to HTTP, the database (row, column, and cell-level authorization?), or the browser - the end result would presumably be worth it. I imagine it would be much easier to reason about an application that is data and data authorization on one side, and logic on the other.

> I imagine it would be much easier to reason about an application that is data and data authorization on one side, and logic on the other.

You're basically describing, for example, a Ember/Android/iOS + Rails + Postgres app. Logic lives in the client (Ember/Android/iOS). Data + Authorization lives in Rails + Postgres. And the Rails part of that is really not doing much. It's deciding if a request is allowed, then serializing or deserializing data from the database. I guess you can do that in the dbms, but you still need to do that somewhere.

The object-relational impedance mismatch disappears when the dbms is an immutable time series, which means a whole bunch of plumbing code does indeed evaporate

How do you decide who can write to and read from your data store?

Reply on news.ycombinator.com