• http://www.buddy.com/ • http://js.dotcloud.com/ • https://cloudmine.me/ • http://backlift.github.com/docs/ • http://www.meteor.com/main • https://parse.com/about/index • http://derbyjs.com/ • http://www.kinvey.com/ • http://www.stackmob.com/ • http://www.appcelerator.com/cloud • http://pusher.com/ • http://www.firebase.com/ • http://www.pubnub.com/ • https://www.getbridge.com/ • https://www.tambur.io/
We have messages that need to go to our users in three tiers of channels:-
a) a bunch of "control" messages to all users (~200 a day to n users) b) users can form subgroups (from 1 to n users) each "control" message will likely require a unique push for each subgroup c) individual pushes to each user
Right now (b) and (c) aren't being performed using APE, we just make the clients poll for the new data once they receive a "control" message, but it's better to push the data out to the individual users rather than have them bother a webserver to get the info - even if it is just being served from memcached or varnish and never bothering the backend DB.
APE is good for us right now, but with ideas for supporting a much greater number of users (>100,000) I'm planning on knocking up a replacement in C. APE is just overkill for our needs. I'll probably also end up having to use libnetfilter-queue to process the raw TCP directly as kernel memory buffers (4KB each for read/write buffers for each connection) soon add up with >1M users but if it gets that far it'll be a lovely problem to have.
Our approach was based on horizontal scaling of commodity hardware (on Amazon EC2). We have X number of worker instances serving clients and they internally publish and subscribe using a Redis cluster. Have a look into Redis, ZeroMQ or RabbitMQ.
But definitely give our service a try in your free time or for your side projects :)
Pusher uses WebSockets; this is awesome and a very forward thinking technology however can be limited by older browsers and proxies not supporting the WebSocket connection. Notifyr uses EventSource (also a HTML5 spec) and XMLHttpRequest, aiming to support a majority of browsers, including mobile browsers.
Additionally, we aim to integrate with Apple and Google's push notification system in the future, allowing a universal method for sending push messages with one API for any platform, device or browser.
Here's their browser compatibility: http://pusher.com/docs/browser_compatibility
I'm biased - we use Pusher and love it - but regardless, didn't want misinformation spread. :) I'm all for competition.
The fact that the claim you made here about Pusher and legacy was so quickly disproven, makes things even worse.
