zlacker

>>robbie+(OP)
This feels like it's all priced for AI companies, TBH. This per-request pricing makes a LOT more sense if you assume that one particular piece of content will only be requested once in your company's history, saved on a server somewhere and used for training forever. You're not paying for a request being processed, you're not even paying to offset any advertising cost, you're essentially paying for the ability to use the requested piece of content forever. Maybe that's what Apollo should do, set up a huge cache layer and proxy all requests for the public data through there? I feel like the power law would apply here, so 80% of the requests would be for 20% of the content. Considering how popular the most popular subreddits are, I wouldn't be surprised if the balance was something like 99-to-1. Cache misses would still need to be fetched from the API itself, but that should drive costs down massively.

If the ToS allow this, the cache layer could even be shared across apps from different developers (developers supporting both iOS and Android might have an advantage here), making the costs even lower.

>>miki12+gN
Would you use a client where the most popular threads are constantly out of date due to caching? I certainly wouldn't.

>>gsk22+So1
This wouldn't really be an issue for there to still be a massive advantage to even a simple caching layer.

Imagine one has 10 request for thread {X} every second (probably a massive under estimation of the actual traffic). If you cache that single thread with a lifetime of a second you have instantly cut out 90% of your API usage for that thread.

Obviously the final benefit depends on what the actual distribution of {users} per {threads} per {time} -- but if your goal is to shave redundant API requests than it definitely makes sense, especially if the alternative is untenable in terms of cost.