Mathieu
Mathieu

Reputation: 4787

Rails 4.2 constants - where to put them: application.yml vs custom config file.rb

I have some constants I am using throughout my app. I'd say there are three types:

  1. some are really passwords to external stuff like sendgrid login/password

  2. some are internal "secret codes" like devise secret key

  3. some are just what I'd call global constants that is to say there are constants that we use a lot throughout the app and don't want anybody to easily change this. They nearly never change. Some examples: the ID of our facebook page, or the number of deals "per page" we define in our infinite scrolling on the homepage (critical for UX), or the url of our brand-validated logo on aws cdn(present in many view files html.erb and assets javascript .js files). One aspect I also have in mind when asking my question, is that even if they seem less critical than a devise key, for those constants, I would like to gather, to make sure very few people and only authorized developers can change those critical data.

Here's what we do today:

then it is called in a controller this way:

nb_per_page = Rails.configuration.x.infite_scrollhp_feed_per_page_deals

But each time I am unsure if I should put global constants inside config/application.yml or in my custom config .rb file?

What is the recommended "Rails -way"? How to decide where to put them ? Is there a generally accepted "good-sense"/"proven to be efficient/well-structuring" practice/rule ?

Also is there a different in performance that is to say are application.yml "injected" faster into view (.html) and assets(.js) files when user load a page than if they are defined on my custom config file ?

Upvotes: 2

Views: 1001

Answers (1)

maicher
maicher

Reputation: 2745

I would advise using config/secrets.yml for sensitive data (1 and 2):

  development:
    some_password: ...

  test:
    some_password: ...

  production:
    some_password: <%= ENV["SOME_PASSWORD"] %>

This way you can put different settings for different environments (for development, test and production). And I would highly recommend keeping the production sensitive data in ENV variables.

When it goes for non sensitive data (3) I would put in config/environments/*.rb files when different settings are needed for different environments. If that's not the case and the setting is the same for all environments, I would put it into application.rb, application.yml or in a custom file in initializers/* or even as class constants.

Upvotes: 1

Related Questions