[anderspitman]

What's wrong with normal HTTP requests for client->server streams? You get the added bonus of being able to dump them to a curl command for debugging.

[viklove]

More overhead, and it doesn't scale. My nodejs websockets server can handle thousands of connections without a problem, but my rails api server allocates a thread per connection so I'm limited to <16 unless I start horizontal scaling.

For infrequent requests everything goes through the api, but for stuff like chat and live-document-editing, nodejs is the better solution.

[anderspitman]

I think I missed something. Why can't you use node for SSE?

[viklove]

I can, but why would I limit myself to one-way communication when I can have bidirectional communication?

[anderspitman]

You didn't cite bidi as your reason for choosing WS in your last comment, you cited scaling and node vs ruby.

But to answer this new question:

* You can have bidi without WS.

* Because WS is more complicated.

[viklove]

> You didn't cite bidi as your reason for choosing WS in your last comment, you cited scaling and node vs ruby.

Because I was answering this question: "What's wrong with normal HTTP requests for client->server streams?"

> You can have bidi without WS.

Only by combining HTTP (which doesn't scale because my api server runs rails) and SSE (which does scale). If I want scaling bidirectional communication, I need websockets.

> Because WS is more complicated.

More complicated than SSE? I don't think so.