3 ms·

What is the best approach to handling a continuous stream of data? Is it just 'buffer till you have what you need and pass it off to be processed' approach? And

What is the best approach to handling a continuous stream of data? Is it just 'buffer till you have what you need and pass it off to be processed' approach? And then keep reading until end of stream/forever.

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 ago
  Sounds like a worse way of writing async requests, while the last part is basically what websockets seem to be intended for
  - allan_s 3y ago
    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.
dgb23 3y ago
In the case of websockets that is already handled for you. I think GP talks about how to think about communication (client server). Stateless request response cycles are much simpler to reason about because it synchronizes messages by default. The state is reflected via this back and forth communication. Even when you do it via JS: the request data is literally in the scope of the response callback. If you have bi-directional, asynchronous communication, then reading and writing messages is separate. You have to maintain state and go out of your way to connect incoming and outgoing messages semantically. That's not necessarily what you should be doing though.
whizzter 3y ago
Pretty much, websocket implementations usually handles the buffering part so you really only need to handle "full" events. Easiest example is probably games, events could be things such players moving to new locations, firing a weapon, explosions. In realtime games, as well as "request-response" scenarios, it's common to have some kind of response that acknowledges that data was received.

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 ago
Sounds like a worse way of writing async requests, while the last part is basically what websockets seem to be intended for
- allan_s 3y ago
  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.

dgb23 3y ago

In the case of websockets that is already handled for you. I think GP talks about how to think about communication (client server). Stateless request response cycles are much simpler to reason about because it synchronizes messages by default. The state is reflected via this back and forth communication. Even when you do it via JS: the request data is literally in the scope of the response callback. If you have bi-directional, asynchronous communication, then reading and writing messages is separate. You have to maintain state and go out of your way to connect incoming and outgoing messages semantically. That's not necessarily what you should be doing though.

whizzter 3y ago

Pretty much, websocket implementations usually handles the buffering part so you really only need to handle "full" events. Easiest example is probably games, events could be things such players moving to new locations, firing a weapon, explosions. In realtime games, as well as "request-response" scenarios, it's common to have some kind of response that acknowledges that data was received.