I see a lot of people put Varnish into their stack, but mostly to serve static files, which feels like a waste - Nginx can handle that fine for most people's st

I see a lot of people put Varnish into their stack, but mostly to serve static files, which feels like a waste - Nginx can handle that fine for most people's stacks, I'd imagine. For really high traffic sites where static assets are off-loaded to other servers, I wonder if Varnish even makes sense (versus an enterprise solution with edge servers across the world). Using Varnish to cache http request that are returned from your code (e.g. the HTML returned from an application) is where I'd imagine you'd see the highest gains. However, that gets pretty complex, especially when dealing with cookies for logged in users. What I would find really useful are guides on getting utility out of Varnish, rather than just "cache http responses" - for example: * Ability to do cloudfront/s3 style signed-requests to create temporary or one-time downloads for authenticated users * Cache OTHER PEOPLE's API's that your site calls out to, especially if the other API doesn't change often. In this scenario, your app would call on a Varnish server, which in turn would be caching responses from an external API (a reversal of the typical way you'd think people use Varnish). One possible use case might be in deployment, grabbing .zip files from Github. * Rate-limiting requests to your API