Ask HN: Experiences with alternative front end-back end architectures
4 comments
> The first alternative architecture has been discussed a bit recently: a frontend which directly sends SQL queries to the backend, getting data back and rendering with a typical frontend framework.
The problem is that you can't trust the frontend - a malicious user can pretend to be the frontend but then send any SQL they want. This also makes it very difficult to do any server-side logic if all the server gets are data modification commands. The only scenario I can see this working is where you're dealing with read-only, public data, where the users are legitimately allowed to access all the data in the DB.
> The other alternative is to have the server do all the rendering, keep (most) working user state in a serverside structure, and hold open a websocket to stream effects from the client and updated components from the server.
I believe this is what Phoenix LiveView implements.
The problem is that you can't trust the frontend - a malicious user can pretend to be the frontend but then send any SQL they want. This also makes it very difficult to do any server-side logic if all the server gets are data modification commands. The only scenario I can see this working is where you're dealing with read-only, public data, where the users are legitimately allowed to access all the data in the DB.
> The other alternative is to have the server do all the rendering, keep (most) working user state in a serverside structure, and hold open a websocket to stream effects from the client and updated components from the server.
I believe this is what Phoenix LiveView implements.
My thoughts around that are to have all authorization and ownership encoded in database relations. I was thinking of a read-append-only table. This is a bit kooky maybe, but I experimented once with trying to make database constraints that verify a public key signature of the content of the record. One field containts signature of the user against the rest of the content of the record.
It was weird and ultimately at least Postgres couldn't support a cryptographic operation within a constraint, but it was fun to play with.
I make no claim any of this is practical right now, but I think there's at least theoeretical room to grow for that approach.
I'll look more into Phoenix! Thanks.
It was weird and ultimately at least Postgres couldn't support a cryptographic operation within a constraint, but it was fun to play with.
I make no claim any of this is practical right now, but I think there's at least theoeretical room to grow for that approach.
I'll look more into Phoenix! Thanks.
> One field containts signature of the user against the rest of the content of the record.
What if there are multiple users authorised for that content?
What if there are multiple users authorised for that content?
Hey, thanks for engaging and challenging my thought experiment. I think I could probably come up with a solution to that, but your point is made: this system will get arbitrarily complex very quickly. And require cryptography experts.
I definitely wouldn't do this for a Real Web App.
I definitely wouldn't do this for a Real Web App.
Also I'm aware some of us never stopped fully rendering serverside. That's cool. I think that makes a lot of sense in some places. But I have an okay understanding of the tradeoffs there already.
The first alternative architecture has been discussed a bit recently: a frontend which directly sends SQL queries to the backend, getting data back and rendering with a typical frontend framework.
The other alternative is to have the server do all the rendering, keep (most) working user state in a serverside structure, and hold open a websocket to stream effects from the client and updated components from the server. This is almost serverside rendering, but the server can focus on just rendering the parts of the page which have changed.
Does anyone have practical experience with these? Both sound cool, but I'm sure someone has a horror story or 2.