Hi There.

If the recommended way is to notify the client via signalR and then let the breeze manager do the update, does anyone have a sample of how this works? any code?

I am also on the notification wagon.
However an interesting aspect seems left unexplored; SignalR supports RPC so it could actually replace query calls to WebAPI.
I do believe the benefit would be minimal though; a bit less header overhead, maybe reduced authentication handling, but what more is there to be gained? Uniformity and just the need to support SignalR backend instead of also WebAPI backend, perhaps.

Not sure if that is rather a suggestion that is more closely related to; https://breezejs.uservoice.com/forums/173093-1-breezejs-feature-suggestions/suggestions/4446822-integrate-with-signalr

My vote is for SignalR

I agree with Ward. The decision to update or not should be done by the client. In our app we send notifications and let the client update if needed, seems more natural that silently update things...

Bump...

Voted for this but specifically for the websockets approach. Not interested in Signalr when there is a cross-browser W3C spec that offers the required functionality.

I've voted and I agree it should be notification for the client to decide how to handle...

I have partially implemented this in my client's project.

My project has two modes of notifying updates. In addition to the usual individual updates processed by breeze (saveChanges webApi) I also have some webApi methods that perform bulk updates. I've got this working well to let every client know of the changes, and update their viewed data.

I have the individual saveChanges working for edits, and will shortly start on Insertions & Deletions.

I went with Ward's approach only notifying clients of changes. This was absolutely the correct way to go as a client may never have used the record, or it may be used on a view that is not currently displayed (so I tell the VM its data is stale, so it refreshes its data when next fetched)

I used Jeffery's code as a starting point (I am the below anonymous!). But I had to add some client VM processing code.

I found someone who seems to have solved this with SignalR using Ward's notification only technique.

http://www.jefferyscottswensen.com/broadcasting-breezejs-entity-changes-with-signalr/

The way I would do this is just notify client that a particular change has occurred and let client refresh itself. Breeze then gives ample entry points.

As a side note though the more challenging part comes when you have to use SignalR in a load balanced environment where you need to use a well thought out messaging architecture to notify changes..

All - very definitely want to explore SignalR and socket.io and Ajax working together in a Breeze app

@michael - the HTTP back-end is pluggable. It's called the 'ajax' adapter. We do have to show how to replace the jQuery implementation.

would it be possible to make the http backend pluggable so it can be substituted with signalr or something else, if it were to come along?

I agree that SignalR should not be "baked in" to Breeze.. but maybe if a "SignalR Friendly" interface was exposed on Breeze that could easily be called from something like SignalR to allow it to easily be hooked up. Then just some examples on the Breeze website of how to do it would suffice.

Notification in client would be preferable.

Fyi: I put the logic for the sync mechanism into the entity definitions for the EntityStore, like this:

//Base Ctor
entityCtor = function () {
//holds snycState init to unchanged
this.entitySyncStateObservable = ko.observable(config.syncPubSubStates.isUnchangedState);
//... more stuff, not interesting here
}

and in the actual ctor for the entity
teamCtor = function () {
entityCtor.apply(this, arguments);
}

and extend the entity Ctor with the synclayer:
breezeSyncLayer.extendEntityCtor(teamCtor);

SignalR ist a great tool and i integrated it to a certain extend into my project to keep the GUIs on each client in sync.
I did it half-automatic (do not have time to implement full automation) and push a change notification to all other clients when the save-success-callback of a change of an entity is running, like this.

signalSyncNew = function () {
syncHub.signalSyncEntity(this.entityType.toString(), this.entityAspect.getKey(), config.syncPubSubStates.isNewState);
}

All i have to do is entity.signalSyncNew or entity.signalSyncDeleted() etc. The other clients then decide how to handle the change and reload the entity or load it in the first place on its own if they are interrested in it at all. A little group managment is in it too.
For one thing i did a lock mechanism for a specific type of entity and only one user can access/edit the entity. Not the best idea to do something like this, but to learn signalR and play its ok.

The work to be done by hand is mostly one line of code for entities. Works like a charm. I implemented this for fun to learn it but now the people want it for many other things too :).

I have to agree with Ward as well.
It would be nice though to be able to bind to the fact that a *new or modified* data alert has come in and allow the user to choose to update their session with that data....
Although I can't quite picture the method to do this from say a SPA where you are editing Item A from List L and new data has been added to L or A has been changed...

I've voted on this, but I also like more the tweaked version of Ward.

I agree with Ward. I also think that there should be integration with signalR. I would like it to tell the client that the entity has changed and let the client decide how to handle it.

We would want to alert the user that work was being done on the same entity that they are working on thus avoiding duplicate work. Then we could let the user click refresh to get the changes.

I am going to vote on this for this but in favor of the slightly tweaked version.