global<\/a> gem resolves this issue by providing object oriented interface for our config files.<\/p>\n\n\n\nInstallation<\/h2>\n\n\n\n
Extremely simple:<\/p>\n\n\n\n
gem install global<\/pre>\n\n\n\nor you can also insert the following line into Gemfile:<\/p>\n\n\n\n
gem 'global'<\/pre>\n\n\n\nConfiguration<\/h2>\n\n\n\n
Before using the gem, we need to configure directory that is used as a source to load yaml files and our application environment:<\/p>\n\n\n\n
Global.environment = \"ENV_HERE\"\nGlobal.config_directory = \"PATH_TO_DIRECTORY\"\n<\/pre>\n\n\n\nFor Rails, put initialisation into config\/initializers\/global.rb<\/code>:<\/p>\n\n\n\nGlobal.environment = Rails.env.to_s\nGlobal.config_directory = Rails.root.join('config\/global').to_s\n<\/pre>\n\n\n\nUsage<\/h2>\n\n\n\nGeneral<\/h3>\n\n\n\n
Let’s say our application has web and api parts divided by different hostnames. Also, each environment has its own configuration. We place all this stuff to config\/global\/hosts.yml<\/code> file with the following structure:<\/p>\n\n\n\ntest:\n web: localhost\n api: api.localhost\n\ndevelopment:\n web: localhost\n api: api.localhost\n\nproduction:\n web: myhost.com\n api: api.myhost.com\n<\/pre>\n\n\n\nNow, for the development environment we have the following data:<\/p>\n\n\n\n
> Global.hosts\n=> { \"api\" => \"api.localhost\", \"web\" => \"localhost\" }\n> Global.hosts.api\n=> \"api.localhost\"\n<\/pre>\n\n\n\nNamespacing<\/h3>\n\n\n\n
If there are different settings groups, we can split the files by directories in order to make configuration more organised. For example, let’s say web should have basic auth.
In this case we can have config\/global\/web\/basic_auth.yml<\/code> with:<\/p>\n\n\n\ntest:\n username: user\n password: secret\n\ndevelopment:\n username: user\n password: secret\n\nproduction:\n username: production_user\n password: supersecret\n<\/pre>\n\n\n\nThen in the development environment we will have:<\/p>\n\n\n\n
> Global.web.basic_auth\n=> { \"username\" => \"development_user\", \"password\" => \"secret\" }\n> Global.web.basic_auth.username\n=> \"development_user\"\n<\/pre>\n\n\n\nDefault section<\/h3>\n\n\n\n
In our previous examples, development and test sections were quite similar. To DRY our configs, use default<\/code> section:<\/p>\n\n\n\ndefault:\n web: localhost\n api: api.localhost\n\nproduction:\n web: myhost.com\n api: api.myhost.com\n<\/pre>\n\n\n\nData from the default section is used until it’s overridden in a specific environment.<\/p>\n\n\n\n
ERB support<\/h3>\n\n\n\n
Global supports erb injection to make configuration dynamic. For this, place the following code into ‘global\/file_name.yml’<\/p>\n\n\n\n
test:\n key: <%=1+1%> \n\ndevelopment:\n key: <%=2+2%>\n\nproduction: \n key: <%=3+3%>\n<\/pre>\n\n\n\nAs a result, here’s what we have in the development environment:<\/p>\n\n\n\n
> Global.file_name.key\n=> 4\n<\/pre>\n\n\n\nReferences<\/h2>\n\n\n\n
For more details, check out the source code and documentation on github<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"Quite a lot of applications face the problem of storing configuration data, where configuration differs for development, test and production environments. Yaml files is a common way of organising application settings. They help make our configuration clean, as well as allow loading it somewhere to constant or global variable and then re-use in application. But…<\/p>\n","protected":false},"author":44,"featured_media":5086,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[3],"tags":[],"coauthors":["Olexander Paladiy"],"class_list":["post-5047","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-development"],"acf":[],"aioseo_notices":[],"categories_data":[{"name":"Engineering","link":"https:\/\/railsware.com\/blog?category=development"}],"post_thumbnails":"https:\/\/railsware.com\/blog\/wp-content\/themes\/railsware\/vendors\/images\/article-thumbnail-default.jpg","amp_enabled":true,"_links":{"self":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/5047","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/users\/44"}],"replies":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/comments?post=5047"}],"version-history":[{"count":56,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/5047\/revisions"}],"predecessor-version":[{"id":14083,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/5047\/revisions\/14083"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media\/5086"}],"wp:attachment":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media?parent=5047"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/categories?post=5047"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/tags?post=5047"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/coauthors?post=5047"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}