• toastal@lemmy.ml
    link
    fedilink
    arrow-up
    19
    ·
    6 months ago

    You can write a stateless server. You can’t do stateless front-end since you have to deal with user interaction.

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

      I would not be so sure. Maybe for a static web page this is possible. Outside of that I think people are kidding themselves. Writing code that might be stateless in isolation but relies on a database isn’t a stateless server imo, it’s just outsourcing state to another service.

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

        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.

        • uis@lemm.ee
          link
          fedilink
          arrow-up
          3
          ·
          6 months ago

          In many pages application url already bears part of state.

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

            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.

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

          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.

          • bitfucker@programming.dev
            link
            fedilink
            arrow-up
            4
            ·
            6 months ago

            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.

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

            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.

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

              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.

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

                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.