One of the improvements we are working on is the possibility of sending notifications to multiple services, like e-mail, Slack, push notifications to mobile apps…

That functionality make us face with the problem of using different strategies depending on a concrete scenario that can be different for each user we want to notify, so we decided to develop a library that help us to manage all that cases. And we called it Ravenx.

How Ravenx works

The library is made of strategies, which define a way of sending a notification (Slack, e-mail, APNS, etc), and they have an standard interface, so its internal behaviour is abstracted from the outside.

Currently, Ravenx has two different strategies:

• Slack: provides sending slack messages using webhooks URLs.
• E-mail: provides sending emails using different strategies (the ones included in bamboo).

But, as we are going to see at the end of this article, new strategies can be easily implemented to manage sending notifications to other systems and platforms.

Also, there are several ways of defining configurations which the strategies will use to know how to send the notification.

Configurations are per strategy, so they defines how a notification is sent (for example, Mailgun’s configuration to send e-mails).

Global configuration

This approach includes two kinds of configuration:

• General Ravenx configuration: like the custom strategies to use, or the configuration module of our app (we will see this two aspects in a few moments).
• Per-strategy configuration: strategy-specific configuration (Mailgun’s config, Slack’s webhook URL…)

config :ravenx, :slack,
  url: "...",
  icon: ":bird:"

Configuration module

A module that have a function for each strategy that receives the payload and returns a map with configurations that apply to that specific payload.

These configuration modules are useful to automatise the configuration generation, for example, if we need to retrieve the slack username of each user in each notification.

config :ravenx,
  config: YourApp.RavenxConfig

defmodule YourApp.RavenxConfig do
  def slack (_payload) do
    %{
      url: "...",
      icon: ":bird:"
    }
  end
end

Particular configuration

This is a configuration map sent when a notification is dispatched. Useful to add configuration generated right before sending the notification.

Ravenx.dispatch(strategy, payload, %{url: "...", icon: ":bird:"})

Mixing configurations

For a given notification dispatch we can have configurations of the three kinds. In that case, configurations are merged with this priorities:

Global < Module < Particular

So a particular configuration key is used even if it’s defined in the configuration returned by a configuration module or by the app configuration.

Sending a notification

Ravenx allows to send a notification in a synchronous or asynchronous way. In case you want to send a notification in an asynchronous way, a Task will be launched to perform the operation under the hood.

To send a notification, the only action needed is a call to the library:

Ravenx.dispatch(:slack, %{title: "Hello world!", body: "Science is cool"})
# => {:ok, "ok"}

Ravenx.dispatch(:wadus, %{title: "Hello world!", body: "Science is cool"})
# => {:error, {:unknown_strategy, :wadus}}

{status, task} = Ravenx.dispatch_async(:slack, %{title: "Hello world!", body: "Science is cool"})
# => {:ok, %Task{owner: #PID<0.165.0>, pid: #PID<0.183.0>, ref: #Reference<0.0.4.418>}}

Task.await(task)
# => {:ok, "ok"}

Ravenx.dispatch_async(:wadus, %{title: "Hello world!", body: "Science is cool"})
# => {:error, {:unknown_strategy, :wadus}}

Sending multiple notifications

Sending a standalone notification is cool, but no one needs another library for that. The true functionality in Ravenx is sending a notification using multiple strategies in an easy way.

To do that, the library defines a macro that can be used to generate notification modules, which can be used to define how to send a particular notification using multiple strategies.

That modules must define a function called get_notifications_config that receives an object and returns a Keyword list with information of which strategies and which payloads will be used:

YourApp.Notification.NotifyUser.dispatch(user)
# => [
#   slack: {:ok, ...},
#   email_user: {:ok, ...},
#   email_company: {:ok, ...},
#   other_notification: {:error, {:unknown_strategy, :invalid_strategy}}
# ]

YourApp.Notification.NotifyUser.dispatch_async(user)
# => [
#   slack: {:ok, %Task{..}},
#   email_user: {:ok, %Task{..}},
#   email_company: {:ok, %Task{..}},
#   other_notification: {:error, {:unknown_strategy, :invalid_strategy}}
# ]

defmodule YourApp.Notification.NotifyUser do
  use Ravenx.Notification

  def get_notifications_config(user) do
    # In this function you can generate your payloads and decid which strategies you
    # want to use depending on the obejct received, and return something like:
    [
      slack: {:slack, %{title: "Important notification!", body: "Wait..."}, %{channel: user.slack_username}},
      email_user: {:email, %{subject: "Important notification!", html_body: "<h1>Wait...</h1>", to: user.email_address}},
      email_company: {:email, %{subject: "Important notification about an user!", html_body: "<h1>Wait...</h1>", to: user.company.email_address}},
      other_notification: {:invalid_strategy, %{text: "Important notification!"}, %{option1: value2}},
    ]
  end
end

So that allows to define all the logic behind a notification generation in a particular module.

That modules can be used (as seen above) to dispatch the notifications in both synchronous and asynchronous way, as when we dispatched simple notifications.

