Rails Configuration and Environments

I'm currently working through The Rails 7 Way and thought I'd share my notes chapter by chapter. This post is all about Rails configuration and environments — the stuff that makes your app behave differently in development, test, and production.

What Are Rails Environments?

Rails has three default environments: development, test, and production. We have this because we can set the database and custom settings for each environment according to the requirement. We can set the corresponding environment settings in the config/environments folder example development.rb.

For example, in development, we need to reload everything according to the code change, but in production, we can cache classes and assets and use them to make requests faster. We can create our own Rails env also a common one is staging, we can check the current Rails environment in the Rails console:
Rails.env
To run a command in a specific environment:
RAILS_ENV=production rails server.

🗂️ Now let’s break down Configuration Files:

• config/application.rb - This is where global settings for your application are defined as we can set things that can be applied to all ENV in Rails, though we can overwrite this with ENV-specific files. Also, It loads Rails and all its components (ActiveRecord, ActionController, etc.).You can customize this to load only what you need (e.g., skipping ActiveStorage if you don’t use file uploads).

• config/environments/*.rb - contains environment-specific settings for your Rails app. Rails has three by default: development.rb, test.rb, and production.rb. These files override or add to the global settings from the application.rb to suit each environment’s needs—like enabling code reloading in development or caching in production.

• config/initializers/ - is where you put Ruby files that run when your Rails app starts. It's used to set up gem configs, constants, or custom app settings that should load once at boot. Rails automatically loads all files in this folder during initialization.

🔧 Environment-Specific Settings

• config.consider_all_requests_local = true # Setting consider_all_requests_local to true causes Rails to display those developer-friendly error screens

• config.server_timing = true # The Server-Timing specification defines how the server can communicate performance metrics to browsers about its response, especially when using Chrome dev tools that include the Network Inspector metrics.

• 🔁 Automatic Class Reloading

  • config.cache_classes = false #when the config.cache_classes setting is false, if the web server is running and application files have been modified, Rails unloads all autoloaded constants before processing the next request.

  • config.enable_reloading = true # It watches for changes and reloads the file if changes happen available in Rails 7

• ⚡ Caching in Development

  • Caching # We don’t want to cache in development mode unless it's for testing cashing as per rails 7 we only cache if tmp/caching-dev.txt exists. (in the older versions we just had a true or false option)

• 📧 ActionMailer Error Handling

  • config.action_mailer.raise_delivery_errors = false # Rails assumes that you don’t want Action Mailer to raise delivery exceptions in development mode, so based on the config.action_mailer.raise_delivery_errors settings, it will swallow those exceptions

• 🐢 Lazy vs Eager Loading

  • config.eager_load = false # To speed up the boot time of starting a Rails server during development, your project code and libraries are not eager loaded into memory. Instead, they are loaded on an as-needed basis (aka “lazy-loading”). In your production environment, this is set to true.

• ⚠️ Deprecation Warnings

  • config.active_support.deprecation = :log #The configuration setting config.active_support.deprecation enables you to set how you would like to receive deprecation warnings

    1. You can configure deprecation warnings that the Application considers disallowed. This way, you can treat specific deprecations as hard failures:

       1. # Raise exceptions for disallowed deprecations. config.active_support.disallowed_deprecation = :raise

       2. # Tell Active Support which deprecation messages to disallow. config.active_support.disallowed_deprecation_warnings = []

📦 Gemfile and Gemfile.lock

• When we create a new rails application using rails new we trigger a bundle Install automatically, which causes a Gemfile.lock to be created.

• The Gemfile.lock freezes the versions of gems that are used so all machines can use the same version, otherwise, different machines will get different versions which might cause an issue

• If Gemfile.lock is deleted or not there then it will refetch the latest gem version and create a new gemlock.

• If we re-run the bundle Install without changing anything in gemfile it will just use the gemfile lock version to fetch again.

• Only specify the version of the gem in the Gemfile if u want to use a specific old version.

• Even the rails version is mentioned in the Gemfile

🔤 Inflections

• Rails has built-in rules for pluralizing and singularizing words, like turning post into posts. But sometimes, especially with irregular words, you need to define your own rules. That’s where config/initializers/inflections.rb comes in. You can add custom inflection rules here so Rails handles naming more accurately across your app.

📝 Final Thoughts

That’s my understanding of Rails configuration and environments so far. As I keep reading The Rails 7 Way, I’ll be posting more chapters with my takeaways.