430
Asking the important questions
(lemmy.ml)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 26 Apr 2024
430 points (100.0% liked)
Programmer Humor
32767 readers
279 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
With the SPA approach, you can have remarkably little state on the server because all the state associated with the user session lives on the frontend. The value of doing this obviously depends on the type application you're making, but it can be a sensible approach in some cases.
In many pages application url already bears part of state.
Sure, but that only gets you so far. I think it's important to distinguish between document sites where the users mostly just views content, and actual applications like an email client or a calendar. The former can be easily handled with little to no frontend code, however the latter tend to need non trivial amount of UI state management.
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.
not what I said at all, but you do you
Sure
Evidently you don't understand what people mean when they talk about stateless backend, so let me explain. The point there is regarding horizontal scaling. If your backend code is stateful then it has user context in memory, and requests for a particular user session have to be handled by the same instance of the service. With a stateless backend all the context lives on the client, and the requests can be handled by any instance on the backend. So now you can spin up as many instances of the service as you need, and you don't need to care which one picks up the request. The fact that you might be persisting some data to the db in the process of handling the request is neither here nor there. Hope that helps you.
Yes that's a stateless service but not a stateless backend. A backend to me is everything that doesn't run on the client, including the database. Databases are not stateless, even distributed databases are not stateless. You can't just spin up more databases without thinking about replication and consistency.
I've explained to you why the term exists, and why it matters. It refers specifically to application code in the context of horizontal scaling. Meanwhile, many popular databases do in fact allow you to do sharding in automated fashion. If you're not aware of this, maybe time to learn a bit about databases.
You still have to consider ACID vs BASE when choosing a database software/provider. It comes from CAP theorem.
If that's how people want to talk about it they can, but you can't eliminate statefulness from the whole stack.
Again. the goal is not to eliminate the statefullness of the whole stack. That's just the straw man you keep arguing against. The goal is to remove context from the server. Once you get a bit more experience under your belt, you'll understand why that's useful.
The whole conversation was about backend being similar because you can write a stateless server. Have you forgotten? The issue here is a backend isn't just one service, you can write a stateless service but you are in fact just moving the statefulness to the database server. The whole backend isn't simpler than the front-end for that reason. It might be simpler for other reasons, though many popular websites need complex backends.
I am not arguing that a stateless service isn't a useful concept. I get why people might want that. That's not what this conversation is about. It's about the backend vs frontend. Backend to me includes databases and other support services.
No, I have not forgotten. This whole conversation was me explaining to you the advantages of keeping the session context on the client. You are not moving statefulness to the database. The fact that you keep repeating this clearly demonstrates that you don't understand what you're talking about.
The statefulness lives on the client. Everything I said about the backend application also applies to the database itself. Any node in the db can pick up the work and store the value. The issue being solved is having everything tied to the state in a particular user session.
To explain it to you in a different way. There will be a certain amount of data that will need to be persisted regardless of the architecture. However, moving user state to the client means that the backend doesn't have to worry about this. The fact that you're having trouble grasping this really is incredible.
I don't write web applications for a living and I especially don't write front ends. I do have to ask though:
What information are you actually keeping in the front end or web server? Surely you don't need any ephemeral state that isn't already stored in the browser and/or for you like the URL or form details. Only thing I can think of is the session ID, and that's normally a server side thing.
I mean I've written web sites where there is no JavaScript at all, and the server is stateless or close to it. It's not a difficult thing to do even. All the actual information is in the database, the web server fetches it, embedds it into a HTML template, and sends it to the client. Client doesn't store anything and neither does the server. Unless I really don't understand what you mean by state. You might keep some of your server fetches data from another server using REST or SOAP but that's only used once as well.
Well, I've been writing web apps for a living for the past 20 years or so, and I've written lots of full stack apps. There can be plenty of ephemeral state in a non-trivial UI. For example, I worked on a discharge summary app for a hospital at one time. The app had to aggregate data, such as patient demographics, medications, allergies, and so on from a bunch of different services. This data would need to be pulled gradually based on what the user was doing. All of the data that got pulled and entered by the user would represent the session state for the workflow. Maybe don't trivialize something you admit having no experience with.
So you do include ephemeral state that's a copy of database data? If we were including that then every non-static website has plenty of state, but so does every web server. Whatever definition you are using must be quite odd.
I don't know why you have so much difficulty wrapping your head around the concept of UI state to be honest.