There are an incredible number of websites that have incredible read:write ratios. I would suggest doing everything you can to avoid writing to the database on every request.
Not many. I worked on Ars Technica back in the day, it's the most CDN-like workload you can imagine. We couldn't ship features we thought were valuable, though, because the CDN was in the way.
CDNs have gotten better, and you can write an app in JavaScript to sit in front of your Rails app to make things more dynamic if you want. I believe most devs are better off running their fullstack app where they need it and skipping the additional infrastructure layer.
CDNs are an architectural misfeature that only exist because Fly.io wasn't around 20 years ago. I'm being extreme, but I think that's fundamentally true. ;)
> CDNs are an architectural misfeature that only exist because Fly.io wasn't around 20 years ago. I'm being extreme, but I think that's fundamentally true. ;)
Spicy take :) Although building for a dynamic CDN (I'm thinking Varnish here) feels like building inside-out, I can't see a way to deliver pageviews as efficiently (in terms of CPU or Watts per view) without using a CDN and a lot of caching.
With Fly I guess you flip the architecture around and run code but cache a lot of partials that you assemble together. Nicer than working with ESI and its "cache it all but punch holes in the page and render those bits again" approach, but does the efficiency hold up?
My architectural misfeature would be ESI [1,2]. So useful and so painful to use. And that's before we get to varying support in different proxies and caches...
It is a spicy take. I agree that Varnish and commodity CDNs are more efficient per pageview than hitting any kind of full stack app process. Most devs can probably ignore efficiency, though. Making things fast for users will take them a long way.
My spicy take is really "in the context of full stack apps". CDNs are amazing for, like, Netflix. And Wikipedia. They're really, really good for one to many files.
With Fly, you do flip it around. And you might find out you don't really even need a cache. Rails + Postgres read replicas are pretty dang fast with one less moving piece. We have an awful lot of users who just do in process caching and hit their DB when they need to, it's pretty cool.
ESI seemed so promising when I first read about it. Then I realized I couldn't actually _use_ it anywhere. I'm still kind of aggravated at how excited it made me.
I am currently finding Rails view generation to be shockingly slow. (no DB query involved, just the view generation computation). I guess I do too many complicated things in my view generation.
(But one thing I don't currently do that has always looked shockingly slow when I've measured it, is Rails i18n. But in general, I'm kind of surprised to find you saying Rails view generation is pretty dang fast! It's always seemed to me like the Rails answer was "yeah, we know, that's why you cache." But now I wonder what I'm doing terribly wrong...)
> I am currently finding Rails view generation to be shockingly slow.
I haven't checked this in a few years, but the last time I looked each `render` call reads the partial off disk, parses it, and executes it.[0] So the common pattern of looping over a collection of objects and rendering a partial for each one is going to hurt a lot. And of course Rails makes tons of allocations, so often you'll see one of those iterations take x00ms as Ruby does some garbage collection.
Rails view generation is shockingly slow. I would definitely cache partials, I just wouldn't run Redis to do it if I could help it!
Rails is basically the worst case framework for our model, so we were excited when we got it working. You still have to work hard to make Rails fast, we just give you the last mile for almost-free.
Rails very slow view rendering is one of the worst parts of it. GitHub's view_components library has some performance improvements that can be substantial in some cases. I wish someone would port how Elixir Phoenix does views, which is extremely fast.
ESI, at least on fastly, are run in serialized fashion. On cloudflare workers, you can have up to 6 concurrent connections to try to do ESI as fast as the slowest request.
I agree that Ars Technica seems like a very CDN-friendly workload. I'm curious what those features were that you couldn't ship because of the CDN. It's gotta just be ads, right?
No, the opposite actually. When the ad market fell apart we launched a paid subscriber program. It immediately turned us into an app that cared about a smaller number of high value users. Almost everything we wanted to add was for those folks - personalization and collaboration features, mostly.
There are good reasons to do it independent of simple ratio; for example, if you want the site to function as much as possible with a read-only database - not uncommon in recovery, failover or big migration situations.