5 ms·
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
by jedberg 3y ago
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.
- assimpleaspossi 3y agoThis sounds like a hack around a programming problem that needs to be fixed.
- jedberg 3y agoI don't even understand what that means. What programming problem?
- assimpleaspossi 3y agoIf 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.
- jedberg 3y agoNot 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.
- assimpleaspossi 3y agoSame issue. If one needs to spin this up just for a one-off usage, there's something wrong that needs to be fixed.
- jedberg 3y agoI’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?
- alberth 3y agoDumb question, then why not stick that API on a machine/service that does need to be used 99% of time.
- nonsense_stream 3y agoBecause 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.