3 ms·

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

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 :)

mrkurt 5y ago
Read heavy Rails apps work great multi region: https://fly.io/blog/run-ordinary-rails-apps-globally/ https://fly.io/blog/run-ordinary-rails-apps-globally/ We have a Gem to make it almost transparent: https://github.com/superfly/fly-ruby https://github.com/superfly/fly-ruby
- gingerlime 5y 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...
  - mrkurt 5y 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.
    - gingerlime 5y 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? :)
      - mrkurt 5y 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.

mrkurt 5y ago

Read heavy Rails apps work great multi region: https://fly.io/blog/run-ordinary-rails-apps-globally/ https://fly.io/blog/run-ordinary-rails-apps-globally/ We have a Gem to make it almost transparent: https://github.com/superfly/fly-ruby https://github.com/superfly/fly-ruby

gingerlime 5y 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...
- mrkurt 5y 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.
  - gingerlime 5y 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? :)
    - mrkurt 5y 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.