Today, I am proposing a very simple tutorial. I needed to integrate a Metabase dashboard in one of my applications and I realized there is no article which explains how to do that. So, ta-da!

Requirements

To follow this tutorial, you will need

• a Metabase dashboard (read this article from my fellow Laurent Dogin to have yours set up in a few minutes)
• a Ruby on Rails application (read this article by me if you need to set up one)

Enabling integration in Metabase

From your Metabase, click on the top right gear icon, then Admin. On the left menu select Embedding in other Applications. Toggle the button to have it saying Enabled. You will now get an Embedding API key. Save it for later.

Leave Metabase admin and select the dashboard you want to integrate. Click the sharing and embedding icon on the top right of your dashboard. Now select Embed this dashboard in an Application. Finally, click on the Publish button.

Integrate Metabase in Rails

In your Gemfile, add gem 'jwt' then run $ bundle install. If your application is deployed on Clever Cloud go to your application's console and under your application's menu go to the environment variables menu. If you deploy locally, use the gem figaro and edit your application.yml. Anyway you must add two environment variables

METABASE_SITE_URL: <your metabase url>
METABASE_SECRET_KEY: <the API key from metabase admin>

In the controller action where you want to integrate your metabase dashboard, add the following lines:

payload = {
          :resource => {:dashboard => <your dashboard number>},
          :params => { },
          :exp => Time.now.to_i + (60 * 10) # 10 minute expiration
    }
token = JWT.encode(payload, ENV["METABASE_SECRET_KEY"])
@iframe_url = ENV["METABASE_SITE_URL"] + "/embed/dashboard/" + token + "#bordered=true&titled=true"

Now in your view, add

<iframe
    src="<%= @iframe_url %>"
    frameborder="0"
    width="800"
    height="600"
    allowtransparency
></iframe>

You are all set. Just restart your application so the new environment variables are taken in consideration. Voilà, your application now has an integrated Metabase dashboard.

Last week, Clever Cloud was part of the Rails Girls event in Nantes. As a company, we think that being involved in tech communities and helping people to be introduced to tech is a good and important thing.

Sponsoring Rails Girls

Last week, we sponsored the latest edition of Rails Girls in Nantes. This series of events, occurring in multiple cities, aims to give tools and a community for women to understand tech and build their ideas.

The RG team is powered by Sarah and Guillaume, two dedicated organizers we would like to thanks for their enthusiasm!

What's next with Clever Cloud

Also, we have several events in the coming weeks. Here 's a bunch of them:

• The Devfest Nantes will host three Clever Cloud speakers:
  • Valeriane Venance: Authentication/Authorization Starters Battle
  • Quentin Adam: Apache Pulsar 101: architecture, concepts & comparaison with Steven LeRoux
  • Hubert Sablonnière: The Web, its frameworks and standards
• Voxxed Microservices: We'll be sponsoring the event, so feel free to see us at our booth !

Fat Models and skinny Controllers right?

You know what they say about the MVC design pattern, keep your Controllers light.
So at the beginning of your project, you added oil and gears to your Models and it was rolling just fine. Even if I'm not a big fan of the big Model that even makes coffee (sending an email, really?), I can say that you were in perfect harmony with the framework principles.
Well, a few iterations later, this idyllic codebase seems very far away and your Controllers and Models are way more '200 line'ish than they used to be.

Service Objects is a good solution to extract some logic out of them by transferring code into simple services that handles only one thing. This way, you end up with maintainable, super understandable and separated critical code.
On this article I'm focusing on Controllers, but the principles are the same for Models. Now, some may ask, why not using Controller Helpers instead?

My answer to that would be: don't choose, use both!

Service object and Controller helper

