Everyone reading this should understand the concepts of a notification area on a website, we've all been using website's long enough! A notification is a message you can display to the user, usually as an icon in a notification area, usually in the header of your website. Recently, a client wanted to add a notification area to the header of their website. Obviously, there are several ways of doing this and in today's post, I'm going to cover the three main contenders.
In this scenario, we have a header where all the standard stuff, like logo, navigation, search bar etc.. are processed and rendered server side. As this data won't change very often it means we can add a long expiry data on it to help make the website more performant. The user profile and notification area in the header will then be populated via AJAX. In this vein the size of the data packets required for each page request is kept to the minimum it can be.
This post is the first of a two-parter, in this first post, I'm going to evaluate the different ways of architecting the solution. In the second post, I'll walk you through my solution by talking you through a sample project that provides the basic outline.
Option One: Wait for the user to refresh the page. In this scenario we do nothing. If a new notification needs to be displayed on the page, we wait until the user refreshes the page and get a new AJAX payload. This option is definitely the easiest as it doesn't involve any additional code. If the user is using your website a lot, then the chances of them getting the new notification quickly are pretty high. If your website visitors don't refresh your pages often, then they might not get your notification for several hours.
Options Three: Observer/Subscriber Pattern: Using an observer pattern, you get all clients to register with your server. When a new notification comes in you send a broadcast signal to all of your clients telling them that your data source has been updated. This approach is pretty efficient because you don't have the downsides of long polling and the wasted resourcing. Clients only run code when a broadcast has been made, instead of polling every 10 seconds. It also means the user doesn't have to wait to refresh the page.
The main problem when you start to think about observer/subscriber patterns is how will you deal with the messaging of data. One of the more popular ways of dealing with this real-time messaging (at the time of writing) seems to be web sockets. Web Sockets do have some very big limitations so I wouldn't just jump right out and start using them straightaway without considering a few things first. Web socket doesn't seem to play that nicely within load balanced environments, or HTTP2, which are two main features most enterprise level organizations will want to use.
This article, https://samsaffron.com/archive/2015/12/29/websockets-caution-required, gives a good explanation about the reasons not to use web sockets. The outcome of which is to use a framework, like SignalR, to future proof it. SignalR does use web sockets but also has the intelligence to gracefully degrade to a different messaging method, like polling, if there are problems.
I would definitely recommend using a framework, as not only does it give you more confidence as the code is battle worn, it also allows you to abstract the transportation method of your code and onto a framework. The more you can decouple your solution, the fewer headaches you have late on down the road.
The most popular form implementing a real-time observer pattern within .NET is with SignalR. SignalR is a Microsoft product that was developed to produce real-time applications, like instant chat or real-time notifications. SignalR allows the server to push messages to clients without clients frequently polling the server. In SignalR cases, Microsofts may come up with a better way of real-time messaging within an HTTP2 connection, bundle it up into a later version of SignalR which you get for free by simply updating SignalR within Nuget.
Software Architect, Programmer and Technologist Jon Jones is founder and CEO of London-based tech firm Digital Prompt. He has been working in the field for nearly a decade, specializing in new technologies and technical solution research in the web business. A passionate blogger by heart , speaker & consultant from England.. always on the hunt for the next challenge