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.
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.
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.