Provide a generic pattern to trigger the REST adapter and update the store

[gonvaled]

As far as I understand, the hooks that you are providing in EmberSockets allow to update some properties in the controllers. What about this (I think quite generic and useful) use case:

1. A record is created (or updated / deleted) on the server
2. It gets pushed via websockets to the Ember application
3. EmberSockets receives, triggers the REST adapter, and updates the store.

This way we can push generic data to the Ember application, and have it automatically be rendered in any view that we have currently active.

Just to clarify, it is not just a matter of parsing the JSON coming from the websockets server and pushing it to the store: the full REST adapter pipeline must be triggered in order to avoid re implementing parts of it.

Could this be added to EmberSockets?

[Wildhoney]

Seems like an interesting idea. How do you imagine we implement this?

[gonvaled]

I know little about ember and ember-data internals (and even less about EmberSockets), but my top-level approach would be:

First, the data coming from the websockets server must be exactly the same as the data coming as reply to a normal REST request, as triggered by the REST adapter.

That data will reach EmberSockets, which must recognize this use case, maybe by extending the sockets hash to activate this feature:

sockets: {
    cherryPickedName: 'name',
    genericREST : true,
}

Now a function to handle that must be implemented, which would receive the eventData and pass it to REST adapter pipeline, in order to perform all the processing which has been configured in the adapter, and as a result update the store. Unfortunately I do not know if the REST pipeline is exposed to trigger it programmatically.

Also, I do not know how to handle DELETEs: usually a DELETE is done on the store and then requested on the backend via the REST adapter, but this would be the opposite operation: the backend has detected that a record has been deleted, and it must inform all connected clients of this. What I mean is that I do not think that the REST adapter reacts in any way to DELETE operations, but triggers them on the server: a specific mechanism should be provided to recognize DELETEs coming from the server.