• ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
    link
    fedilink
    arrow-up
    4
    arrow-down
    1
    ·
    6 months ago

    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.

    • areyouevenreal@lemm.ee
      link
      fedilink
      arrow-up
      1
      arrow-down
      3
      ·
      6 months ago

      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.

          • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
            link
            fedilink
            arrow-up
            1
            arrow-down
            2
            ·
            6 months ago

            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.

            • areyouevenreal@lemm.ee
              link
              fedilink
              arrow-up
              1
              arrow-down
              2
              ·
              6 months ago

              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.

              • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
                link
                fedilink
                arrow-up
                1
                arrow-down
                1
                ·
                edit-2
                6 months ago

                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.

                • areyouevenreal@lemm.ee
                  link
                  fedilink
                  arrow-up
                  1
                  arrow-down
                  2
                  ·
                  edit-2
                  6 months ago

                  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.

                  • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
                    link
                    fedilink
                    arrow-up
                    1
                    arrow-down
                    2
                    ·
                    6 months ago

                    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.