3 ms·
I think what they mean is that most people think that only the following is possible on 1 connection 1. Send Request 1 2. Wait for Response 1 3. Send Request 2
by allan_s 3y ago
I think what they mean is that most people think that only the following is possible on 1 connection
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)
- bmicraft 3y agoSounds like a worse way of writing async requests, while the last part is basically what websockets seem to be intended for
- allan_s 3y agoI 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.