Search code examples
expresswebsocketserver-sent-eventsws

Server Sent Events and Ajax VS Websockets and Ajax

I am creating an application(Nuxtjs) and am having troubles determining a good approach for sending data to the API(expressjs) and retrieving real-time updates. It seems that i can create "bi-di" connections with both protocals [Server Sent Events(SSE) and Axios or Websocket(WS)].

Both technologies work with most of the browsers, so i do not see a need to add additional libraries such as socket.io - For those individuals that do not have a current browser (too bad).

The application is based on user input of form data/clicks. Other users are then notified/updated with the information. At which point, the user can respond and the chain goes on(Basic chat like flow some information will be exchanged quickly while some may not or ever).

In my experience, the user flow would rely more heavily on listening for changes than actually changing the data - hence why i'm considering SSE. Unfortunately, both protocols have their flaws.

Websockets:

  1. Not all components will require a WS to get/post information as such it doesn't make sense to upgrade a basic http connection at the additional server expense. Therefore another method other than WS will be required(Axios/SSR). Example: Checking to see if a user name exists
  2. Security firewalls may prevent WS for operating properly
  3. express-ws makes sockets easy on the API end
  4. I believe you can have more than 6 concurrent connections by one user (which may be pro and con)

Server Sent Events

  1. Seems like the technology is fading in favor of WS
  2. Listening to the events seem to be as easy as listening to events for WS
  3. No need to upgrade the connection but will have to use node-spdy within the expressjs API - This may also be a good implementation for WS due to multiplexing
  4. Little more backend code to setup http2 and emit the SSEs(Ugly code as well - so functions will be made)
  5. Limited to HTTP limitations (6 concurrent connections) which is a problem as the users could easily max this out(ie. having multiple chat windows open)

TLDR

The application will be more "feed" orientated with occasional posting(which can be handled by Axios). However, users will be listening to multiple "feeds" and the HTTP limitations will be a problem. I do not know what the solution would be because SSE seem like the better option as i do not need to continually handshake. If this handshake is truly inconsequential(which from everything i have read isn't the case) than WS is likely a better alternative. Unfortunately, there is soooo much conflicting information regarding the two.

Thoughts?

Solution

  • SSE, Web Sockets, and normal HTTP requests (via AJAX or Fetch API) are all different tools for different jobs.

    SSE

    • Unidirectional, from server to client.
    • Text-based data only. (Anything else must be serialized, i.e. JSON.)
    • Simple API, widely compatible, auto-reconnects, has built-in provision for catching up on possibly missed events.

    Web Sockets

    • Bi-directional.
    • Text or binary data.
    • Requires you to implement your own meaning for the data sent.

    Standard HTTP Requests

    • Client to Server or Server to Client, but only one direction at a time.
    • Text or binary data.
    • Requires extra effort to stream server-to-client response in realtime.
    • Streaming from client-to-server requires that the entire data be known at the time of the request. (You can't do an event stream, for example.)

    How to decide:

    • Are you streaming event-like data from the server to the client? Use SSE. It's purpose-built for this and is a dead simple way to go.
    • Are you sending data in only one direction, and you don't need to spontaneously notify clients of something? Use a normal HTTP request.
    • Do you need to send bidirectional data with a long-term established connection? Use Web Sockets.

    From your description, it sounds like either SSE or Web Sockets would be appropriate for your use case. I'd probably lean towards SSE, while sending the random API calls from the client with normal HTTP requests.

    I do not know what the solution would be because SSE seem like the better option as i do not need to continually handshake. If this handshake is truly inconsequential(which from everything i have read isn't the case) than WS is likely a better alternative.

    Keep in mind that you can simply configure your server with HTTP keep-alive, making this point moot.