Doesn’t SPA require polling the web server for more information? I feel like any website which retains information outside of the client device (like anything with a login page) would require state to be stored somewhere on the backend.
What kind of polling are we talking about? If you are talking about realtime data, SSE doesn’t solve that either. You need SSE or WebSocket for that (maybe even WebRTC). If what you mean is that every time the page is refreshed then the data is reloaded, it is no different than polling.
Typically, you just have a session cookie, and that doesn’t even need to be part of the app as auth can be handled by a separate proxy. The server just provides dumb data pull operations to the client in this setup, with all the session state living clientside.
That data has to be stored somewhere though. So you would still need some kind of database server to store it all or some other solution. That’s what I mean by outsourcing state. Data is still stored in the backend, just in a database rather than a web server.
There is data that gets persisted and needs to be stored somewhere, and then there’s the UI state that’s ephemeral. The amount of data that gets persisted tends to be small, and the logic around it is often trivial.
How am I being obtuse? You have been trying to trivialise the backend and now frontend as well. Backend isn’t just writing PHP or whatever, it’s setting up database servers, authentication proxies, and all that stuff. Not everything can be stateless.
I’m not trivializing anything here. What I actually said was that when all the UI logic lives on the frontend, then the backend just has dumb fetch and store operations along with an auth layer. In this scenario, the backend code can indeed be largely stateless. Specifically, it doesn’t care about the state of the user session or the UI. The only one trivializing things here is you by completely ignoring the nuance of what’s being explained to you.
The only nuances here seem to be: a) very simple websites need little state (but still aren’t stateless) and b) that you can move the state around to make something look stateless within a narrow view.
Doesn’t SPA require polling the web server for more information? I feel like any website which retains information outside of the client device (like anything with a login page) would require state to be stored somewhere on the backend.
What kind of polling are we talking about? If you are talking about realtime data, SSE doesn’t solve that either. You need SSE or WebSocket for that (maybe even WebRTC). If what you mean is that every time the page is refreshed then the data is reloaded, it is no different than polling.
Typically, you just have a session cookie, and that doesn’t even need to be part of the app as auth can be handled by a separate proxy. The server just provides dumb data pull operations to the client in this setup, with all the session state living clientside.
That data has to be stored somewhere though. So you would still need some kind of database server to store it all or some other solution. That’s what I mean by outsourcing state. Data is still stored in the backend, just in a database rather than a web server.
There is data that gets persisted and needs to be stored somewhere, and then there’s the UI state that’s ephemeral. The amount of data that gets persisted tends to be small, and the logic around it is often trivial.
So I was right then. Colour me surprised.
I mean if you’re going to be aggressively obtuse about this, I guess there’s no point talking.
How am I being obtuse? You have been trying to trivialise the backend and now frontend as well. Backend isn’t just writing PHP or whatever, it’s setting up database servers, authentication proxies, and all that stuff. Not everything can be stateless.
I’m not trivializing anything here. What I actually said was that when all the UI logic lives on the frontend, then the backend just has dumb fetch and store operations along with an auth layer. In this scenario, the backend code can indeed be largely stateless. Specifically, it doesn’t care about the state of the user session or the UI. The only one trivializing things here is you by completely ignoring the nuance of what’s being explained to you.
The only nuances here seem to be: a) very simple websites need little state (but still aren’t stateless) and b) that you can move the state around to make something look stateless within a narrow view.