One thing I never appreciated about client-server architecture is the nature of the asymmetry between the client and server: the client can not be trusted, whereas the server can be trusted.
I never appreciated this until recently, and it made me think of an API style that I think would elegantly solve many common repetitive/unfortunate workflows.
Basically, the backend can always tell the front end what to do, as a trusted entity. So the front end can not only render what the backend gives it, but also change state - routes, localStorage, ...
The key insight is that it's possible to build up a language for the backend to communicate with the front end, vs having a reactive paradigm to e.g. error handling. It's not just "error 64 happened", it's "Please redirect to standard error page with this message" - the front end exposes an API to the backend.
I never appreciated this until recently, and it made me think of an API style that I think would elegantly solve many common repetitive/unfortunate workflows.
Basically, the backend can always tell the front end what to do, as a trusted entity. So the front end can not only render what the backend gives it, but also change state - routes, localStorage, ...
The key insight is that it's possible to build up a language for the backend to communicate with the front end, vs having a reactive paradigm to e.g. error handling. It's not just "error 64 happened", it's "Please redirect to standard error page with this message" - the front end exposes an API to the backend.