Using google, as well as searching on github produces a list of a lot of different adapters for socket.io. Curious if one is the de-facto standard in the community for socket.io?
Thanks
Using google, as well as searching on github produces a list of a lot of different adapters for socket.io. Curious if one is the de-facto standard in the community for socket.io?
Thanks
Eg can anyone recommend using Brent J Andersons adapter? https://gist.github.com/brentjanderson/4360857
It appears to be highly undocumented, and my code breaks on line 69:
this.rootForType(request.type)
Any clue what rootForType is and why I can’t find it in any of the Ember API Docs?
Thx
Got an e-mail from Brent saying his adapter is way out of date.
So I am still open to new ideas?
I searched for socket adapters recently didn’t find anything help full was going to write my own that would listen for changes for loaded models
BillyBonks, thanks for the input. I am leaning towards that as well. But that is depressing.
take a look at EmberFire
It’s pretty fast to write your own. Mine extends the REST adapter and utilizes the REST serializer, but ultimately it depends on my having implemented specific types of events on both ends. I feel specifics of the setup for io on node vary enough that each adapter has to be heavily customized most the time anyway.
@jthoburn @billybonks I am going to give a custom adapter a shot, but would just like a nudge to get started. I see that the find() function should return a Promise, but I am not really clear exactly what that promise should do? Is it returning json or models? If it’s models how should I be resolving them from json? If I can just get passed this first hurdle, I am optimistic
The promise should reject if errors occurred, and resolve with the resulting json if it succeeded. If you want to sideload records, I usually do that before resolving the promise.
Another note, if the callback function provided to socket.io errors, it crashes the websocket. I usually will wrap the return with Ember.run
or Ember.run.later
to prevent that.
makeSocketRequest : function (store, eventType, query) {
var adapter = this;
return new Ember.RSVP.Promise(function (resolve, reject) {
try {
if (App.Socket.authenticated) {
App.Socket.emit(eventType, query, function (data) {
if (data.status) {
resolve(data.content);
} else {
reject(data);
}
});
} else {
reject({ message : 'App.Socket is not authenticated'});
}
} catch (e) {
reject({ message : 'App.Socket is not available for requests'});
}
});
},
find: function (store, type, id) {
return this.makeSocketRequest(store, 'find', {
type : type.typeKey,
query : { id : id }
});
},
(In my case, makeSocketRequest is analogous to the ajax method usually found in an adapter, a reusable method for GET/POST/PUT/DELETE. The semantics of what I pass in query are purely subjective, something to consider doing is passing full routes for consumption by express endpoints or that match an API you are proxying to.
@jthoburn that’s great, thanks! I am curious: are you using https://github.com/auth0/socketio-jwt for the authentication?
Do you guys plan on using this alongside a REST adapter? Because that’s what I’m doing now, most of the data is handled by the ActiveModel adapter and updates are pushed over a socket. It works okay but I have some pretty nasty code in that socket handler right now that I’d love to clean up…
Hi @jurre, I am going for a socket only approach for this
There’s always https://github.com/Wildhoney/EmberSockets.
I’m not, I implemented my own. I didn’t want to expose the JWT during the handshake, so it is emitted as an authentication event following the handshake.
the problem with that package, is that it doesn’t work as an adapter