I agree separate servers can be a pain, especially in a development environment. But I also believe separate servers can be a useful architecture in production, regardless of whether the web framework being used is thread-per-connection or event-driven.
Using separate servers can make it possible to upgrade/restart the backend process without necessarily disconnecting clients. It can allow managing/scaling the front tier separately from the back tier, which can make sense if you already do this for your request/response stuff (e.g. cache tier separately managed/scaled from web service tier). It's also a sane way to manage long-lived connections from a function backend like AWS Lambda, so the function doesn't have to run for the entire duration of a connection.
I created Pushpin (https://pushpin.org) to attempt to standardize this split-process architecture for all languages. It is a bit of a pain in a development environment, but a lot of fun in production. :)
Using separate servers can make it possible to upgrade/restart the backend process without necessarily disconnecting clients. It can allow managing/scaling the front tier separately from the back tier, which can make sense if you already do this for your request/response stuff (e.g. cache tier separately managed/scaled from web service tier). It's also a sane way to manage long-lived connections from a function backend like AWS Lambda, so the function doesn't have to run for the entire duration of a connection.
I created Pushpin (https://pushpin.org) to attempt to standardize this split-process architecture for all languages. It is a bit of a pain in a development environment, but a lot of fun in production. :)