Just to clarify, we don't _want_ to use Socket.IO on Node.js but combined with the client-side library it has a lot of benefits (multiple transports, automatic fallback, good cross-browser support, namespaces and rooms match our problem domain). The server component is sufficiently complex that we don't want to replicate all of that functionality ourselves.
We don't need huge scalability (at least, not in foreseeable future) so the in-memory aspect of Node.js's implementation isn't really a concern if we have to fallback on it and expose our services via REST to it. We'd rather have the whole server side on the JVM however. We can't use direct WebSockets because browser support is not good enough (and won't be for our target market for a long time I suspect). That's why we are looking at netty-socketio since it seems to support the Socket.IO client "out of the box" and is reasonably easy to use from Clojure. The reasons stated above are also why we can't just use http-kit (which was my first thought) - we need more machinery than just WebSockets. I had found this by Chris Granger - https://github.com/ibdknox/clj-socketio - but it's outdated and when I reached out to him, he confirmed the first point above - that the server side of Socket.IO is too complex to warrant trying to replicate ourselves (and that Socket.IO had evolved sufficiently that his project wouldn't be a useful starting point either). Sean On Wed, Jul 17, 2013 at 4:37 PM, Anand Prakash <anand.prak...@gmail.com> wrote: > Hi Sean, > We are in process for going with a similar solution on clojure. Lets keep > sharing notes. > > We were on heroku till last week. Websockets wont work on heroku. Lack of > sticky session caused other issues. So we moved to elabstic beanstalk. > However elastic beanstalk doesn't support jetty and I do not like tomcat. > Plus on elastic beanstalk whenever you push code they have a down time upto > 5 minutes. > So over the past 2 days, we moved things to chef on ec2 which I am really > happy with. Now we have a system as easy to use as heroku, with much more > control. I am mentioning these because you or others might go through the > same steps. > > Coming to your main point about Socket.IO. We spent around a week exploring > Socket.IO. It was super easy to hack up a demo, however we ended up leaving > it for couple of reasons: > 1. Though the community looks very active in terms of forks etc, the > development on Socket.IO is completely stopped. The dev team is focussed on > engine.IO and they are very opaque. When you post on socket.io google group, > posts do not have get approved. If you propose to help, you do not get any > response. > 2. The library has lot of features - like rooms etc. However they are not > built to scale. I looked at the code and was very disappointed. User->Room > mapping, Room->User mapping were stored in memory which will make it not > scale beyond a point. Bad coding (e.g. using lists traversal where hash maps > should be used) is very common in nodejs community and I am very wary of > developing on that platform. > 3. There was a memory leak in Socket.IO which would cause memory to increase > linearly with usage. Given that most projects using nodejs dont move beyond > prototypes these kind of issues do not get highlighted. I used to manage the > mobile server at LinkedIn and we had to deal with a lot of memory leaks with > node.js. > 4. Javascript > > So finally, if you really have to use Socket.IO, I would recommend using > https://github.com/einaros/ws for just websocket and built everything else > yourselves. > > I am not a big fan of keeping two different setups at the stage of our > product. We are fine with long-poll for now. So we will start there and > eventually get to web sockets. We are considering http://http-kit.org/ for > that. For communication between message generators and open client sockets > we are exploring some pub sub solution. > > Hope this helps. > > Thanks > Anand > > > On Tuesday, July 16, 2013 10:07:34 PM UTC-7, Sean Corfield wrote: >> >> At work we're starting down the path of building a new piece of >> functionality based on WebSockets and the external team we're working >> with is a Node.js shop so their go to solution is Socket.IO and >> they've produced a very nice front end in CoffeeScript and a prototype >> back end on Node.js. >> >> I'd really like to have our back end on the JVM, of course, and so I'd >> like to find a JVM-based Socket.IO solution that I use from/with >> Clojure... >> >> This seems like a reasonable option: >> >> https://github.com/mrniko/netty-socketio >> >> A little bit of experimentation with lein-try (Thank you Ryan!) shows >> that it's pretty easy to get a basic server up and running in the REPL >> - and I was able to get several of their demos running unchanged >> against Clojure, instead of their Java applications, so that was >> promising. >> >> Are there other folks out there doing Socket.IO stuff with Clojure? >> What approaches have you taken? >> >> Obviously, we could run Node.js and have it hit a Clojure-based REST >> API to do the integration, and that might be less pain long term >> but... >> -- >> Sean A Corfield -- (904) 302-SEAN >> An Architect's View -- http://corfield.org/ >> World Singles, LLC. -- http://worldsingles.com/ >> >> "Perfection is the enemy of the good." >> -- Gustave Flaubert, French realist novelist (1821-1880) > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
