Comment by mrcsharp | Hacker News Reader

Comment by mrcsharp | Hacker News Reader

Parent Full thread

> "In HTTP+SSE mode, to achieve full duplex, the client sets up an SSE session to (e.g.) GET /sse for reads. The first read provides a URL where writes can be posted. The client then proceeds to use the given endpoint for writes, e.g., a request to POST /a-endpoint?session-id=1234. The server returns a 202 Accepted with no body, and the response to the request should be read from the pre-existing open SSE connection on /sse."

This just seems needlessly complicated. Performing writes on one endpoint and reading the response on another just seems so wrong to me. An alternative could be that the "client" generates a session id and the start of the chat and make http calls to the server passing that ID in a query string or header. Then, the response is sent back normally instead of just sending 202.

What benefit is SSE providing here? Let the client decide when a session starts/ends by generating IDs and let the server maintain that session internally.

> What benefit is SSE providing here? Let the client decide when a session starts/ends by generating IDs and let the server maintain that session internally.

The response is generated asynchronously, instead of within the HTTP request/response cycle, and sent over SSE later. But emulating WS with HTTP requests+SSE seems very iffy, indeed.

Well with SSE the server and client are both holding a HTTP connection open for over a relatively long period of time. If the server is written with a language that supports async paradigms, then a http request that needs async IO will use about the same amount of resource anyways. And when the response if finished, that connection is closed and resources are freed. Whereas SSE will keep them for much longer.

Yes, and the client may do multiple requests, and if all take long to be processed you may end up with a lot of open connections at the same time (at least on http1), so there is a point to fast HTTP requests+SSE, instead of slow requests (and no SSE). Granted, if the server is HTTP2 the requests can share the same connection, but then it'd be similar to just using WS for this usage. Also, this allows to queue the work, and processed it either sequentially or concurrently.

By async I meant a process that may take longer than you are willing to do within the request/response cycle, not necessarily async IO.

You make a good point about queuing up the work. You do get more control over resource management in this case.

What benefit are WebSockets providing? It's the same. You send something to one endpoint and need to listen for a response in another handler.

Reply on news.ycombinator.com