interesting, i hadn't seen that! it does say it's not meant to be a front-facing server since it has no authentication, which is a slight downside (one of the reasons I added github auth to mine was to allow logging in from anywhere)
Basically, you want to listen for the 'open' event and then start the express server... db.once('open', function() { start express here })
A very important future feature would be to handle apns feedback service too (I see that in your TODO). I hear that if you don't enable this, apple will throttle your messages.
yes, feedback service integration is next on the priority list. i think it should take about 30 minutes or so. so far this whole project is only a few hours of work. i don't open-source much of my code, but i thought this might be a good candidate.
This seems like a more full fledged APNS server with a web frontend.
If you are looking for more transactional approach to integrate into an existing node app. I've been using node-apn in production for almost a year now. works well.
For Ruby I definitely recommend RPush: https://github.com/rpush/rpush. Helios hasn't been updated in a very long time and has a massive list of unresolved issues.
Nice to see more open source push notification tools, and the quality is generally getting better.
The main drawbacks to PushServer seems to be that it's not cross platform, and it doesn't interact with Apple's feedback service. Apple has an ominous warning for people who decide to do this: "APNs monitors providers for their diligence in checking the feedback service and refraining from sending push notifications to nonexistent applications on devices." [1] Though it's unclear what the penalty really is, and this is listed as a TODO item by PushServer [2]
My company decided to build a push notification system in house. We needed it to be cross platform, able to handle very large volumes, and fully follow all of Apple and Google's guidelines. We recently released it as a service for other game developers: https://gamethrive.com
Having built something like this myself and wrestling through the all the edge cases, I've come to the conclusion that unless you have a good reason for doing so, you should outsource sending of push notifications to a 3rd party service. Parse, Urbanairship, and GameThrive (our service) do a good job and are way less expensive than maintaining it yourself, especially if you plan to deliver a high volume or have multiple platforms to deal with.
...thx for the FUD on my three hour project I decided to give to the world. This is generally why I don't open-source stuff.
Feedback support is coming. Also as noted below, I am familiar with iOS push having built a previous YC startup around it.
Some class of people will want to do it themselves. I am one of those, presumably the audience on HN is full of those ppl, it's why I posted it here. Doing is learning.
This looks promising. Though I have to add, sending push notifications is on the list of things I definitely outsource, along with email delivery, analytics, payment processing, etc.
Why? The message format is relatively simple to compose, and every language has at least one library to make the process easier. The connections to Apple/Google are free, and you've probably already got a database of some sort, so why not just do it yourself?
Because it's a headache and hassle that's not worth it. Using a saas service is not a large expense and frees up time and mindshare to focus on things I can add value to.
Best case scenario you have to:
1. Worry about Apple AND Google push notification infrastructure
2. Manage device tokens
3. Forever add one more cron to your life to manage device token invalidation requests for Apple (Is there something similar for Google? I dunno)
4. Gotta keep your certs/keys updated
Yes, you can work around all that stuff. Of course you can, people are doing this after all. But an even better option to me is to spend a small sum and let somebody else worry about these boilerplate systems.
more like Parse's push value-add (b/c they have a notion of push channels and devices). My previous startup (Notifo) was a push notification-as-a-service company, so I'm familiar w/ push. This was just a weekend project to scratch and itch for an app I'm currently writing and I didn't want to use a 3rd party service b/c they are too inflexible and too much lock-in.
I don't understand either. It seems the use case is limited to pushing a notification to all devices. I know plenty of apps do that, but it is generally just spammy.
Any app that needs to send custom push notification to individual users needs to have connected the user_id to the device_id. Once you go the Urban Airship route, there is basically no way to do anything useful with push notifications.
Parse seems to be the only 3rd party service that can do something useful, but you would need to use their user/authentication system.
Parse has become so unreliable and my users complain a lot about APNS not going through. It's working for some and not working for many in PROD. Hard to figure why it's not working as everything else you touch in Parse will ask for a paid service (straight to Enterprise Plan!). Will have to code something by myself.
Not sure what you'd define as useful, but the core value add for UA these days is more in location-based segmentation, rich messaging, automation tools, etc. Sending a single broadcast notification is the most basic thing you could do, but not necesarily the focus.
Works for android as well, and has a nice web interface too.