|
I've been out of the RoR loop for a long while. I just deployed a tiny serverside app for an iPad app I wrote, and it was a huge pain to deploy on my Joyent lifetime account. Heroku looks absolutely amazing - I love that deployment is just a git push. But I have one snag... This app depends on push notifications and is really really latency sensitive. When I want to send a push notification it needs to be sent right away. However, Apple requires that push notification providers hold the connection to the service open as long as possible, rather than opening a new one for every notification. All the current Rails implementations for the APNs use a queue/cron system to batch notifications up in order to get around this requirement. I ended up writing a daemon that maintains the connection to their servers forever, and communicating with it through a named pipe in the app. That works really well for the environment I'm in. However, I'm on a lifetime shared hosting account with low limits. If this app takes off, I'll be screwed if it hammers my servers too much, and have to move it somewhere else (which is sort of a problem I'd like to have...) Heroku looks like a great place to migrate to if this thing gets too big. Hell, I'd use Heroku for what I currently use my lifetime account for, which is basically a dev sandbox. But I'm wondering about how I'd implement what I have already on their service. I see that they allow for worker processes at 5c/hr (which adds up fast monthly) but I'm not sure whether this setup would actually work for me. I read their overview documentation, and it seems like it COULD work - I'd just have to communicate with it through the database rather than the named pipe, which would be some work. But I don't know what the gotchas are there. Has anyone else done something like this on Heroku before? I'm just making sure I have an escape plan if I need it.
|
#
¿
Apr 18, 2010 04:10
|
|
|
|
| # ¿ Apr 25, 2024 03:09 |
|
|
Sorry, push notifications go the other way - from my app to the daemon to Apple (and then to devices). The latency I was referring to is the delay between when someone hits my app with a browser and the push notification appears on their device. A couple seconds is fine, but anything over about ten and it loses most of its value. So the fifo was the easiest way to do that. I actually just took another Ruby daemon that was already out there but used TCP sockets and ripped the Apple connection code out of there and then wrote the fifo part. Local notifications won't work for this because the push is definitely generated off-device. The app is just an app that lets you click a bookmarklet and then you get a popup on your device that you can press to open the page you were viewing on your computer. I made it mainly because I found that I was doing that all the time by hand, since the iPad is really nice to read the web on. I was mostly just asking to see what the capabilities of the workers were and if they could be expected to live long lives. The architecture looks like they might migrate between servers from time to time.
|
|
#
¿
Apr 19, 2010 03:18
|
|
|
skidooer posted:
I had no idea about the method_chain, that's awesome.
|
|
#
¿
May 8, 2010 18:43
|
|