I know WebSockets are largely considered a replacement for a REST API, but I think it could be useful if Kinvey supported a scenario where WebSockets simply complemented the REST API as a means for an HTML5 application to receive the equivalent of a push notification when an entity or collection changes. For example, if I have a collection called "animals" and I wanted to know when a new animal was added I could listen for changes like this:



var animalSocket = new WebSocket("wss://baas.kinvey.com/appdata/kid_MyApp1D/animals", ["apiVersion3"]);

animalSocket.onopen = function (event) {

animalSocket.send(JSON.stringify({authToken: "abcd123456789"}));

};



...



animalSocket.onmessage = function (event) {

console.log("Got a new animal");

console.log(JSON.parse(event.data));

}



Then when someone else adds an animal to the collection (assuming I have access to it via the ACL), I would receive a message ideally containing the new object, but alternatively just a notification that "hints" that I should GET a given collection or entity again since it has been updated.



An alternative to having a socket on each collection with a more generic solution might be just to have one per application ID and make the messages more generic like:



{

action: ["created" | "retrieved" | "updated" | "deleted"]

collection: "animals"

}

Did anyone from Kinvey ever come back on this idea? Looks a great one!

Seems like a great idea. However given that WebSockets are still not widely used (maybe rather the number of legitimate use-cases only makes up a tiny portion of web/mobile activity) and the amount of backend work required for this, I can see it not being a top priority at the moment.



Instead a structured heartbeat solution would be nice, perhaps coupled with user discovery. Maybe you can share your use case to further discussion on this?

Perhaps not widely used yet, but according to [caniuse.com](http://caniuse.com/#feat=websockets "caniuse.com"), they have at least partial support in almost 76% of browsers including mobile so I would say it is an underused feature at this point in time :smile:



The use case is essentially to avoid a polling heartbeat to check for changes on an entity or collection which happen as the result of another user's actions. I don't see how this can be coupled with user discovery though, can you elaborate on that bit?



As for the amount of work, I can't really comment since I'm not much of a backend guy (that's why I use Kinvey!), but it's difficult features that make products stand out from their competition so it might be a good differentiator. Anyone can implement the easy stuff :wink: As for the cost benefit, that's for Kinvey to decide, but I guess this is a good place to express interest.

Would you mind explaining just a bit more? If one user makes changes on data in a collection, do other users need to know about this for fetching (display/read) purposes, or for update purposes (as in, you want to prevent them from overwriting changes made since they last saw the original data)? Maybe sharing a more real-life use case would help in understanding.



The reason I ask is because you should be able to use conflict resolution (see http://devcenter.kinvey.com/html5/guides/caching-offline#CustomConflictResolutionPolicy) to handle updating. If you really need to have data displays essentially updating in real-time (as in, one user changes something and within seconds the other users see that change on their view) then I would agree websockets is probably the right fit for you.



In regards to the point I mentioned about "coupled with user discovery" - that's because one of the more common uses these days for websockets (outside of gaming) is chat programs. A frequently used alternative is heartbeats, so taking it one step further via Kinvey SDK could be to flag a user (or any associated kinveyRefs, for example, a messages collection) as "watching" - so that a heartbeat could be automated. This is all just an idea of course, but basically a method where you can specify an ID of a user - along with various callback functions, which are triggered when the heartbeat detects a change in set collection/fields. One step beyond this would be channels (groups) that users can create/subscribe to, with some degree of access control.