hntrl
Joined 3 years ago
Karma
173
Submissions
10
Member since
Jun 12
Recent submissions
Comment · 1 year ago
The helper example was a sore attempt to plug the project I've been working on (tinkering with it is how I came up with the example). The library I plugged has much more to do with enabling a more flexible reactive programming model in js, but just so happens to plug into the stream API pretty handily. Still an interesting look IMO if you're into that kind of stuff
Comment · 1 year ago
It even has mention as being the spiritual successor to WebSocket for certain cases in mdn docs:
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...
Comment · 1 year ago
who's to say your data is coming from multiple streams? You can propagate any updates you need to make in the application to a single stream (like SSE or a long-lived response) in place of a WebSocket. your http responses can just be always 204 if all they're doing is handling updates and pushing events to aforementioned single stream.
https://en.wikipedia.org/wiki/Command%E2%80%93query_separati...
Comment · 1 year ago
It's a good thing I didn't then :shrug:
Websockets are a web standard, socket.io is a userland framework
Comment · 1 year ago
> sending a RequestID to the server so that you get request/response cycles isn't weird nor beyond the pale.
To me the sticking point is what if the "response" message never comes? There's nothing in the websocket protocol that dictates that messages need to be acknowledged. With request/response the client knows how to handle that case natively
> And the websocket browser API is nicer to work with than, say, EventSource.
What in particular would you say?
Comment · 1 year ago
I have a demo of this for CF workers https://github.com/hntrl/eventkit/tree/main/examples/workers...
(it's not SSE in particular, but it demonstrates that you can have a long running stream like SSE)
Comment · 1 year ago
I've noticed some weird behaviors with the EventSource impl that browsers ship with. Chief among them being the default behavior is to infinitely reconnect after the server closes the stream, so you have to coordinate some kind of special stop event to stop the client from reconnecting. You wouldn't have that problem with the stream object from Response.body
The SSE protocol is actually just a long-running stream like I mentioned but with specific formatting for each chunk (id, event, and data fields)
as a side note, eventkit actually exports utilities to support SSE both on client and server. The reason you'd want to use eventkit in either case is because it ships with some extra transformation and observability goodies. https://hntrl.github.io/eventkit/guide/examples/http-streami...