Web Streams at the Edge | Hacker News Reader

Web Streams at the Edge

deno.com

99 points0xedb11 comments

Nice to have a new offering for edge compute/streams! It would be useful to see how this compares with the different edge compute alternatives (particularly Cloudflare Workers/Durable Objects) in terms of TCP Connection Time, Time To First Byte, Time To Last Byte, etc.

The SSE example hangs indefinitely on mobile Safari, rendering fully all events that were sent only after canceling load. According to caniuse this shouldn’t be a compatibility issue, so something else might be wrong.

I’m not sure what to expect from the websocket example, but I just see “request isn't trying to upgrade to websocket.”

For the SSE example, Safari only streams HTML, not plain text AFAIK. It should work if you use the endpoint with the `EventStream` constructor.

As for the WS example: it is a WebSocket endpoint, so you must connect to it using `new WebSocket` :-)

Thanks, this makes sense. Weird examples to link to, but at least I understand the behavior now.

I was naturally wondering what some use cases of this would be. Anyone have ideas?

You could:

- Stream-process JSONL.

- Replace strings for translations while streaming.

- Stream Video.

I guess you don't mean WebSockets, since that has a myriad of use-cases, everything from chats, games, charts, feeds etc.

You could run trusted game server proxies. In FPS games this would help with the latency vs cheating trade-off.

1. An enemy is hiding behind a corner. The player takes a step and sees the enemy.

If the client knew the enemy was there, the player could cheat. If the client didn't know, the player would see the enemy with a delay. The proxy can share the hidden state at exactly the right moment.

2. When the player thinks that their shot hit the target, but the central server disagrees.

If the client is trusted to determine the answer, the player could cheat again. If the client isn't trusted, the player would sometimes see a hit that didn't harm the target. The proxy can make the decision and provide accurate feedback immediately.

This seems like its http and web sockets, so probably not useful for game networking until HTTP/3 and WebTransport happens so that UDP becomes possible.

If a game doesn't want TCP at all for whatever performance metrics they think they need to hit in their networking stack, HTTP/3 is not likely to meet their needs/standards/expectations either even over UDP because HTTP/3 just moves some of TCP's stack into the application protocol over top of UDP and in some ways remains "just" a TCP-over-UDP tunnel.

Could you elaborate? I'm not sure I understand. The main issue that UDP solves in game networking is being able to send/receive out-of-order messages, which will be possible with WebTransport datagrams.

Streaming in particular can provide a huge performance boost for server-side rendered pages. In theory, server-sent events can also provide performance benefits (both in page weight and runtime) by moving more dynamic behavior from the client to the server.

Reply on news.ycombinator.com