Discussion on: What does the server setup look like for dev.to

[Salman Ahmed]

Thanks for the insights.

So basically DNS wise you are just pointing dev.to to fastly which hosts the root page file, which then makes JS calls out to your heroku app?

So in effect the heroku app is an api server?

Or is there something more complicated going on DNS wise.

In terms of vendor lockin, say fastly "gets hit by a bus", what would the alternative be? I know one of fastly's strenghts is cache invalidation.

[Ben Halpern]

All cold requests go back to the origin server. If you update an article or something on the page, or modify a feed, you'll get the Rails-rendered page. All subsequent pages will be cached for further requests.

"reactions", for example, are loaded async, meaning the page doesn't go cold after each reaction. But if you change the text on the page or other things that purge the cache, you'll start cold.

Results in 85-90% cached responses.

[Salman Ahmed]

Ah ok, I think I got it now.

So you point your DNS to fastly, and all requests initially go to the origin server if not in the cache.

You have some excludes for api calls that are always 'fresh'.

I want to get an idea on how many api calls are made to fastly for a site like this.

So they charge 0.0075 per 10K requests.
= $0.75 per 1m API calls.

So say a given page makes 10 api calls, that is 10 million API calls per 1 million page views.

So the cost would be $7.5 per million page views.

For the 20% of requests that have to hit the origin server, I guess that cost is double since it has to make additional request to the origin server.

Is my math roughly correct? ~ $10 per million page views.

This is a cool hybrid approach when compared to serverless :)

[Salman Ahmed]

Curious, how many and what kind of heroku instances does this puppy need?