How can we improve Breeze.js?

Use websockets/signalr to push updated objects instantly out to the client cache

On the client side, objects can get stale if they are frequently updated. Instead of requiring constant polling to see if entities have changed, allow updates to be pushed from the server out to the client cache. That change would in turn trigger knockout bindings so that the HTML instantly updates.

385 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Brian Reynolds shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Nigel Dewar commented  ·   ·  Flag as inappropriate

    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?

  • Patrick Roza commented  ·   ·  Flag as inappropriate

    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;

  • Anonymous commented  ·   ·  Flag as inappropriate

    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...

  • Chris Tomlinson commented  ·   ·  Flag as inappropriate

    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.

  • Jeremy Noble commented  ·   ·  Flag as inappropriate

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

  • RockResolve commented  ·   ·  Flag as inappropriate

    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.

  • Brahma Acharya commented  ·   ·  Flag as inappropriate

    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..

  • Ward Bell commented  ·   ·  Flag as inappropriate

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

  • Ward Bell commented  ·   ·  Flag as inappropriate

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

  • Michael Ralston commented  ·   ·  Flag as inappropriate

    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?

  • Andrew Newton commented  ·   ·  Flag as inappropriate

    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.

  • Anonymous commented  ·   ·  Flag as inappropriate

    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:

  • Anonymous commented  ·   ·  Flag as inappropriate

    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 :).

  • Richard Davison commented  ·   ·  Flag as inappropriate

    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...

  • John Bloom commented  ·   ·  Flag as inappropriate

    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.

← Previous 1

Feedback and Knowledge Base