3 ms·

The problem with push: can small developers afford it?

7 points by naish 18y ago

mcav 18y ago
The author seems to confuse push with polling: > Consider an application with just 10,000 users. It might service a million uses per day, assuming update checks every 15 minutes. More time-critical uses might demand checks every few minutes or even several times a minute. As the computational burden builds, so do the hosting costs. While cloud computing provides an excellent match to these kinds of needs, that kind of solution comes with a real price in development, maintenance, and day-to-day operations. With push, small developers are saved from the hassle of handling lots of polling connections. They just push according to what their application needs -- it's more scalable, and that's the point.
- wmf 18y ago
  It depends. Consider the prototypical iPhone app, the Twitter client. AFAIK, the Twitter API only supports polling, but the iPhone only supports push for background notifications. Thus the app developer is left to build (and pay for) a polling/pushing adaptor. Somebody like Gnip could make good money here.
  - tesseract 18y ago
    Or consider an instant messaging client - incoming messages are pushed from the IM service, but not directly to the iPhone in the format it understands, so the app developer would have to operate a server that maintains an open connection to the IM server for each app user and forwards incoming messages to their iPhones.
    - collint 18y ago
      It really is a good thing that multiple pieces of software exsists for doing just such a thing. Modern messaging middleware can handle in the range of hundreds of thousands of messages per second. Talent and domain knowledge will be important, but iPhone "push" changes little.
- smokinn 18y ago
  The real problem with push is that you have to deal with a massive number of open connections. Most web servers just aren't designed to handle that. Polling isn't much of a problem with proper caching. Push is for cases where data is truly time critical. If it's no big deal for the data to get there a few seconds after it's been generated polling every 10 seconds will usually cause less strain on your servers than keeping lots of connections open. Just don't hit the database every 10 seconds! Generate your data before the request, throw it up in memcached and pick it out of memory when the request comes along.
  - sokoloff 18y ago
    So in your proposed solution, you're going to "push" the data to memcached, but rely on polling to get the data to the end user, right? If the problem is that your webserver doesn't handle large numbers of open quiescent connections well, then don't use that webserver. Clearly you're capable of writing the application that is pushing the data into memcached. Just have that same (type of) app push the data to the end consumer. Designing a naturally push app to be push-into-cache and then poll seems to be going the long way around. It may also set you up for a terrible scaling "elbow" where at some point with increasing load, you'll suddenly be polling for data that was just expired from memcached and you may have little warning that that's about to happen. Apple's worries about battery life and end-user experience are valid and no amount of tears from small developers is going to change them. They have to keep giving the consumer a good experience, which is ultimately what you/we as developers have to do. If that changes the economics slightly, so be it, but Apple is rightly concerned foremost about the buyers of iPhones, not the developers for them.
rs 18y ago
Webhooks are an example of easily implemented "push" tech http://webhooks.pbwiki.com/ http://webhooks.pbwiki.com/
mattmaroon 18y ago
The easy solution here is to just charge $1 for your app. Then if 1m people download it, you can afford to deal with it.
- patio11 18y ago
  Some combination of cash and cache can solve just about every performance problem I've ever heard about. (Incidentally: if you are creating a service which will be used over the long term and which provides value, you should not be pricing it anywhere near $1.)
  - comatose_kid 18y ago
    Unless that value is predicated by the number of people using it...
deleted 18y ago
[deleted]
jdg 18y ago
Something I've been musing over for the last few days has been whether or not this will help raise prices in the app store. Or will "push" be an add-on, purchased for $4.99/mo/yr via the new in-app store. As cstejerean said, "no shit, servers cost money." In any event, there are new ways coming to make your money back. Ars may be looking at this within the context of the current app store. Looking at it from what will be available in the near future changes the game a bit more. I for one will be raising prices on my apps, whether that cost is up front or via an in-app purchase after a short trial. We're not selling apps to lose money.

7 points by naish 18y ago

mcav 18y ago

The author seems to confuse push with polling: > Consider an application with just 10,000 users. It might service a million uses per day, assuming update checks every 15 minutes. More time-critical uses might demand checks every few minutes or even several times a minute. As the computational burden builds, so do the hosting costs. While cloud computing provides an excellent match to these kinds of needs, that kind of solution comes with a real price in development, maintenance, and day-to-day operations. With push, small developers are saved from the hassle of handling lots of polling connections. They just push according to what their application needs -- it's more scalable, and that's the point.

wmf 18y ago
It depends. Consider the prototypical iPhone app, the Twitter client. AFAIK, the Twitter API only supports polling, but the iPhone only supports push for background notifications. Thus the app developer is left to build (and pay for) a polling/pushing adaptor. Somebody like Gnip could make good money here.
- tesseract 18y ago
  Or consider an instant messaging client - incoming messages are pushed from the IM service, but not directly to the iPhone in the format it understands, so the app developer would have to operate a server that maintains an open connection to the IM server for each app user and forwards incoming messages to their iPhones.
  - collint 18y ago
    It really is a good thing that multiple pieces of software exsists for doing just such a thing. Modern messaging middleware can handle in the range of hundreds of thousands of messages per second. Talent and domain knowledge will be important, but iPhone "push" changes little.
smokinn 18y ago
The real problem with push is that you have to deal with a massive number of open connections. Most web servers just aren't designed to handle that. Polling isn't much of a problem with proper caching. Push is for cases where data is truly time critical. If it's no big deal for the data to get there a few seconds after it's been generated polling every 10 seconds will usually cause less strain on your servers than keeping lots of connections open. Just don't hit the database every 10 seconds! Generate your data before the request, throw it up in memcached and pick it out of memory when the request comes along.
- sokoloff 18y ago
  So in your proposed solution, you're going to "push" the data to memcached, but rely on polling to get the data to the end user, right? If the problem is that your webserver doesn't handle large numbers of open quiescent connections well, then don't use that webserver. Clearly you're capable of writing the application that is pushing the data into memcached. Just have that same (type of) app push the data to the end consumer. Designing a naturally push app to be push-into-cache and then poll seems to be going the long way around. It may also set you up for a terrible scaling "elbow" where at some point with increasing load, you'll suddenly be polling for data that was just expired from memcached and you may have little warning that that's about to happen. Apple's worries about battery life and end-user experience are valid and no amount of tears from small developers is going to change them. They have to keep giving the consumer a good experience, which is ultimately what you/we as developers have to do. If that changes the economics slightly, so be it, but Apple is rightly concerned foremost about the buyers of iPhones, not the developers for them.

rs 18y ago

Webhooks are an example of easily implemented "push" tech http://webhooks.pbwiki.com/ http://webhooks.pbwiki.com/

mattmaroon 18y ago

The easy solution here is to just charge $1 for your app. Then if 1m people download it, you can afford to deal with it.

patio11 18y ago
Some combination of cash and cache can solve just about every performance problem I've ever heard about. (Incidentally: if you are creating a service which will be used over the long term and which provides value, you should not be pricing it anywhere near $1.)
- comatose_kid 18y ago
  Unless that value is predicated by the number of people using it...

deleted 18y ago

[deleted]

jdg 18y ago

Something I've been musing over for the last few days has been whether or not this will help raise prices in the app store. Or will "push" be an add-on, purchased for $4.99/mo/yr via the new in-app store. As cstejerean said, "no shit, servers cost money." In any event, there are new ways coming to make your money back. Ars may be looking at this within the context of the current app store. Looking at it from what will be available in the near future changes the game a bit more. I for one will be raising prices on my apps, whether that cost is up front or via an in-app purchase after a short trial. We're not selling apps to lose money.