Controller Helpers do hold code shared between Controllers and are also a good way to keep slim Controllers. They are great to respect the DRY (Don't Repeat Yourself) principles. If you target the same workflows in many Controllers, you must consider putting this logic into a helper. The code you put here is a simple succession of actions you do and conditions you are evaluating. They are useful only if used by at least two Controllers, otherwise, you should think of some code refactoring.
Anyway, we often hear that backend logic should not belong to the Controller and just moving everything into a helper won't solve the problem.

For every operation tied to your business logic (calling an API, calculation) performed in this duplicated code or present in any Controller, you should definitely consider creating a service object for each chunk of logic.

Okay, now you know when to use a service object, but what is it exactly?

A service object is a PORO. No, not that cute fluffy League of Legends NPC, but a Plain Old Ruby Object.
You just create a class not related to ActiveRecord (the RubyOnRails ORM) with it's own methods, put your code there, and WOW, you now have a PORO!
We will see how we construct it later, first we need to know where to put it in our project.

Break it to rebuild it

First, let's take this Controller. One thing we can notice is an API call in this get_weather method and this should not be Controller business.

class HomeController < ApplicationController
    require 'curb'
    def index
    end

    def get_weather
        http = Curl.get("#{ENV["api_base"]}#{ENV["api_key"]}")
        if http.status = "200 OK"
            response_body = JSON.parse http.body_str
            @current_weather = response_body["weather"][0]["description"]
            @current_temperature = "#{(response_body["main"]["temp"].to_f - 273.15).round(1)} °C"
        else
            @current_weather = "There was an error sorry: #{current_weather[:error]}"
        end
    end
end

According to the name of the design pattern, we will create a services folder at root_path/app/services/.
Okay, looks like it's about getting weather informations so we will name another folder accordingly.
Finally, we can create our service object file. For this, we will be the most explicit and we will use something like x_service.rb.

Being precise on naming and using the _service suffix is here to help other code maintainers to easily understand what is the purpose of the service and where to find it in the project.

Skeleton

This is how we should start every new service object. Here, we can note the import of the library "ostruct". This allows us to use the OpenStruct object in order to return a rich object containing error messages and a success? method.

class FolderName::NameOfTheService
    require "ostruct"
    
    def initialize(params={})
        @params = params
    end

    def call
        begin
        rescue => exception
            OpenStruct.new(success?: false,
                           error: exception.message)
        else
            OpenStruct.new(success?: true, 
                           error: nil)
        end
    end

end

Filling it up

Instead of just copying our Controller's code into our private method, we will use the wide known begin/rescue pattern to manage errors and will use it at our advantage to raise our own errors.

class Weather::GetCurrentWeatherService
  require "ostruct"

    def initialize(params={})
      @params = params
    end

    def call
      @api_base = ENV["api_base"]
      @api_key = ENV["api_key"]

      begin
        http = Curl.get("#{@api_base}#{@api_key}")
        if http.status == "200 OK"
          response_body = JSON.parse http.body_str
          if response_body["weather"] && response_body["main"]
            weather_string = response_body["weather"][0]["description"]
            temperature = "#{(response_body["main"]["temp"].to_f - 273.15).round(1)} °C"
          else
            raise
          end
        else
          raise
        end
      rescue => exception
          OpenStruct.new(success?: false,
                 error: exception.message)
        else
          OpenStruct.new(success?: true, 
                 weather_string: weather_string, 
                 temperature: temperature, 
                 error: nil)
        end
    end

end

Let's refactor this Controller

def get_weather
    current_weather = ::Weather::GetCurrentWeatherService.new.call(params: {})
    if current_weather.success?
        @current_weather = current_weather[:weather_string]
        @current_temperature = current_weather[:temperature]
    else
        @current_weather = "There was an error sorry: #{current_weather[:error]}"
    end
end

We simply call a new instance of our service in our Controller and use it's success? method to handle regular Controller rendering logic. Note the use of the prepending :: it's for preventing the Controller to look for the service only in its own repository.
Here, the params argument is just an empty hash that I do not use but this was to show that, like every PORO, a service can take many parameters.

This pattern is so great, but I've made a mess!

If our weather service was real, we would probably want to handle city search, forecast weather and so on. Maybe we would have extended our service object or created a bunch of others and now it's an obscure code to maintain and you can feel like you're drowning. No worries, it's just time for you to be rescued by NameSpacing!

In fact we already used it by putting our service in a weather folder in the first place. You should definitely classify all your new services by folders and never hesitate to create a sub folder when your folder holds too many service files.
If your services can be sliced by fields of usage or are really tied to a Model or Controller, create new folders and move your services under the corresponding ones.

For naming your folders, no master rule, but logic, efficiency, and consistency between the names.
Of course, you will need to rename your services. For instance, under a folder named my_folder/my_folder_2 your my_service will be renamed MyFolder::MyFolder2::MyService and you will now use the same name in your Controllers to use them.

So, SO or not?

As you may have notice, I was mostly giving advices on how to implement it and never refer to the official documentation.
This is because this pattern does not have any convention and everyone can implement it its own way. In order to avoid maintainability issues, I would really recommend keeping these concerns in mind:

• always think concerns separation.
• don't let your services grow big.
• always return rich objects.
• all your return objects should have the same structure.

Happy refactoring!

Prerequisites

Rails local installation

Super fast version

• Deploying ruby on rails application.
• Docs for PostgreSQL add-on.
• Docs for FSBuckets filestystems(optional).
• Docs for the clever-tools CLI.

Step by step version

Get your app ready for production

Database settings

default: &default
  adapter: postgresql
  encoding: unicode
  timeout: 5000

production:
  <<: *default
  database: <%= ENV['POSTGRESQL_ADDON_DB'] %>
  username: <%= ENV['POSTGRESQL_ADDON_USER'] %>
  password: <%= ENV['POSTGRESQL_ADDON_PASSWORD'] %>
  host: <%= ENV['POSTGRESQL_ADDON_HOST'] %>
  port: <%= ENV['POSTGRESQL_ADDON_PORT'] %>

Dependencies settings

# Use sqlite3 as the database for Active Record
gem 'sqlite3', '~> 1.4'

# Use postgresql as the database for Active Record
gem 'pg'

Deployment orchestration settings

{
  "deploy" : {
    "rakegoals": ["db:migrate", "assets:precompile"],
    "static": "/public"
  }
}

Clever Cloud configuration

I don't have an account

I have an account

Creating the application

Database setup

Setting environment variables

SECRET_KEY_BASE

RUBY_VERSION

I need a filesystem

Deploying the application!

The Clever Cloud CLI

$ curl https://clever-tools.cellar.services.clever-cloud.com/releases/latest/clever-tools-latest_linux.tar.gz
$ tar xvzf clever-tools-latest_linux.tar.gz
$ cp clever-tools-latest_linux/clever ~/.local/bin/

I have a filesystem (only if you have followed #I need a filesystem)

Deployment

Happy coding!

My workflow to use Clever Cloud as dev env

• I locally create a git branch with git checkout -b <my_branch_name>, the name evokes the feature I'll be working on.
• I use TDD as coding methodology (on rails I'd suggest you start with FactoryBot and RSpec) so I code all my tests for the feature, then commit them all on my branch.
• I code my feature and create a new commit.
• I can test on production conditions how the modifications behave by pushing my specific branch to master by doing $ git push clever my_branch_name:master (you need to push local commits on your branch before).
• If I'm not satisfied with the changes I can make new changes, add the files to git then $ git commit --amend to add the modifications to the last commit without having to make a new one.

Welcome to this new edition of One Framework a Day keeps the Boredom Away. In this series I will show you how to deploy a particular framework on Clever Cloud every day until I want to go back to boredom. Today it's about Sinatra.

In each post of this series we'll see how to deploy a particular framework on Clever Cloud. Today we are taking a look at Sinatra.

If you want to tag along, make sure you have git, a Clever Cloud account and that you have installed our CLI Clever-Tools.

What is Sinatra?

Sinatra is a DSL for quickly creating web applications in Ruby with minimal effort

It's been around for 10 years now and has already inspired several other framework since then. Ratpack which was showcased last week has been heavily inspired by sinatra for instance. Our own Keruspe wanted to play with a couple of Ruby technologies like Puma and Sinatra. And so he built a sample project for it. That's what we are going to deploy today.

Setup

• Start by cloning the sources: git clone https://github.com/CleverCloud/demo-sinatra-puma-activerecord
• Create the database you want to use, in my case Postgres: clever addon create postgresql-addon --plan dev --region eu sinatraPG
• Create the Ruby application on Clever Cloud: clever create --type ruby sinatraSample --region par
• Link the Postgres add-on to the application: clever service link-addon sinatraPG
• Tell Clever Cloud to deploy the API using puma (the default is uwsgi as of now): clever env set CC_RACKUP_SERVER puma
• Tell Clever Cloud to run database migrations before launching the API:clever env set CC_PRE_RUN_HOOK 'bundle exec rake db:migrate'
• Add a domain name: clever domain add mySinatraSample.cleverapps.io

Specify the maximum number of PG connections your application will use (depending on the selected plan) by adding an environment variable like DB_POOL=5 if you want to use 5 connections. For production, you should also set:

clever env set RACK_ENV production
clever env set RAILS_ENV production

Deploy

• Deploy the application with clever deploy

And you are up and running. This application provides an API to store users. They only have a name field. Users can be created with a POST request and retrieve with a GET request like so:

• Create an object with curl --data "regis" https://mySinatraSample.cleverapps.io
• Retrieve that object with curl https://mySinatraSample.cleverapps.io/regis

Everything works out of the box because this application has been written for Clever Cloud. If you take a look at the condfiguration file under ./config/database.yml you should see some environment variables being used. They are the one provided by our Postgres add-on. You can get the full list of variables with clever env.

Let us know your thoughts on this in the comments below. We will be back tomorrow for another post :)

What is Ruby on Rails?

Ruby on Rails, or simply Rails, is a server-side web application framework written in Ruby under the MIT License. Rails is a model–view–controller framework, providing default structures for a database, a web service, and web pages.

Setup

• Start by cloning the sources, here I am checking out the latest stable branch: git clone https://github.com/edavis10/redmine/ --branch 3.4-stable
• Create the database you want to use, in my case Postgres: clever addon create postgresql-addon --plan dev --region eu redminePG
• Create a FS Bucket: clever addon create fs-bucket --plan s --region eu redmineFS
• Create the Ruby application on Clever Cloud: clever create --type ruby redmine --region par
• Link the Postgres add-on to the application: clever service link-addon redminePG
• Link the FS Bucket add-on to the application: clever service link-addon redmineFS

production:
  adapter: postgresql
  database: <%= ENV["POSTGRESQL_ADDON_DB"] %>
  host: <%= ENV["POSTGRESQL_ADDON_HOST"] %>
  username: <%= ENV["POSTGRESQL_ADDON_USER"] %>
  port: <%= ENV["POSTGRESQL_ADDON_PORT"] %>
  password: <%= ENV["POSTGRESQL_ADDON_PASSWORD"] %>
  encoding: utf8

• Define a new global secret in config/secrets.yml: touch config/secrets.yml

  production:
    secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
  

• Define all the other configuration variables under config/configuration.yml: touch config/configuration.yml

  production:
    attachments_storage_path: <%= ENV["APP_HOME"] %><%= ENV["ATTACHMENTS_STORAGE_PATH"] %>
  

• Set the Ruby version: clever env set RUBY_VERSION 2.3.1
• Setup the Rails environment to use the production configuration: clever env set RAILS_ENV production
• Use en as language: clever env set REDMINE_LANG en
• Use a newly generated secret: clever env set SECRET_KEY_BASE `./bin/rake secret`
• Setup where to write files: clever env set ATTACHMENTS_STORAGE_PATH /data/attachments
• Define where to mount our FS Bucket:clever env set CC_FS_BUCKET /data:`clever env | awk -F = '/BUCKET_HOST/ { print $2}'`

[ -d tmp ] || mkdir tmp
[ -d tmp/pdf ] || mkdir tmp/pdf
[ -d data/plugin_assets ] || mkdir data/plugin_assets
[ -d tmp/pdf ] || mkdir tmp/pdf
[ -d data/attachments ] || mkdir data/attachments

Deploy

{
  "deploy" : {
    "rakegoals": ["db:migrate"],
    "sidekiq": true
  }
}

git checkout -b clever/deploy
git add Gemfile.lock clevercloud/initDirectories.sh clevercloud/ruby.json config/configuration.yml config/database.yml config/secrets.yml
git commit -m"add clever specifics"
clever deploy

[ldoguin@caolila redmine]$ clever ssh
Opening an ssh shell.
Warning: Permanently added '[195.154.154.198]:40707' (ED25519) to the list of known hosts.
bas@76afae97-762c-43ee-b861-d5db873b553d ~ $ cd app_58f97386-2ec5-48b6-a774-31d64241f692/
bas@76afae97-762c-43ee-b861-d5db873b553d ~/app_58f97386-2ec5-48b6-a774-31d64241f692 $ RAILS_ENV=production bundle exec rake redmine:load_default_data
Select language: ar, az, bg, bs, ca, cs, da, de, el, en, en-GB, es, es-PA, et, eu, fa, fi, fr, gl, he, hr, hu, id, it, ja, ko, lt, lv, mk, mn, nl, no, pl, pt, pt-BR, ro, ru, sk, sl, sq, sr, sr-YU, sv, th, tr, uk, vi, zh, zh-TW [en] 
====================================
Default configuration data loaded.
bas@76afae97-762c-43ee-b861-d5db873b553d ~/app_58f97386-2ec5-48b6-a774-31d64241f692 $ 

Setup and Deploy a Preproduction Redmine

clever addon create postgresql-addon --plan s --region eu redminePG
clever addon create fs-bucket --plan s --region eu staging-redmineFS
clever create --type ruby staging-redmine --region par
clever service --alias staging-redmine link-addon staging-redminePG
clever service --alias staging-redmine link-addon staging-redmineFS
clever env --alias staging-redmine set RUBY_VERSION 2.3.1
clever env --alias staging-redmine set RAILS_ENV production
clever env --alias staging-redmine set REDMINE_LANG en
clever env --alias staging-redmine set SECRET_KEY_BASE `./bin/rake secret`
clever env --alias staging-redmine set ATTACHMENTS_STORAGE_PATH /data/attachments
clever env --alias staging-redmine set CC_FS_BUCKET /data:`clever env --alias staging-redmine  | awk  -F = '/BUCKET_HOST/ { print $2}'`
clever env --alias staging-redmine set CC_PRE_RUN_HOOK ./clevercloud/initDirectories.sh
clever deploy --alias staging-redmine

At Clever Cloud, we want developers to be happy. To achieve that we try to adapt as quickly as we can to users needs. The other day, someone asked for Sidekiq support for their Rails applications.

What's Sidekiq

Sidekiq is a solution to run long background tasks in ruby. It works by running a background server and treating jobs stored in a Redis. It's helpful to delay tasks, take a long API call to the background while still be able to answer to a request in a timely manner.

How do I use Sidekiq on Clever Cloud?

First, you need a Redis instance. Start by provisioning a redis addon on Clever Cloud. Remember to link the redis add-on to your application in the Console.

The redis addon provides a REDIS_URL environment variable which will be used by sidekiq to connect to the redis addon.

• The next and only step is to add/modify the clevercloud/ruby.json file to add the "sidekiq" flag:

{
   "deploy": {
      "sidekiq": true
   }
}

Then commit and push your application, and you should be all set!

After three months of development and testing we are pleased to announce that Ruby is open for beta access on our platform. This famous robust natural language syntax created by Yukihiro Matsumoto is very popular among web developers. It is therefore logical that it is available today on Clever Cloud.

We support Rack-based applications, including applications based on Rails and Sinatra.

You can find more information on Ruby on Rails deployments in our documentation. Do not hesitate to give us your impressions.

We believe that a product is never complete without the feedback of its users, so Ruby is currently in free beta until the final version.

You can keep in touch to get the pricing plans when ready on our mailinglist.

The Clever Cloud team

Deploy your application for free!

Version française

Après quatre mois de développement et de tests intensifs, nous sommes heureux de vous annoncer que Ruby est en beta gratuite sur Clever Cloud. Ce célèbre langage robuste à la syntaxe naturelle, créé par Yukihiro Matsumoto est très prisé par les développeurs web depuis quelques années. Il est donc tout à fait logique qu’il soit disponible aujourd’hui sur Clever Cloud.

Nous supportons actuellement les applications basées sur Rack, ce qui inclut les applications basées sur Rails et Sinatra.

Vous trouverez plus d’informations sur les déploiements Ruby on Rails dans notre documentation. N’hésitez pas à nous faire part de vos impressions.

Nous considérons qu’un produit n’est jamais parfait sans les retours de ses utilisateurs. Ruby est donc actuellement en beta gratuite jusqu’à sa version finale.

Vous pouvez vous tenir informé de nos offres quand elles seront prêtes via notre newsletter.

L’équipe Clever Cloud