Custom strategies

Anyone can create custom strategies and integrate them with Ravenx. To do that, the only requirement is to implement the interface needed and tell Ravenx which modules should use as strategies:

config :ravenx,
  strategies: [
    my_strategy: YourApp.MyStrategy
  ]

defmodule YourApp.MyStrategy do
  @behaviour Ravenx.StrategyBehaviour

  def call(payload, options) do
    # ... do stuff ...
  end
end

What Ravenx doesn’t do

Ravenx doesn’t take care of dispatching schedule (limiting the amount of notifications sent simultaneously). As Erlang VM can virtually take care of a lot (really, a lot) of internal processes, this is not a real issue.

You can send a lot of notifications asynchronously and the Erlang VM will be able to manage them without much problem.

Wrapping up

Ravenx is not the perfect solution for all the notification scenarios (and it is not intended to be that), but in Acutario we think this can solve some complex scenarios in which you can have to deal with changing configurations, multiple strategies and massive dispatches of notifications.

Using notification modules alongside with the configuration options, the code related to notifications can be organised and reused, avoiding repetitions in multiple places of your code.

If you have any question about Ravenx, you can read its documentation here, ask any question here or just open an issue! (Pull requests are welcome too :)

Hope you enjoyed this article and see you soon (in ElixirConf.EU if you assist!)

Getting in touch with CircleCI

CircleCI is just another continuous integration platform, free for both public and private repositories.

The main advantage is that, as it’s based on top of containers, you can can access via SSH to the container where your tests are running and debug environment/build issues easily.

So, what’s the matter with Elixir in CircleCI?

CircleCI doesn’t have native support for Elixir/Phoenix projects, so the only option left is trying to automatise the installation of the environment needed to run the tests.

This shouldn’t be a real trouble since they allow you to define the shell commands executed at each step, so the process can be customised as much as you want.

In my case, I have decided to install the environment using ASDF, a new lightweight version manager that can handle multiple languages/platforms using plugins.

The idea is to install it (if it’s not previously installed) and apply the plugins needed. Then, we can use .tool_versions file (the default one used by ASDF) to install required dependencies and use them to run the actual tests.

So here is the circle.yml that does it:

machine:
  environment:
    PATH: "$HOME/.asdf/bin:$HOME/.asdf/shims:$PATH"
    MIX_ENV: "test"
dependencies:
  cache_directories:
    - ~/.asdf
  pre:
    - if ! asdf | grep version; then git clone https://github.com/HashNuke/asdf.git ~/.asdf; fi
    - if ! asdf plugin-list | grep erlang; then asdf plugin-add erlang https://github.com/HashNuke/asdf-erlang.git; fi
    - if ! asdf plugin-list | grep elixir; then asdf plugin-add elixir https://github.com/HashNuke/asdf-elixir.git; fi
    - asdf plugin-update erlang
    - asdf plugin-update elixir
    - asdf install
    - cp config/test.ci.exs config/test.exs
    - yes | mix deps.get
    - yes | mix local.rebar
database:
  override:
    - mix ecto.drop
    - mix ecto.create
    - mix ecto.migrate
test:
  override:
    - mix test
experimental:
  notify:
    branches:
      only:
        - master

Also, some adjustments are made:

• Various environment variables, like the $PATH including ASDF paths
• Copying CircleCI specific project config to use it on tests
• Install required dependencies
• Clean the database
• Only notify the builds on master branch (to avoid flooding of notifications on non-master commits).

Note that, by adding ASDF directory to the cache list, we can avoid reinstalling and rebuilding Erlang and Elixir, which will take (really) long time on first execution.

Benchmarking

Thanks to the cache between builds, the build times of one of the projects we use at work are:

• ~3 minutes on regular builds.
• ~13 minutes on the first build (download and build Erlang & Elixir).

• Having access to local services on your local network , like a (in my case) a Time Machine docker service.
• Access services only available from your country IP when travelling to other places.
• Being able to use open hotspots while encrypting your whole network traffic.

In order to get it, my first thought was to install the server on the bare metal machine (not on a Docker container) because it may require some network privileges that can make it unable to work behind the Docker network layer.

But searching a bit over the Internet I’ve found this repository that includes a functional Docker image. It doesn’t just works, but it includes a full documentation file with instructions to set the server up in two different containers (the one that has the daemon running and the one that stores the secure data).

So, in less that 5 minutes my OpenVPN server was up and running! Also I have generated the CA file and the client certificates, so I can connect from anywhere like being at home.

Clients

In Mac OSX (10.11 — El Capitán) I installed Tunnelblick, a free and open source alternative to OpenVPN client or Viscoso.app. It has an easy and lightweight GUI, perfect to avoid resource consumption and annoyance while using it.

In Windows 10 I used the official OpenVPN client, but it doesn’t work out-of-the-box. To make it work, its executables should be marked to be run with administrator privileges, so they can add the networking routes needed to route the traffic through the VPN.