This gem contains helper code and Rack middleware for deploying Ruby web apps on Fly.io. It's designed to speed up apps by using region-local Postgresql replicas for database reads. See the blog post for more details:
https://fly.io/blog/run-ordinary-rails-apps-globally
Fly's cross-region private networking makes it easy to run database replicas alongside your app instances in multiple regions. These replicas can be used for faster reads and application performance.
Writes, however, will be slow if performed across regions. Fly allows web apps to specify that a request be replayed, at the routing layer, in another region.
This gem includes Rack middleware to automatically route such requests to the primary region. It's designed should work with any Rack-compatible Ruby framework.
Currently, it does this by:
- modifying the
DATABASE_URL
to point apps to their local regional replica - replaying non-idempotent (post/put/patch/delete) requests in the primary region
- catching Postgresql exceptions caused by writes to a read-only replica, and asking for these requests to be replayed in the primary region
- replaying all requests within a time threshold after a write, to avoid users seeing their own stale data due to replication lag
You should have setup a postgres cluster on Fly. Then:
- ensure that your Postgresql and application regions match up
- ensure that no backup regions are assigned to your application
- attach the Postgres cluster to your application with
fly postgres attach
Finally, set the PRIMARY_REGION
environment variable in your app fly.toml
to match the primary database region.
Add to your Gemfile and bundle install
:
gem "fly-ruby"
If you're on Rails, the middleware will insert itself automatically, and attempt to reconnect the database.
Most values used by this middleware are configurable. On Rails, this might go in an initializer like config/initializers/fly.rb
Fly.configure do |c|
c.replay_threshold_in_seconds = 10
end
See the source code for defaults and available configuration options.
This middleware send all requests to the primary if you do something like update a user's database session on every GET request.
If your replica becomes writeable for some reason, your cluster may get out of sync.
Here are some ideas for improving this gem.
- Add a helper to invoke ActiveJob, and possibly AR read/write split support, to send GET-originated writes to the primary database in the background