Yes I looked into dnode and it seems to follow kind of a similar object based approach to prevent naming inconsistency. Altough I think my solution is not strictly RPC based. For example in the JSON file I can define (and mix) the type of each message seen from the client side: only allow listening on message, only allow emitting the message or a "get" type which is like RPC (emit and listen once for answer).
And the other problems like listener management and missing wildcards seem to remain in dnode if I'm not mistaken. On Tuesday, September 24, 2013 12:30:37 PM UTC+2, spion wrote: > > I use dnode through shoe(sockjs): https://github.com/substack/dnode > > With this I get the best of both worlds: support for event listeners (you > can pass callbacks) *and* RPC (like getUserData) - in a single package. > > On Monday, September 23, 2013 6:28:52 PM UTC+2, André Eife wrote: >> >> At the moment I'm developing a large web application heavily relying on >> websockets and socket.io basically for all server communication. During >> developement I discovered some problemes and developed a little library as >> an approach for a common solution. So I would like to share my thoughts and >> hear your opinion on it. >> >> First the main problems I discovered using websockets: >> >> 1. consistent naming of messages on client and server >> When using REST you get an error message when requesting a wrong or non >> existing URL from the server. With socket.io if you mistype a message it >> is just ignored by the other side without any error indicating this. >> >> 2. managing listeners >> In a big web application with lots of seperate modules and lots of >> communication it's quite hard to handle all the listeners. Multiple modules >> can each open a listener for the same message but you have to be carefull >> to not open a listener again for the same functionality which is already >> open. Otherwise the same code is excecuted multiple times when receiving >> the message and this may result in potential errors which can be hard to >> debug. >> >> 3. no wildcards and problems with simultaneous messages >> So for example each module requests some data for a different user from >> the server. There is a message like "getUserData" so this can be requested >> from the server and is listened once for the answer. If this happens for >> multiple modules at the same time, the first answer for this message will >> be processed by all modules (and thats why some get the wrong data) and all >> following answers will be ignored because of the once-listeners. >> >> >> So I thought about it and tried the following solution: >> You no longer use strings for messages but just define the required >> message api as a JSON like this: >> { >> user: { >> info: { >> on: { >> attach: 'username' >> }, >> emit: {} >> } >> } >> } >> >> This is translated by the library into an object including all the needed >> socket.io functionality. Instead of using *io.socket.on('userInfo', >> callback);* you use *socketapi.user.info.on(callback)*. On the server >> the object is also used and so you can't mistype messages or listen for non >> existing messages. >> >> When generating the usable api object from the JSON file there are also >> multiple helper functions included trying to solve some problems. For >> example after declaring the listener you can use chaining and call a >> function *onRoute()* instantly so the listener is only valid while the >> route of the web app has not changed. The function *whileLoggedIn()*closes >> the listener when the user logs out. Otherwise an object containing >> functions to stop and resume the listener at any time is returned. >> >> Also there is some wildcard support. So for example in the >> example above the "attach" attribute in the inner object declares that a >> wildcard is attached to the message. So you actually use it like >> *socketapi.user.info.on('someUsername', >> callback);*. The library attaches the username to the message and the >> server recognizes it because it uses the same object. >> >> >> There are other things to it but the main intention of this post is that >> I wanted to share my thoughts and my approach of a solution. It helped me a >> lot during my current project and solved a lot of problems for me but I >> really would like to hear your opinion on this. >> >> -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
