We’re working on a JS/HTML drawing app that should support say over 50 users in the same space in real-time. Here’s the interface to give you an idea. Persistent bidirectional communication is very important, and it’s got to be fast. The idea’s to use WebSockets. But on framework, is meteor really the best course?
We’ve looked into ember.js Then there’s angular, require, etc. etc. A lot of people are recommending Meteor, but we’ve got to be able to achieve rapid and fluid drawing with virtually no delay.
Thanks for pointing me to Meteor Streams. I took a look at a few demos, including one in Streams, and I’ve found despite (usually) decent response times across clients they all suffer one fatal flaw. Brushstrokes are not sent and received as a continuous stream, but instead in jagged segments. Here’s a couple of the better demos I looked at which have this problem, Blackboard (using Streams) and Pen.
It’s important everything flows smoothly including the inputs by other users, but naturally, with minor lag which can’t be helped. So I’d be interested to know, how could we acheive this constant flow of the brush with Meteor? And if we reach a few thousand connections, though around 50 per drawing room, what sort of performance hits could we expect through Meteor (and perhaps MongoDB)?
Meteor stream use traditional pub/sub to make its communication. I have published a package https://github.com/YuukanOO/streamy which use directly meteor underlying socket to communicate with an easy interface similar to socket.io.
It performs quite well using basic Meteor API functionality. There’s no continuous brush because I’m not interpolating between each mouse event, or even drawing lines, but this could easily be added. Also, I’ve done no performance optimisation, so there’s a lot of room to work on improving the paint speed, and probably some smart MongoDB-level perf enhancements to make that could help it scale.
