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:
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
Security firewalls may prevent WS for operating properly
express-ws makes sockets easy on the API end
I believe you can have more than 6 concurrent connections by one user (which may be pro and con)
Server Sent Events
Seems like the technology is fading in favor of WS
Listening to the events seem to be as easy as listening to events for WS
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
Little more backend code to setup http2 and emit the SSEs(Ugly code as well - so functions will be made)
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?
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.
I personally avoid using websockets as a 2-way communication between client and server.
I try to use sockets to broadcast data from server to users or a single user(socket), so they can get real-time updates, but for the post requests from client to server I tend to use axios or something similar, because I don't want to pass sensitive data (like access keys etc) from client to server.
My data flow goes something like
User posts data to the server using axios, SSE or whatever
Backend server does what it has to and notifies socket that an event has occured
Socket server then notifies who he has to
My problem with using sockets to send data from client to server is the authentication issue. Technically, you can't pass anything that is not available to client-side javascript through a socket, meaning that to authenticate the action you will have to send sensitive information through a websocket. This is an issue for multiple reasons - if your sensitive data can be accessed using client-side js, there is a bunch of attacks that can be done here. Also someone can listen to the communication between ws and client. This is why I use API calls (axios etc) and store sensitive data to http-only cookies.
So once server wants to notify the user that something has happened, you can easily do that by telling the websocket server to send the data to the user.
You also want to keep your API server stateless, meaning no sockets in your API. I use separate server just for websocket connections, and my API server and websocket server communicate using redis. Pub/sub is a really neat feature for internal server communication and state management.
And to answer your question regarding multiple connections - you can use a single connection between your websocket server and client, and broadcast data using channels. So one channel would be for notification feed, other channel could be for story feed etc.
I hope this makes sense to you. This stack has worked really good for me.
Related
Simple question, are there any other options how to fetch data from server to client to achieve realtime refresh (For example realtime table) other than:
Call API request inside some loop
Subscribe to realtime websocket server
I mean it as core options. Sure there are many libraries or patterns but seems they using one of those two methods.
For Web Applications (browser clients):
There's SSE (Server Sent Events, a.k.a., EventSource), WebSockets and polling (short / long).
Other then that, you'll be working with non-standard solutions (i.e., flash sockets, etc').
IMHO, WebSockets are the best for realtime updates and there are plenty of tools to make the development easy enough.
I have just began using socket.io and I have some experience with express. I know socket.io has bidirectional communication while express is only client to server.
This made me think, why don't we just use socket.io with different namespaces and not use express at all?
In which cases should I use socket vs express?
In the case I need bidirectional communication, is it advisable to make the client -> server with express and then use socket for server -> client?
First off express and socket.io are pretty different things. Express is a full-blown web server framework. You use it for setting up a web-site, fielding http requests from a browser, fielding http requests for an API, etc...
socket.io is a communication layer that sits on top of the webSocket protocol and the webSocket protocol uses an http server to establish its initial connection. While there is a little bit of overlap between what you can do with socket.io and Express, they are more different than they overlap.
For example, if you're setting up a web-site, you couldn't do that with socket.io, one would use something like Express.
Now, if you have a specific programmatic need to communicate between an arbitrary client and a server, you have a zillion choices. If the client is in a browser and the programmatic interface is from Javascript in the browser, then you have fewer choices.
From the browser, using http ajax requests via Express is one choice. Setting up a socket.io connection and defining you own messages is another choice.
Reasons to pick socket.io over Ajax calls to Express from browser Javascript:
You need/want two-way communication over the same channel.
The client is sending a lot of requests to the server (the overhead for sending a socket.io message is lower than an ajax call, once the socket is already set up, so if you're sending a lot of messages, then socket.io messages are more efficient than http requests)
Reasons to pick Ajax calls to Express:
HTTP connections are stateless and short-lived which can make implementing high scale, multi-server implementations with failover and redundancy easier.
There are a wealth of tools to use for http connections from authentication libraries to data formats (MIME) to audio to video, etc...
You want your client to run in places where a long-connected socket.io during inactive periods of time may not be practical (perhaps mobile or battery operated devices).
You want to run in situations where there are proxies, firewalls or other network infrastructure that may not support long running webSocket connections or specifically disallow them.
You want a request/response model. HTTP is request/response where you get a specific response for each request and you know exactly which response goes with which request.
So, as you can see, there is no generic answer to this question. It really depends upon the specific of your communication, the interoperability you desire and the exact needs of your code.
Here are some other references on this topic:
Ajax vs Socket.io
Websocket vs REST when sending data to server
Using AJAX vs. socket.io socket messages
websocket vs rest API for real time data?
Problem description
i am working on a Xamarin application that consumes a REST API written in Python flask.
The Xamarin application offers virtual shopping lists where user can collaborate on buying stuff they have on a shared list.
To improve the user experience, i want to be able to actively notify the user about finished items on the list.
Possible solutions:
Synchronous API polling from client side
Notifications are stored by the API in a relational database and have a flag indicating if the user received the notification already.
The API has an endpoint GET /users/:user_id/notifications/ that queries the database for notifications and returns a JSON response with those.
Advantages
fairly simple to implement
Problems
synchronous polling creates a huge amount of http requests
API service remains stateless, making a horizontal scaling with a loadbalancer easier
Websocket endpoint on the API
The API has an endpoint POST /users/:user_id/notifications/register which creates a websocket connection between client and API.
The connection is stored to a global array in which each entry maps a client id to a websocket connection.
When a new notification is created, the endpoint makes a lookup in the connection dictionary by comparing the owner id of the notification with the dictionary entries. The notification is sent to appropriate user through the websocket.
Notifications are stored in the database like in the first approach.
When a user calls the endpoint, a new websocket connection will be established first and upon success the API sends all unseen notifications from the database to the user.
Advantages
API can push notifications to clients asynchronously
Problems
When a user terminates the websocket connection his dictionary entry will persis
Retaining one websocket connection per user permanently adds additional overhead to the API
Horizontal scalability of the API is more difficult because the service is not stateless anymore (Websocket connection information saved in
RabbitMQ
The API uses a RabbitMQ service to send notifications to the client. Every client uses subscribes to his own notification queue to prevent the broadcasting of messages.
Advantages
API remains stateless
Problems
Notifications needs to be resend to the exchange when a user is offline
Amount of queues grows drastically
Additional costs for RabbitMQ service
High temporary load on the RabbitMQ service when many users come online in the same time
Final words
It would be interesting to hear the opinion of others.
I believe the active distribution of notifications from backen services to clients i a very common use case.
best,
D
I would use RabbitMQ and consume events forwarding them as push notifications. This will work while the user is not actively connected to the website and enhance the engagement with each user experience that will return to the website when notified for more information see How to setup basic web push notification functionality using a Flask backend or How to send push notifications to a browser in ASP.NET Core or Sending Notifications with Spring Boot, Angular, and Firebase Cloud Messaging this way the RabbitMQ will not wait until the user is back online. If the user is online you can forward the notification directly to the Xamarin application via WebSockets and a load balancer like NGINX that can handle many WebSockets in an optimized way.
Synchronous API polling from the client-side is the less preferred way since it overloads the webserver with requests while nothing was changed.
I don't think the scalability of WebSocket is a problem. You can scale up easily with pub/sub. The hotspot of long connections is a kind of serious problem.
For one-way communication, I would suggest Server sent event. In the end, it usually depends on what your team is confident with.
I can recommend on a different approach for API that provides JSON which is called GraphQL
It supports subscriptions capabilities that are pushed by the GraphQL API Server (using web sockets)
GraphQL is considered today to be better than RESTful API since its very flexible and you can get exactly the data you need with one query.
I need to build a server and a client that can exchange data in real time with a company's proxy between them. No one has the authorisation to amend the proxy's configuration (in order to allow the WebSocket protocol).
I would need a fallback technology such as long-polling.
Example: client is a user's PC employee. He needs to exchange data with the server, located in the cloud and separated by company's proxy.
Ideally, I would use WebSocket with SSL, but I know some proxies are not configured for WebSocket messages and thus could reject the connection.
The app would therefore switch to another push technology such as long-polling, increasing the chances of getting a successful connection (is 100% guaranteed with proxies? Giving that there are several types of proxies...)
Are there any libraries/frameworks proposing such features?
Usually, secure WebSocket connections do fine through proxies.
In .NET you have SignalR
In node.js you have socket.io
I have a question with regards to the comet implementation. I know that it is used to handle asynchronous requests similar to what now can be achieved through Servlet 3.0 async functionality. Yet what i do not understand is how the push is done to the calling client.
In web sockets we open the connection by providing the ip and port. With comet, how do you connect with the server in order to receive call backs when the server pushes data?
The Wikipedia page on Comet (programming) is a pretty good resource for this question (sorry it's so obvious).
Comet is an umbrella term for using HTTP to simulate a bi-directional connection between a client and server. Ultimately you make an HTTP request to the server and attempt to hold it open (long polling and streaming). With long-polling that connection closes after a given interval or when data is returned. With streaming the connection is help open as long as possible and new data is sent over the existing connection.
How these are achieved differ between web browsers - that why Comet is classed as a hack. Again, the wikipedia page should provide almost all the information you need.
I wrote an article covering the history of realtime web communication (with a focus on client) and why WebSockets are a game-changer.