(disclaimer: I don't know how this looks) if you follow the old-school web app model, you're working on the basis of stateless requests. This means that if you want to make a multi-page form, you have to build up coordination mechanisms between pages.
In something like an SPA, you end up having frontend state, but you're lacking the corresponding backend state. There are a lot of times where I've wanted to do something in the backend like:
first_response = await render('first_form.html')
if is_valid(first_response):
final_confirmation = await render('second_form.html')
(This is obviously more conceptual than actual code, since actual code would require suspending python VMs for some unknown future)
In a framework that is more amenable to the fact that frontend clients have state, you should be able to write out multi-request flows more easily. Perhaps with some base notion of a request trace (with the understanding that the frontend also need to send extra info to identify itself).
Websockets are something interesting, but it doesn't quite enable this. And it won't be easy to get right. Failure cases in particular will require some coordination.
The backend request handling layer pretty much has to be stateless if you want to horizontally scale it anyway. Granted, it’s really helpful to have good abstractions for managing session state, but multi-request flows are just a sequence of requests that you have to handle statelessly anyway, even if that involves maintaining, fetching, and sometimes caching session state and other data more explicitly. I see value in having mechanisms for doing that easily (e.g. my request handler function taking a “state” argument that’s automatically populated from a session state store based on a request trace, JWT, cookie, or other mechanism), but I don’t see how those mechanisms would require tightly coupling your frontend and backend aside from enforcing the session protocol.
beyond the session protocol, you have to think about the bundle of state you need to carry between requests in a _clean_ way (preferably something that goes beyond "stuff it in the session dict", because that's basically global variables). You also most likely want ways to do things like fetch non-stale versions of objects from the DB, help with certain data assertions, etc.
You don't need to have a stateless backend for horizontal scale, you can have relatively smart routing, or relying on stuff like the database to help you with the coordination. Especially if you do things like say "this session is held to for up to an hour" you could even consider suspending VMs! If you have the resources to do so, that is.
I think that "coupling frontend and backend" is not really what is being requested here, but more about providing functionality that lets you build rich backends based on the fact that our frontends are way richer than they used to be
In something like an SPA, you end up having frontend state, but you're lacking the corresponding backend state. There are a lot of times where I've wanted to do something in the backend like:
(This is obviously more conceptual than actual code, since actual code would require suspending python VMs for some unknown future)In a framework that is more amenable to the fact that frontend clients have state, you should be able to write out multi-request flows more easily. Perhaps with some base notion of a request trace (with the understanding that the frontend also need to send extra info to identify itself).
Websockets are something interesting, but it doesn't quite enable this. And it won't be easy to get right. Failure cases in particular will require some coordination.