Hacker News new | ask | show | jobs
by gingerlime 1615 days ago
What kind of Rails apps run without a DB? or how can you scale your app with a DB across 10+ regions?

Would love to understand better how to deploy Rails with fly and still benefit from multi-region/failover/scaling

p.s. horrible nitpick, but I think it’s SECRET_KEY_BASE :)
1 comments
mrkurt 1615 days ago
Read heavy Rails apps work great multi region: https://fly.io/blog/run-ordinary-rails-apps-globally/

We have a Gem to make it almost transparent: https://github.com/superfly/fly-ruby

link
gingerlime 1614 days ago
It's an interesting idea to assume GETs will do no writes, as opposed to POST/PUT/DELETE and route them via middleware, but as an app developer, you need to be very mindful of any updates I suppose... replication delay can also create some weird scenarios I imagine...
link
mrkurt 1614 days ago
That's all solved. We catch readonly errors from Postgres and issue the replay. Preemptively sending a POST to the primary region is an optimization, it works fine without doing that!

Replication lag is handled too in the Ruby library we pin requests to the for a few seconds. In our Elixir library, we actually monitor the read replica directly and reroute writes until it's caught up.

link
gingerlime 1614 days ago
I understand roughly what the gem does, but you still need to be aware of it with your app. For example, if every request updates some activity stat, or the last page the user was on (which happens with some apps), you instantly lose pretty much all the benefits, right?

What about redis / sidekiq btw? :)

link
mrkurt 1614 days ago
Ah I see what you're saying! You're basically describing our experience trying to run Discourse. Weirdly, naive, less complicated Rails apps work better multi-region on Fly than mature grownup Rails apps.

We use sidekiq + Fly in a single region with the primary database, and then write to the Redis from other regions asynchronously. It's a good time in Ruby world, I think Ruby 3 will simplify a lot of the weird background work people do.

Ruby 3 will definitely help us solve the problem of gets that do writes for stats or history, since those things can be done async. You can do a little of it now just by spawning a thread and writing the the writable Postgres in the background.

link