1

It is possible to achieve two-way communication between a client and server using Server Sent Events (SSE) if the clients send messages using HTTP POST and receive messages asynchronously using SSE.

It has been mentioned here that SSE with AJAX would have higher round-trip latency and higher client->server bandwidth since an HTTP request includes headers and that websockets are better in this case, however isn't it advantageous for SSE that they can be used for consistent data compression, since websockets' permessage-deflate supports selective compression, meaning some messages might be compressed while others aren't compressed

Muizz Mahdy
  • 798
  • 2
  • 8
  • 24
  • 1
    Here are some other good links: [SO: WebSockets vs. Server-Sent events/EventSource](https://stackoverflow.com/questions/5195452/), [Polling vs SSE vs WebSocket— How to choose the right one](https://codeburst.io/polling-vs-sse-vs-websocket-how-to-choose-the-right-one-1859e4e13bd9), and [Do you really need WebSockets?](https://blog.stanko.io/do-you-really-need-websockets-343aed40aa9b). PS: To answer your questions: "Yes", and "Yes" ;) – paulsm4 May 13 '19 at 03:01
  • 1
    I'm not sure about the compression difference; but unless your "chat" messages are each megabytes in size, that is not going to be your bottleneck. – Darren Cook May 14 '19 at 07:19

2 Answers2

1

Your best bet in this scenario would be to use a WebSockets server because building a WS implementation from scratch is not only time-consuming but the fact that it has already been solved makes it useless. As you've tagged Socket.io, that's a good option to get started. It's an open source tool and easy to use and follow from the documentation.

However, since it is open-source, it doesn't provide some functionality that is critical when you want to stream data in a production level application. There are issues like scalability, interoperability (for endpoints operating on protocols other than WebSockets), fault tolerance, ensuring reliable message ordering, etc.

The real-time messaging infrastructure plus these critical production level features mentioned above are provided as a service called a 'Data Stream Network'. There are a couple of companies providing this, such as Ably, PubNub, etc.

I've extensively worked with Ably so comfortable to share an example in Node.js that uses Ably:

var Ably = require('ably');
var realtime = new Ably.Realtime('YOUR-API-KEY');
var channel = realtime.channels.get('data-stream-a');
  //subscribe on devices or database
  channel.subscribe(function(message) {
  console.log("Received: "  message.data);
});

//publish from Server A
channel.publish("example", "message data");

You can create a free account to get an API key with 3m free messages per month, should be enough for trying it out properly afaik.

There's also a concept of Reactor functions, which is essentially invoking serverless functions in realtime on AWS, Azure, Gcloud, etc. You can place a database on one side too and log data as it arrives. Pasting this image found on Ably's website for context:

enter image description here

Hope this helps!

Fabian Andrei
  • 50
  • 5
0

Yes, it's possible.

You can have more than 1 parallel HTTP connection open, so there's nothing stopping you.

Evert
  • 93,428
  • 18
  • 118
  • 189
  • What about the latency and packet size, is it advantageous to use SSE over websockets since they allow for consistent data compression? – Muizz Mahdy May 13 '19 at 03:10
  • 1
    It's too hard to give a general answer. Both have advantages. – Evert May 13 '19 at 03:13
  • 1
    If you're completely new to this and have no idea what bottlenecks you might run into, go for websockets and solve scalability problems when they happen. – Evert May 13 '19 at 03:15
  • 4
    I'm sorry to say, this answer is incomplete to the point of being misleading. There are per-client HTTP connection limits imposed by browsers, intermediaries and servers. I believe [Chrome will allow ~6 connections per domain name](https://bugs.chromium.org/p/chromium/issues/detail?id=275955). An SSE connection is still HTTP and it will take one of these connections (unlike WebSockets). [A client opening more than 4 tabs could experience DoS](https://stackoverflow.com/questions/18584525/server-sent-events-and-browser-limits). Even after 2 tabs, a client might experience degraded performance. – Myst May 13 '19 at 03:33
  • 1
    @Myst this is useful background, but not what OP asked. – Evert May 13 '19 at 05:11
  • 1
    Evert, @MuizzMahdy (OP) asked if using SSE isn’t more advantageous due to compression. IMHO, this information answers by providing an important counterpoint to the supposed (and questionable) advantage. – Myst May 13 '19 at 12:50
  • This answer is correct (answering the main question being asked); it is what I was also about to post. I would add that using SSE + HTTP POST it is likely to be more complicated and more inefficient, as you'll have more moving parts, and a new connection for each new post a client sends. – Darren Cook May 14 '19 at 07:16