5 ms·

Thanks for pointing me to that article. I've been mulling over for years how to architect apps to remove the server, that layer never sat well with me. I've als

by jrcii 10y ago

Thanks for pointing me to that article. I've been mulling over for years how to architect apps to remove the server, that layer never sat well with me. I've also found I couldn't discuss the problem with anyone because "clients can't access the database directly!" is such a knee-jerk reaction.

yawaramin 10y ago
If clients access the database directly, then the database is now the server. You haven't removed the server, you've just moved it.
- jrcii 10y ago
  By removing the server-side layer I mean, for example, moving the "model" logic in MVC to the client. The database is still there, but it doesn't perform any application logic, so the server-side layer is moved to the client, not the database. The challenge then becomes authorization. Ideally even the database would be ad-hoc distributed yet would maintain authorization functions or at least the practical result of them, so there's no server-side whatsoever.
  - HillRat 10y ago
    But if your server doesn't enforce data consistency -- that is, the business logic resides on the client -- you can't rely on the quality of your input. And if your authorization sanitizes the data to ensure consistency, then you've just built your middle tier for logic.
  - toasterlovin 10y ago
    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.
    - jrcii 10y ago
      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.
      - toasterlovin 10y ago
        > 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.
    - dustingetz 10y ago
      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
      - toasterlovin 10y ago
        How do you decide who can write to and read from your data store?

by jrcii 10y ago

yawaramin 10y ago

If clients access the database directly, then the database is now the server. You haven't removed the server, you've just moved it.

jrcii 10y ago
By removing the server-side layer I mean, for example, moving the "model" logic in MVC to the client. The database is still there, but it doesn't perform any application logic, so the server-side layer is moved to the client, not the database. The challenge then becomes authorization. Ideally even the database would be ad-hoc distributed yet would maintain authorization functions or at least the practical result of them, so there's no server-side whatsoever.
- HillRat 10y ago
  But if your server doesn't enforce data consistency -- that is, the business logic resides on the client -- you can't rely on the quality of your input. And if your authorization sanitizes the data to ensure consistency, then you've just built your middle tier for logic.
- toasterlovin 10y ago
  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.
  - jrcii 10y ago
    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.
    - toasterlovin 10y ago
      > 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.
  - dustingetz 10y ago
    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
    - toasterlovin 10y ago
      How do you decide who can write to and read from your data store?