Hacker News new | past | comments | ask | show | jobs | submit login

The main use case if for seldom used APIs. If I run a service where the API isn't used often, but I need it quick when it is, Lambdas or something like it are perfect.

As it turns out, a lot of APIs for phone apps fit this category. You don't want a machine sitting around idle 99% of the time to answer those API calls.




Dumb question, then why not stick that API on a machine/service that does need to be used 99% of time.


Because the API also needs some separation. The same reason you would want your services isolated in VMs instead of all running in one bare metal.


This sounds like a hack around a programming problem that needs to be fixed.


I don't even understand what that means. What programming problem?


If you rarely need an API but set something up like this just to rarely use it, it seems one needs to write their own code for this functionality and not go through hoops to run someone else's. That just sounds so bizarre.


Not someone else's API, your own. You make an app. It needs an API that you create (perhaps to sync up scores or something). You don't want to run a machine full time just to accept one score update a day.


Same issue. If one needs to spin this up just for a one-off usage, there's something wrong that needs to be fixed.


I’m not sure how to explain this so you’ll understand. It’s basically how all phone apps are written. It’s a common pattern.

If you made a iPhone game and wanted the high scores to sync to a global scoreboard when the game is over, how would you build that?

What if you only expected 10 players a day?




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: