I've been intrigued by a couple ideas I've seen pop up, but I want to hear experiences with either approach as compared with our standard frontend framework + backend framework + REST/GraphQL/RPC architecture.
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.
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.