How can a GUI display unsolicited output?

Question

"Solicited output" means a user issues a command to a GUI and the GUI displays the corresponding output.

In this context, I include Web apps in the term "GUI".

However, often a GUI needs to display unsolicited output.

For example, the SE/SO websites often display an icon indicating the number of new email messages and the new score for a user's reputation. This wasn't solicited by the user.

I was trying to figure out how this is done:

1) Obviously, a DB maintains the relevant data about each user.

2) In this DB, the data rows pertaining to a specific user are updated by the App, in response to other users' actions (as well as the user's own actions).

3) Then, the output - completely unsolicited by the user in question - goes to the screen of the user in question.

But which concepts / technologies are involved in making step 3 above happen?

For instance, does an Event fire? If this is so, then what possible event could be raised in the frontend, due to a DB action?

Alternatively, does the frontend poll the DB at frequent intervals? This would be inefficient.

Answer 1

In the case of StackExchange, the technology which allows the server to push notifications to the client is WebSocket. You can check it yourself: open the developers tools and refresh the page; you'll see a call to wss://qa.sockets.stackexchange.com/ and you can even look at the frames, i.e. the messages which were sent by the server to the user or the other way around.

There are other technologies for server to client communication as well. One of them is Server-sent events, which should be your default choice over WebSocket (see below).

While SSE and WebSockets are relatively new, other techniques existed before 2011 as well, specifically polling (i.e. the client sends an AJAX request on regular basis, such as once per second, to retrieve the events) and long-polling, which is an optimized version of polling where the number of AJAX requests is drastically reduced.

More esoteric techniques exist as well (especially if you're not limited only to JavaScript), but the four ones I presented above should be sufficient in most cases. If you need to chose:

• SSE should be your default choice. Easy to set up compared to WebSockets, it ensures that the events are delivered very fast compared to polling, and is straightforward to implement compared to long-polling. Its major drawback compared to WebSocket is that disconnections are not handled for you.

• WebSocket is a nice alternative when you need the power of non-HTTP, duplex communication. With the power comes the problems related to infrastructure; unless you know your network infrastructure supports WebSocket, you may have nasty surprises when deploying for the first time in production.

• Polling is a good alternative where you don't need the events to appear on client side nearly immediately. For instance, if a delay of ten seconds is reasonable, polling can be the most efficient solution, with a major benefit of not keeping a permanent connection to the server. While it doesn't look fashionable any longer, polling is still a perfectly valid choice for specific applications.

• Long-polling keeps a nearly-permanent connection to your server, which means that you may chose long-polling over SSE only when SSE is not supported by your infrastructure. If this is the case, it's time to invest in better infrastructure anyway.

However, often, all this is irrelevant.

What you'll do in practice is to use an existent library, such as socket.io, which abstracts the internals for you. They do a great job of choosing the right medium to transmit the events, which also means that they would automatically fallback to older techniques such as polling for very outdated browsers.