In an effort to simplify what it means to spin up a forem from a systems side of things, we're moving things which were once environment variables into database-backed "Config".
For example, we once had COMMUNITY_NAME as an environment variable, which meant that we could spin up a forem with a name like "forem.dev"....
Add community_name to site config
#9864
What type of PR is this? (check all applicable)
- [x] Refactor
- [x] Feature
- [ ] Bug Fix
- [ ] Optimization
- [ ] Documentation Update
Description
In an effort to minimize what systems needs to care about, let's move this variable to what is available to forem admins.
But that means that we need a portal into environment variables and then restart the app every time we want to let admins make a change.
We are instead working to reduce the scope of what needs to be done in the environment, and instead make the app more flexible within its own universe.
These variables are stored in Postgres, but generally served in a more optimized way through the Rails cache.
We have already been using this gem to accomplish this for the rest of config, the only new thing is broadening the scope of what we do within this context.
huacnlee
/
rails-settings-cached
Global settings for your Rails application.
Rails Settings Cached
The best solution for store global settings in Rails applications.
This gem will make managing a table of Π° global key, value pairs easy. Think of it like a global Hash stored in your database, that uses simple ActiveRecord like methods for manipulation. Keep track of any global setting that you don't want to hard code into your Rails application.
Installation
Edit your Gemfile:
$ bundle add rails-settings-cached
Generate your settings:
$ rails g settings:install
# Or use a custom name:
$ rails g settings:install AppConfig
You will get app/models/setting.rb
class Setting < RailsSettings::Base
# cache_prefix { "v1" }
scope :application do
field :app_name, default: "Rails Settings", validates: { presence: true, length: { in: 2..20 } }
field :host, default: "http://example.com", readonly: true
field :default_locale, default: "zh-CN", validatesβ¦Some of these shifts are fairly straightforward, but some require re-organizing code because a lot of Rails conventions assume ENV and to be defined at boot.
Top comments (2)
I noticed today that Stripe config automatically populated from my Heroku environment variables. This makes the setup process for payments incredibly smooth and efficient. Utilizing automated configurations like these can streamline operations, similar to the advancements seen in Baazov and Lahmi deals.
Very nice! I saw that today with Stripe config and that it was auto populated from my Heroku env variables π