Notifyr: a new service for push notifications
notifyr.ioLooks nice, but what's the difference between Notifyr and:
• 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/
Interesting. We're using APE for something similar (can't go into too much detail as it'll spoil our stealth mode) but with different scaling requirements.
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.
Yes.. having a large amount of concurrent users (>100,000) is definitely a challenge, and polling each time adds to the load as you are creating a new connection every time.
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 :)
How is this different from Pusher or the other dozen services like this out there?
Thanks for your comment. We believe offering our users more choice is always a good thing. Moreover, while we do provide a similar service, the way we deliver and our goals are slightly different.
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.
Pusher actually degrades to Flash Sockets if a browser doesn't support WebSockets: http://pusher.com/docs/flash_fallback
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.
On what project do you use Pusher? tinfoilsecurity.com ?
Yup no worries :D And Pusher is a fantastic service
More choice is only a good thing when you make it abundantly clear what it is you're going different, and why someone should use you. Otherwise, you're just making it harder for people to make a decision about what tools to use. Your front page doesn't do a very good job at that right now.
The fact that the claim you made here about Pusher and legacy was so quickly disproven, makes things even worse.
Hmm, doesn't Urban Airship integrate with the stores too? At any rate, this looks very well done, congratulations and good luck!
Thanks :)
From what I gather, Urban Airship aims more at providing a service for native apps rather then web based apps, but I could be mistaken.
Plans for mobile libraries and server sdks (java, node, python etc.)?
Yes definitely as we get more traction