0

In my Rails app, after executing some code I want to send Slack messages to users to notify them of the execution result. There are multiple processes for which I want to send these messages, and in short, I need somewhere to store message templates for successes/errors (they're just short strings, like "Hi, we've successfully done x!", but they differ for each process).

Right now, I have a SlackMessage model in the DB from which you can retrieve the message content. However, I heard that it's better to manage custom messages like this in a yml file, since it's easier to add/edit the messages later on (like this, even though this is for locales).

What is the best practice for this kind of scenario? If it's not to use a DB, I appreciate if you could give pointers or a link on how to do it (in terms of using yml files, the only material I could find was on internationalisation).

reesaspieces
  • 1,600
  • 4
  • 18
  • 47
  • it depends on a few things, but generally storing in yml is better, i think. It s faster and easier to maintain. – Nodir Rashidov May 13 '19 at 03:45
  • I have seen i18n files in [YAML](https://yaml.org/spec/1.2/spec.html) but never in [YML](https://fdik.org/yml/) and they are not the same. – Anthon May 13 '19 at 04:42

2 Answers2

2

Why don't you use the already existing I18n module in Rails? This is perfect for storing messages, and gives you the ability to use translations would you ever need them in the future.

Getting a message is simple:

Slack.message(I18n.t(:slack_message, scope:'slack'))

In this case you need a translation file like this:

en:
  slack:
    slack_message: This is the message you are going to select.

Read more on I18n: https://guides.rubyonrails.org/i18n.html

bo-oz
  • 2,842
  • 2
  • 24
  • 44
0

YAML is generally much slower than a DB to load data from. Additionally YAML parsers load all of the data usually even if there are multiple documents in the YAML stream.

For programs that have a long run-time and use a large part of the messages, it is usually not a problem to use YAML. But on short running programs the loading can be a significant part of the run-time and techniques like delaying the loading and caching might not help. As an example: I got a PR for my YAML library some time ago, that delayed the instantiation of regular expressions in the library, as that delayed the startup of some programs.

If you have many messages, they all stay in memory after loading from YAML, that might be a problem. With a DB it is much more common to only retrieve what is needed, and rely on the DB to do that efficiently (caching, etc).

If the above mentioned advantages and criteria don't help you decide, you can also have it both ways: by having the ease of reading/editing of YAML and the speed, caching, etc. of a DB. "Just" convert the YAML stream to a DB, either explicitly after editing the YAML document or on first use by your program (by looking at the files date-time-stamps). That is approach that programs like postfix use relying on postmap (although the inputs are text, but not YAML files).

Anthon
  • 69,918
  • 32
  • 186
  • 246