Sounds like a worse way of writing async requests, while the last part is basically what websockets seem to be intended for
I think you missed my point
> Sounds like a worse way of writing async requests,
It's just how it works under the hood, this complexity is quickly abstracted and actually it's how a lot of async requests are implemented, it's just here it's on 1 tcp connection.
> , while the last part is basically what websockets seem to be intended for
yes I was specifically answering that :
> I have seen teams of experienced seniors using websockets and then just sending requests/responses over them as every architecture choice and design pattern they were familiar with required this.
i.e people using websocket like normal http request.
1. Send Request 1 2. Wait for Response 1 3. Send Request 2 4. Wait for Request 2
while you can do
1. Send Request 1, move on 2. Send Request 2, move on
and have an other process/routine handling response
and potentially you even have Request that can be sent without needing a reponse "user is typing" in XMPP for example.
and even wilder for people using only http, that you can receive Response without a Request ! (i.e that you don't need to implement a GET /messages request, you can directly have your server sending messages)