Signal R between boot and update
I am trying to create a signal application. The application outline will be:
- Load the original state from the database
- Subscribe to follow-up messages
I was looking for a set of best practices. If I subscribe to updates after the initial download, there is a risk of no updates. There may be an update between the initial download and the subscription, and I will skip this update.
Second, I could use some sort of object state identifier and then subscribe to the update stream first, fetch the data, and then apply updates if the objects are behind. This will require quite some code.
Are there any recommendations on this?
source to share
There may be a miss in the case of an update request. For example, say your backend requests for some notifications and push that to the client, then the user connects (subscribes) to the notifications - the original dataset you pushed might be outdated if the update was sent during this initialization step and skipped.
What I have found as the best practice is to opt out of sending any raw data. Instead, subscribe as soon as you can and request updates on successful connection. eg....
var proxy = $.connection.yourHub;
$.connection.hub.start()
.done(function () { // <--- immediately call once connected
// define and call server hub method
// this will query updates and immediately
// invoke the associated client function
proxy.server.queryUpdates();
})
.fail(function () {
console.log('Could not connect!');
});
proxy.client.serveUpdates = function(updates) {
// here your fetched updates on initial connect
}
// YourHub.cs
public void QueryUpdates()
{
var updates = this.yourService.yourQueryUpdatesmethod();
Clients.Caller.serveUpdates(updates) // this calls proxy.client.serveUpdates
}
This gives you the ability to establish a connection, listen for updates, and efficiently serve the most recent set of data at a time when connected.
Note , this does not have to be a SignalR specific implementation. You can make a typical ajax call in this callback .done()
to get your results, but I don't understand why you can't reuse all the logic you already have in your hub. You can simply use this to call your existing hub method by explicitly calling it from the client.
source to share