Forem: Just The V

Handbook to migrate your Postgres from Heroku to Kamal

Just The V — Mon, 25 Nov 2024 08:00:00 +0000

Today I’m going to show you how I managed to migrate from Heroku to Kamal, with a focus on Postgres. The schema below describes our goal for today :

We want :

A Preprod application, on its own host and its own Postgres instance.
A Production application, with its own Postgres as well. Production also needs another feature : save DB backups on an S3.

We will use my previous article as a base for today. You can find every information here.

1. Add Postgres to Production

       1.1. Edit deploy.yml
       1.2. Edit secrets
       1.3. Edit database.yml

2. Setup Postgres for Preprod

       2.1. Edit deploy.preprod.yml
       2.2. Edit secrets
       2.3. Edit database.yml

3. Migrate the database

       3.1 Download the backup
       3.2. Upload the backup to S3
       3.3. Run the migration script

4. Conclusion

Add Postgres to Production

We already have Production and Preprod applications working perfectly without any additional services. Let’s add and configure our first accessories : Postgres and Backups !

Edit deploy.yml

# config/deploy.yml
[...]
service: my-app

env:
  clear:
    POSTGRES_USER: postgres
    POSTGRES_DB: my_app_production
    POSTGRES_HOST: my-app-db
  secret:
    - RAILS_MASTER_KEY
    - POSTGRES_PASSWORD

accessories:
  db:
    image: postgres:16.4
    host: 190.0.0.0
    port: 5432:5432
    env:
      clear:
        POSTGRES_USER: postgres
        POSTGRES_DB: my_app_production
      secret:
        - POSTGRES_PASSWORD
    directories:
      - data:/var/lib/postgresql/data

  db-backup:
    image: eeshugerman/postgres-backup-s3:16
    host: 190.0.0.0
    env:
      clear:
        SCHEDULE: '@daily' # I want a backup every day for the last 30 days
        BACKUP_KEEP_DAYS: 30
        S3_REGION: eu-west-3
        S3_PREFIX: backups
        S3_BUCKET: my-app-backups
        POSTGRES_HOST: my-app-db
        POSTGRES_DATABASE: my_app_production
        POSTGRES_USER: postgres
      secret:
        - POSTGRES_PASSWORD
        - S3_ACCESS_KEY_ID
        - S3_SECRET_ACCESS_KEY

As my service name is my-app, Kamal will automatically prefix accessories with it. This is why I can freely call my-app-db. Kamal understands that you’re talking about the accessory db linked with the service my-app. This mechanism is very powerful!

For the database backups, I’ll use the marvelous image that does all the work for you : https://github.com/eeshugerman/postgres-backup-s3

Basically, you just need to set up an S3 with the correct permissions, and every day you’ll get your backups there. postgres-backup-s3 also provide a useful feature that allows you to restore an old backup. We will use it later on !

Edit secrets

We now need to ensure that the new secrets are stored in the secrets file:

# .kamal/secrets
[...]
POSTGRES_PASSWORD=fakepassword
S3_ACCESS_KEY_ID=xxxxxxxxxxxxxxx
S3_SECRET_ACCESS_KEY=xxxxxxxxxxxxxxx

Edit database.yml

You also need to help Rails connect to your database by providing the same environment variables:

# config/database.yml
default: &default
  adapter: postgresql
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  timeout: 5000
  host: <%= ENV["POSTGRES_HOST"] %>
  username: <%= ENV["POSTGRES_USER"] %>
  password: <%= ENV["POSTGRES_PASSWORD"] %>

[...]

production:
  <<: *default
  database: <%= ENV.fetch("POSTGRES_DB") { "my_app_production" } %>

Once it’s done, you can run :

$ kamal setup

This will install the Postgres container in Production. You can confirm that everything will work by accessing the dbconsole using : kamal app exec -i 'bin/rails db'

Now that we have Postgres working in Production, let’s do the same for Preprod.

Setup Postgres for Preprod

Well, the steps are exactly the same. We will just provide different env variables. Let’s do it!

Edit deploy.preprod.yml

# config/deploy.preprod.yml
[...]
service: my-app-preprod
[...]
env:
  clear:
    POSTGRES_USER: postgres
    POSTGRES_DB: my_app_preprod
    POSTGRES_HOST: my-app-preprod-db
  secret:
    - RAILS_MASTER_KEY
    - POSTGRES_PASSWORD

accessories:
  db:
    image: postgres:16.4
    host: 190.0.0.1
    port: 5432:5432
    env:
      clear:
        POSTGRES_USER: postgres
        POSTGRES_DB: my_app_preprod
      secret:
        - POSTGRES_PASSWORD
    directories:
      - data:/var/lib/postgresql/data

The only changes from Production are :

— service property.
— POSTGRES_DB and POSTGRES_HOST env variables.
— Host domains for accessories

Edit secrets

We still need to update .kamal/secrets.preprod to provide a POSTGRES_PASSWORD value :

# .kamal/secrets.preprod
[...]
POSTGRES_PASSWORD=fakepassword

Edit database.yml

We need to add the preprod environment and confirm that it takes the right environment variable.

# config/database.yml
[...]
preprod:
  <<: *default
  database:  <%= ENV.fetch("POSTGRES_DB") { "ride_back_preprod" } %>

And, we’re good to run :

$ kamal setup -d preprod

We now have Preprod and Prod applications working with their own database 🎉

Now that everything is set up, let’s say adios to Heroku and migrate our database once and for all!

Migrate the database

The first thing you want to do is cut access to your application to avoid losing any data.

To do so, you can enable the “Maintenance Mode” in the settings of your Heroku application.

Once it’s done, we can get back to work !

Download the backup

You’ll need to find your Postgres public URL to download a backup locally. To do so, go on your application Dashboard and :

“Resources” > “Heroku Postgres” > “Credentials” > “Default” > “URI”

The URI will normally look like this : postgres://{random-letters-and-numbers}ec2[...].eu-west-1.compute.amazonaws.com:5432/[...]
Once you’ve found it, let’s download the database locally using pg_dump:

pg_dump --format=c --no-acl --no-owner {paste URI here}  > database.dump

You should now see a database.dump file in your directory.

Upload the backup to S3

Now, you need to upload your file to the S3 bucket you use to store your backups. Use the exact same directory the backups will go.

Run the migration script

Once your file is uploaded, you can now run this script:

kamal accessory exec db-backup -i "sh" 
source ./env.sh
s3_uri_base="s3://${S3_BUCKET}/${S3_PREFIX}"
aws $aws_args s3 cp "${s3_uri_base}/database.dump" "database.dump"
conn_opts="-h $POSTGRES_HOST -p $POSTGRES_PORT -U $POSTGRES_USER -d $POSTGRES_DATABASE"
pg_restore $conn_opts --clean --if-exists --no-acl --no-owner database.dump
rm -rf database.dump

This script will:

Access to the database backup container using sh
Download your database.dump file using aws cli
Restore the database based on database.dump
Remove database.dump to free space.

That’s it! Your database is now completely self-hosted. Congratulations!

Conclusion

Thanks for reading so far !

If you need help with your Kamal configuration, do not hesitate to comment out or reach me by DM 👋

Deploy your Preprod and Production Rails Application using Kamal

Just The V — Wed, 13 Nov 2024 07:30:00 +0000

In most of the projects I contributed to, the deployment workflow looked like this :

We got a Preprod application that lets us experiment and do some QA. Preprod is an application that I can break without impacting users. Once I know that my Preprod application is working correctly, I can then deploy my application to the Production environment and expose new features to users.

Usually, I used Heroku for both Preprod and Prod. But… come on, we’re in 2024 right ? Heroku is old school, now we’re using Kamal 😎

Today I’ll share with you how I manage the deployment of multienvironment application using Kamal 2 in a step-by-step guide.

I won’t go that deep on how to configure kamal, I’ll just share the specificities of handling 2 environments deployment. If you need more details about a certain part, I linked useful resources that helped me and will help you for sure in the conclusion.

Prepare your Preprod environment

Before toying with Kamal, we need to create the Preprod environment.

To do so, I only need to create a new file in my environments folder

$ cp config/environments/production.rb config/environments/preprod.rb

I want my Preprod environment to be as close as possible to my Prod environment, so I won’t edit the file.

Now that Rails knows my Preprod environment, I need to create a master.key for this environment

$ rails credentials:edit -e preprod

One last thing, we need a dedicated Dockerfile to handle this specific environment when building the Docker image.

For the sake of this article, I will take the default Dockerfile provided by Rails when you’re using rails new, and create a dedicated one for Preprod environment :

$ cp Dockerfile Dockerfile.preprod

The only thing I will edit will be the ENV variables set by Dockerfile.preprod:

# Dockerfile.preprod L20
ENV RAILS_ENV="preprod" \
    BUNDLE_DEPLOYMENT="1" \
    BUNDLE_PATH="/usr/local/bundle" \
    BUNDLE_WITHOUT="development"

That’s it, now we’re good to explore Kamal !!

Your folder architecture will look like this :

.
├── Dockerfile
├── Dockerfile.preprod
└── config
    ├── credentials
    │   ├── preprod.key
    │   └── preprod.yml.enc
    ├── credentials.yml.enc
    ├── environments
    │   ├── preprod.rb
    │   └── production.rb
    └── master.key

Install Kamal

Kamal is not a gem that you add to your Gemfile, but you can install it using gem :

$ gem install kamal

Once it’s done, you have access to Kamal. You can use the following command to bootstrap your Kamal configuration :

$ kamal init

kamal init will create a config/deploy.yml file and a .kamal folder containing a hooks directory and a secrets file

Setup Prod

I will keep my config/deploy.yml as simple as possible, here is what I write :

# config/deploy.yml
service: my-app
image: docker-username/my-app

servers:
  web:
    - 190.0.0.0

proxy:
  ssl: true
  host: mydomain.com
  app_port: 3000

registry:
  username: docker-username 
  password:
    - KAMAL_REGISTRY_PASSWORD

builder:
  arch: arm64
  local: true
  dockerfile: Dockerfile.production
  context: "."

env:
  secret:
    - RAILS_MASTER_KEY

ssh:
  user: ubuntu

Let’s dive into each parameter :

service: The name of your application
image: The name of the image you will use for your registry (I’ll use a public docker registry here)
servers: The addresses of the servers you will deploy your application. Here I have a single host for my production. I can also add a dedicated process for jobs handling if I need to process job.
proxy: handle SSL certificate and point to the right domain name
registry: where your Docker image will be pushed / pulled
builder: Use Dockerfile.production and build it locally when deploying to the server. I use arm64 architecture because I’m using a macBook.
env: It’s a way of passing secrets to the machine. We’ll talk about it just after
ssh: Kamal will connect to the servers using the ubuntu user

To provide secrets, Kamal introduces it own secrets mechanism. You need to edit .kamal/secrets to add the RAILS_MASTER_KEY environment variable.

# .kamal/secrets
RAILS_MASTER_KEY=$(cat config/master.key)
KAMAL_REGISTRY_PASSWORD=mysuperpassword

Once it’s done, you’re good to either setup your server or deploy your application.

$ kamal setup
$ kamal deploy # if you want to deploy only

And now your application is running in production and fully accessible at your domain 🎉

At this stage, your folder architecture will look like this :

.
├── .kamal
│   └── secrets
├── Dockerfile
├── Dockerfile.preprod
└── config
    ├── credentials
    │   ├── preprod.key
    │   └── preprod.yml.enc
    ├── credentials.yml.enc
    ├── deploy.yml
    ├── environments
    │   ├── preprod.rb
    │   └── production.rb
    └── master.key

Let’s see how to setup Preprod deployment now !

Setup Preprod

To configure Preprod deployment, we need to replicate what we did for Production, and essentially add .preprod everywhere:

$ cp .kamal/secrets .kamal/secrets.preprod
$ cp config/deploy.yml config/deploy.preprod.yml

And then in the config/deploy.preprod.yml :

# config/deploy.preprod.yml
image: docker-username/my-app-preprod

servers:
  web:
    - 190.0.0.1

proxy:
  host: preprod.mydomain.com

builder:
  dockerfile: Dockerfile.preprod

And … that’s it.

Kamal will read the “primary” config (deploy.yml) as a fallback for missing value in our deploy.preprod.yml. We’re just saying to Kamal that it must take the Dockerfile.preprod and set the SSL certificate will point to preprod.mydomain.com

The last thing to do before deploying is to edit the secrets :

# .kamal/secrets.preprod
RAILS_MASTER_KEY=$(cat config/credentials/preprod.key)
KAMAL_REGISTRY_PASSWORD=mysuperpassword

And then you’re good to go :

$ kamal setup -d preprod
$ kamal deploy -d preprod # if you want to deploy only

Your application can be accessed at preprod.mydomain.com !

Your folder architecture will look like this :

.
├── .kamal
│   ├── secrets
│   └── secrets.preprod
├── Dockerfile
├── Dockerfile.preprod
└── config
    ├── credentials
    │   ├── preprod.key
    │   └── preprod.yml.enc
    ├── credentials.yml.enc
    ├── deploy.preprod.yml
    ├── deploy.yml
    ├── environments
    │   ├── preprod.rb
    │   └── production.rb
    └── master.key

Ressources

Conclusion

I took a lot of shortcuts here, but the point is that it’s very easy and painless to deploy multienvironment applications using Kamal.

So far, I only have good experience using Kamal. I've never had any difficult stages while debugging / monitoring, so it’s a very positive thing.

📩My journey to send 100 mails to 500k effortlessly📩

Just The V — Mon, 04 Nov 2024 07:30:00 +0000

Today, I’d like to share my journey while working for a client on implementing an efficient mailing system.

We'll see how I enabled my client to send 100, 1,000, and even 500,000 emails without impacting the performance of my Rails application.

Let's dive in now 🎉

1. The Mail
2. V1: Deliver Now (up to 300 emails)
3. V2: Deliver Later (up to 100,000 emails)
4. V3: Perform All Later (up to +500,000 emails)
5. Other possible alternatives I explored
       5.1. Monkey Patching Application Mailer
       5.2. Using the Mail Provider’s Native Bulk Send
       5.3. Using BCC
6. Conclusion

The Mail

For the project example, we'll start with a simple mailer, adding a method to send emails that simply forwards the arguments. Here's the code:

# app/mailers/application_mailer.rb
class ApplicationMailer < ActionMailer::Base
  def generic_mail(subject:, body:, to:)
    mail(subject: subject, body: body, to: to)
  end
end

# Call the mailer like this:
ApplicationMailer.generic_mail(
  subject: "Hello", body: "<p>How are you today?</p>", to: "you@gmail.com"
).deliver_now

The goal is to expose an interface to my admin so they can send emails to our entire user base. Here's an example of what the interface might look like:

The challenge is ensuring that the emails are sent promptly, ideally within 10 seconds.

Let's explore the different iterations of sending emails!

V1: Deliver Now (up to 300 emails)

The simplest way to send emails in Rails → deliver_now

User.pluck(:email).each do |email|
  ApplicationMailer.generic_mail(
    subject: "Hello", body: "<p>How are you today?</p>", to: email
  ).deliver_now
end

Initially, we only had a Rails application and a database. Given our small user base, using deliver_now was acceptable.

The problem with deliver_now is that it’s a blocking call. It waits for a response from the mail provider before moving to the next line of code.

Assuming each API call takes around 100ms, sending 100 emails would mean a 10-second wait on the interface. This solution is thus only suitable for testing scenarios with a minimal database.

V2: Deliver Later (up to 100,000 emails)

The logical next step to accelerate the application is to send emails within a Job. ActionMailer offers the deliver_later method for this.

User.pluck(:email).each do |email|
  ApplicationMailer.generic_mail(
    subject: "Hello", body: "<p>How are you today?</p>", to: email
  ).deliver_later
end

deliver_later enqueues a MailDeliveryJob with all the mail information.

We were satisfied with this for a while. However, as our email volume increased, Redis started to be overwhelmed with write operations.

Despite Redis being very fast, sending around 10,000 emails led to slowdowns, likely due to our $3/month instance on Heroku.

Fortunately, I found an even more efficient solution for handling higher volumes of emails!

V3: Perform All Later (up to +500,000 emails)

Rails 7.1 introduced a powerful feature called ActiveJob.perform_all_later, enabling bulk job enqueuing. The downside is that we need to move away from mail.deliver_later and use a custom job class. Here's a simple implementation:

class SendEmailJob < ApplicationJob
  queue_as :default

  def perform(subject:, body:, to:)
    ApplicationMailer.generic_mail(
      subject: subject, body: body, to: to
    ).deliver_now
  end
end

jobs = []
User.pluck(:email).each do |email|
  jobs << SendEmailJob.new(
    subject: "Hello", body: "<p>How are you today?</p>", to: email
  )
end

ApplicationJob.perform_all_later(jobs)

With this implementation, we managed to send emails to 500,000 users in approximately 15 seconds. Pretty impressive!

Based on my benchmarks, this method could potentially handle sending 1,000,000 emails in about 40 seconds. Unfortunately, Heroku imposes a page timeout after 30 seconds, so another solution will be necessary when I will need to send a million.

Other possible alternatives I explored

Monkey Patching Application Mailer

Seeing the performance of ApplicationJob.perform_all_later led me to consider monkey-patching ApplicationMailer to implement a deliver_all_later method. Here is my implementation:

class ApplicationMailer < ActionMailer::Base
  class << self
    def deliver_all_later(messages, options = {})
      jobs = messages.map do |message|
        message.delivery_handler.delivery_job.new(
          message.delivery_handler.name, message.instance_variable_get(:@action).to_s, 'deliver_now', args: message.instance_variable_get(:@args)
        ).set(options)
      end

      ActiveJob.perform_all_later(jobs)
    end
  end
end

In theory, this seemed promising. However, my benchmarks showed inefficiencies beyond 100,000 emails due to memory bloat from handling many MessageDelivery objects. Thus, it wasn’t the best path.

Using the Mail Provider’s Native Bulk Send

Some providers like Mailjet offer native bulk sending. This could be an option in the future if our email volume continues to grow, although it requires using their SDK over ApplicationMailer, making the code less Rails-friendly.

Using BCC

An easy idea is to use BCC, sending the same email to many recipients. This would work if the email content is identical for everyone. However, my custom mail system interprets user-specific variables, so this wasn't viable for my use case.

Conclusion

That’s it, thanks for reading me so far. If you find a better way to send more and more mails I would love to hear from you. Don’t hesitate to comment if you want more details about my searches / benchmark.

Bye 🕺

🚩Effortless Feature Management in Rails : A Guide to Using Flipper with Active Admin

Just The V — Tue, 03 Sep 2024 07:00:00 +0000

Feature flags are development tools that allow you to control the activation and deactivation of certain features in your application during runtime.

They are extremely useful for testing new features in production or for performing progressive deployments, all without redeploying the code.

Today, we will explore how to implement feature flags in your Ruby on Rails application by integrating Flipper into your Active Admin.

All the code shown today is accessible in this repository.

1. Feature Flags Management
2. Use a Feature Flag in Your Code
3. How I Integrate Flipper UI in ActiveAdmin
       3.1. 1. Only Admins have access to Flipper UI
       3.2. 2. Flipper UI must be accessible on the Admin Panel
       3.3. 3. Admin Panel must be accessible on the Flipper UI
4. Conclusion

Feature Flags Management

To add feature flags to your application, we will use the Flipper ecosystem.

For this, we will need three gems: flipper, flipper-ui, and flipper-active_record.

$> bundle add flipper flipper-ui flipper-active_record

To store the feature flags in your database, we need to tell Flipper to use ActiveRecord. To do this, run the Flipper setup command:

$> rails g flipper:setup

Finally, to create and modify our feature flags graphically, we just need to expose flipper-ui routes. Flipper UI will expose a web interface for managing our feature flags.

# config/routes.rb

Rails.application.routes.draw do
  mount Flipper::UI.app(Flipper) => '/feature-flags'
end

And voilà 🎉, you have configured Flipper in your application. You can now access the UI via the /feature-flags route by starting your server.

Before configuring the integration with ActiveAdmin, let’s create our first feature flag together.

It will be called new_admin_dashboard and is activated at 50% for all users.

Use a Feature Flag in Your Code

Let’s assume we have an application using ActiveAdmin. On the root of your Active Admin Panel, you will find the default dashboard. Here is mine:

# app/admin/dashboard.rb

ActiveAdmin.register_page "Dashboard" do
  menu priority: 1, label: 'Dashboard'

  content title: "'Dashboard' do"
    div class: "blank_slate_container", id: "dashboard_default_message" do
      span class: "blank_slate" do
        span 'Welcome to ActiveAdmin.'
        small "You're looking at the default dashboard."
      end
    end
  end
end

We will implement new wording in our dashboard, which will only be exposed via the new_admin_dashboard feature flag.

# app/admin/dashboard.rb

[...]
span class: "blank_slate" do
  if Flipper.enabled?(:new_admin_dashboard)
    span 'Welcome to the new ActiveAdmin dashboard!'
    small "You're looking pretty cool! Have a nice day buddy!"
  else
    span 'Welcome to ActiveAdmin.'
    small "You're looking at the default dashboard."
  end
end
[...]

The feature flag is now in place. When I refresh the page, I have a 50/50 chance of seeing my new wording:

How I Integrate Flipper UI in ActiveAdmin

Flipper UI is really cool! But in order to expose it to non-technical users, it’s important to link your application with Flipper UI.

In the projects where I had to integrate Flipper, I also had Active Admin, which allows non-technical users to interact with the application.

Here are a few points on how I link the two tools:

1. Only Admins have access to Flipper UI

To allow only admins to access Flipper UI, we will leverage Active Admin authentication. For this, simply modify the way we declare our route to Flipper UI:

# config/routes.rb
Rails.application.routes.draw do
  ActiveAdmin.routes(self)

  devise_for :admins, ActiveAdmin::Devise.config
  authenticate :admin do
      mount Flipper::UI.app(Flipper) => '/admin/feature-flags'
  end
end

And there you go! Our Flipper UI is now behind the Active Admin authentication wall and is accessible at the /admin/feature-flags route.

2. Flipper UI must be accessible on the Admin Panel

Only admins have permission to access Flipper UI. But they still need to find the access!

Fortunately, Active Admin offers a very simple solution:

# config/initializers/active_admin.rb

[...]
config.namespace :admin do |admin|
  admin.build_menu :default do |menu|
    menu.add label: 'Feature Flags', url: '/admin/feature-flags'
  end
end
[...]

That’s all 🎉

3. Admin Panel must be accessible on the Flipper UI

Once on the Flipper UI interface, I want to be able to easily return to the admin page. Fortunately, Flipper UI exposes an option in its configuration just for this!

We will create an initializer file to hold the Flipper configuration:

# config/initializers/flipper.rb

Flipper::UI.configure do |config|
  config.application_breadcrumb_href = '/admin'
end

This configuration allows Flipper UI to display a small “< App” button at the top of its navigation menu.

Now we have a link from the admin to Flipper, and from Flipper back to the admin!

Conclusion

Setting up feature flags with Flipper and Active Admin offers great flexibility in managing the activation of new features in production while minimizing risks.

This integration allows both technical and non-technical teams to collaborate more effectively by providing tools tailored to their needs.

We have covered a very simple use case of Flipper, but in reality, this tool is quite powerful and capable of more advanced calculations than just “Displaying this dashboard 50% of the time.”

Thank you for reading, and see you soon in the next article!

Make your Rails App Configurable in 4 Ways

Just The V — Thu, 01 Aug 2024 07:00:00 +0000

Over the years, I have participated in several Ruby on Rails projects that implement the same functionalities but in completely different ways.

Today, I would like to share with you the 4 ways I have found most effective for making the projects I have worked on Configurable.

Introduction

Configuring an application means giving administrators the ability to provide the context your application needs to operate.

Let's say your application has a paid subscription. As a developer, you want to "give control" to administrators to update prices. You want to be able to call a "variable" directly in the code, which is accessible everywhere. This is how you will make your application configurable.

1. Constants
2. Configuration File
3. Configuration Model
4. Variable Model
TL;DR
Conclusion

1. Constants

Explanation

The simplest and most naive way to make your application configurable is by assigning constants to your classes.

There are generally two types of constants:

Global constants, which you will use in multiple places in your application:

# config/initializers/global.rb
class Global
  SOFTWARES = %w[libreoffice word textedit].freeze
  BRAND_NAME = "YourNameHere"
end

# You can use it everywhere in your app like this
Global::BRAND_NAME = "YourNameHere"

Or constants that are specialized for a feature or class:

class UpdateUserFirstNameService
  FORBIDDEN_FIRST_NAME = "Julien"

  def call(user:, first_name:)
    raise 'Forbidden first name' if first_name == FORBIDDEN_FIRST_NAME

    user.update(first_name: first_name)
  end
end

These constants are directly accessible throughout the application without going through a database or external files.

Pros

Simplicity and Speed: Immediate access to configuration.
Security: Fewer risks of accidental modifications since constants are defined in code and not modifiable via an admin interface.

Cons

Lack of Flexibility: Any changes require code modification and redeployment of the application, which can be cumbersome for configurations that may need to change more regularly.
Not Suitable for Dynamic Configurations: Not practical for data that needs to be updated regularly or is too voluminous to be efficiently managed as constants.
Lack of Administrative Control: Non-technical administrators cannot update configurations without going through developers.

When to Use It?

In my opinion, this approach should only be used when you want to configure static elements. Examples include API keys, values useful throughout your application, or data for static pages.

2. Configuration File

A slightly more advanced way to configure your application is via configuration files.

Explanation

In a .yml or .csv file, you can store all the data you need in a hierarchical format. You can then exploit this data by reading it when the application starts. We then need to expose these values to our application through a class that contains a constant.

Here's an example:

# config/app/airports.yml
AYHK:
  name: Hoskins Airport
  country: US
  [...]
EFVR:
  name: Varkaus Airport
  country: FI
  [...]
[...]

# app/services/find_airport_service.rb
class FindAirportService
  AIRPORTS = YAML.safe_load(Rails.root.join("config/app/airports.yml").read)
                 .with_indifferent_access.freeze
  class << self
    def from_id(id)
      AIRPORTS.fetch(id)
    end

    def from_country(country)
      [...]
    end
  end
end

Pros

Developer Control: Modifications are controlled by developers, reducing the risk of accidental errors.
Performance: Quick reading of configurations at startup without database queries.

Cons

Less Flexible for Administrators: All changes require developer intervention and application restart.
Management Difficulties for Large Data Sets: Complications can arise when information is numerous or when data structures evolve.

When to Use It?

We already use .yml files in our Rails projects for I18n. Configuration files are very useful for storing data that we don't want in the database but is too numerous for simple constants.

3. Configuration Model

Now that we've seen static configurations, let's look at dynamic configurations by introducing the database.

Explanation

We'll set up a Configuration model. Each attribute of this model corresponds to a specific variable. We could represent the table as follows:

# inside db/schema.rb
create_table "configurations", force: :cascade do |t|
  t.float "variable_1", default: 5.0, null: false
  t.integer "variable_2", default: 160, null: false
  t.bigint "admin_id", null: false
  t.boolean "active", default: true, null: false
  t.index ["admin_id"], name: "index_configurations_on_admin_id"
end

admin_id: Identifies who set up the configuration.
active: Identifies the configuration to use.
variable_1 and variable_2: Variables stored in the database.

The idea is to have a Configuration model that exposes quick and lightweight access for the application.

Here's how I like to implement it:

# app/models/configuration.rb
class Configuration < ApplicationRecord
  LOOKABLE_ATTRIBUTES = %i[
    variable_1
    variable_2
  ].freeze

  class << self
    def active
      Rails.cache.fetch('active_configuration') do
        Configuration.find_by!(active: true).to_h
      end
    end

    def to_h
      LOOKABLE_ATTRIBUTES.index_with do |attribute|
        send(attribute)
      end
    end

    LOOKABLE_ATTRIBUTES.each do |attribute|
      define_method(attribute) do
        active[attribute]
      end
    end
  end
end

# rails console 
[1]> Configuration.variable_1
Configuration Load (1.9ms)  SELECT "configurations".* FROM "configurations" WHERE "configurations"."active" = $1 LIMIT $2  [["active", true], ["LIMIT", 1]]
=> 5.0
[2]> Configuration.variable_2
=> 160

Next, I just need to expose my Configuration model through the admin interface. When an admin wants to update the Configuration, a new record is created. This record has active: true, and it invalidates the cache in the process.

If at any point there's a configuration issue, I can always roll back simply by modifying the active attribute.

Pros

Control and Flexibility: Administrators are autonomous while developers retain code control.
Security and Traceability: Each change can be traced to a specific admin, and configurations can be easily activated or deactivated.
Good Performance: Uses caching to avoid repetitive database queries, thus improving performance.

Cons

Cache Management: Requires an effective strategy for cache invalidation when configurations are updated.
Adding Variables is Cumbersome: To add a variable in your Configuration model, you need to: Make a migration, update your model, update your admin interface, and deploy.

When to Use It?

Perfect for environments where configurations need to be frequently updated by administrators, but adding variables is rare.

4. Variable Model

The Configuration model has a limitation: adding variables is restricted by the developer.

Let's see how to break this glass ceiling with the Variable model.

Explanation

This method uses a Variable model where each record represents a different variable. Let's see its structure right away, and I'll explain afterward:

# db/schema.rb
create_table "variables", force: :cascade do |t|
  t.string "name", null: false
  t.string "value", null: false
  t.string "type", null: false
  t.boolean "array", default: false, null: false
end

The attribute names are quite clear. Let's look at an example of implementation I use for this approach:

# app/models/variable.rb
class Variable < ApplicationRecord
  enum type: { string: 'string', integer: 'integer', float: 'float', boolean: 'boolean' }

  class StringResolver
    def self.resolve(value)
      value.strip
    end
  end

  class IntegerResolver
    [...]
  end

  class FloatResolver
    [...]
  end

  class BooleanResolver
    [...]
  end

  class << self
    def fetch(name)
      variable = find_by!(name: name)
      resolver = "#{variable.type.camelize}Resolver".constantize
      if variable.array
        variable.value.split(',').map { |v| resolver.resolve(v) }
      else
        resolver.resolve(variable.value)
      end
    end
  end
end

# rails console 
[1]> Variable.create!(name: "foo", type: "float", value: "5.34,43.4,10.0", array: true)
[2]> Variable.fetch("foo")
=> [5.34, 43.4, 10.0]

This is a very simple version of the Variable model. Another implementation could allow requesting multiple Variables at once, using a LIKE query for example.

Pros

Fully Administered by Admin: Allows flexible management of configurations without developer intervention.
Flexibility: Administrators can add, modify, or delete configurations on the fly.

Cons

Risk of Errors: High risk of

human error, such as a typo in the variable name, which can lead to hard-to-detect bugs.

Performance: Can impact performance if configurations are frequently queried without effective caching. This can quickly become a memory sink.

When to Use It?

I really like this approach for generalizing code aspects. It allows me to ignore the context beforehand and still develop quite advanced features. I also like that I often have to use a lot of meta-programming to exploit it to its full potential.

However, there are often errors because the admin or developer forgot to create or misspelled a variable.

TL;DR

If you're a bit lost with all these methods, I've prepared a simple questionnaire to help you decide when to use which method.

Do configurations need to be modified?
- No: Constants
Do administrators need to modify configuration variables without developer intervention?
- No: Configuration File
Do administrators need full control over the configuration?
- Yes: Variable Model
- No: Configuration Model

Conclusion

In summary, choosing the right method to configure your application depends on the frequency of changes, who controls these changes, and the importance of flexibility.

The easiest guide to generate PDF📜 using Prawn in your Rails project

Just The V — Thu, 25 Jul 2024 07:00:00 +0000

By the end of this guide, you will be able to generate a PDF on demand using the Prawn gem in your Ruby on Rails project!

PDF generation is a feature that I have often been asked for when developing Ruby on Rails projects. Let's see how I like to implement it in my projects.

1. What is Prawn?
    1.1. Managing the Cursor
    1.2. Managing Tables
2. Let’s build something together!
3. Pros and Cons of Using Prawn
    3.3. Pros
    3.4. Cons
4. Conclusion

What is Prawn?

Prawn is a fast and lightweight Ruby library for generating PDFs. It has no external dependencies, which means you only need to install the gem in your project:

$ bundle add prawn

Generating a PDF file is very simple. Prawn exposes a very clear API for that:

pdf = Prawn::Document.new
pdf.text "Hello World!", style: :bold, align: :center, size: 18
pdf.render_file("hello_world.pdf")

Once the code is executed, we have a beautiful PDF file "hello_world.pdf" that indeed contains the wording "Hello World!".

Writing text in a PDF is great, but you can do much more with Prawn.

Managing the Cursor

When we create a PDF document, Prawn exposes us "Cursor". It's our guide to know where we are in the document we are creating.

As you saw in the example above, the text naturally appeared at the top of my page.

If I add other text blocks, they will follow each other, skipping a line:

pdf = Prawn::Document.new
pdf.text "Hello World!", style: :bold, align: :center, size: 18
pdf.text "Hello World!", style: :bold, align: :center, size: 18
pdf.text "Hello World!", style: :bold, align: :center, size: 18
pdf.text "Hello World!", style: :bold, align: :center, size: 18
pdf.render_file("hello_world.pdf")

Thanks to this notion of cursor, we can change the layout of the elements using all the cursor methods:

pdf = Prawn::Document.new
pdf.text "Hello World!", style: :bold, align: :center, size: 18

pdf.stroke_horizontal_rule
pdf.pad 20 do
  pdf.text "Full padding", style: :bold, align: :center, size: 18
end
pdf.stroke_horizontal_rule

pdf.move_down 100

pdf.stroke_horizontal_rule
pdf.pad_bottom 20 do
  pdf.text "Padding Bottom", style: :bold, align: :center, size: 18
end
pdf.stroke_horizontal_rule

pdf.move_up 80
pdf.text "Last text but display before", style: :bold, align: :center, size: 18

pdf.move_cursor_to pdf.bounds.bottom + 20
pdf.text "Origin of the document", style: :bold, size: 18

pdf.render_file("hello_world.pdf")

A few additional explanations:

stroke_horizontal_rule: allows you to draw a horizontal line. Useful to see the impact of padding.
pad: Short for padding, allows you to add space above and below.
pad_bottom: Short for padding-bottom, allows you to add space below.
move_up: Moves the cursor up from its position.
move_cursor_to: Moves the cursor exactly to the specified line.

All these helpers are very practical for placing our content on the page.

Managing Tables

Creating tables is a very common use case when it comes to PDF generation. Let's see how to create a basic table:

# Prawn supports basic HTML tags. I use them to style my table headers
headers = %w[Name Age City].map { |header| "<font size='12'><b>#{header}</b></font>" }

data = [
  ['John', 25, 'New York'],
  ['Jane', 30, 'London'],
  ['Bob', 20, 'Paris'],
]

pdf = Prawn::Document.new
pdf.table([headers, *data], width: pdf.bounds.width, header: true,
          cell_style: {
            borders: %i[top bottom left right], padding: 5,
            size: 10,
            inline_format: true
          })

pdf.render_file('hello_world.pdf')

Cool, now we’re enough stuffed to build something real !

Let’s build something together!

Now that you know almost everything you need to know before getting started with PDF creation, let’s build.

I propose we integrate a feature that I have already been asked for: export data from my database to a PDF file.

Imagine: We are an e-commerce shop, and we already display a page containing all the orders information to our administrators.

We already expose an HTML view that reports the different orders as follows:

class OrdersController < ApplicationController
  def index
    @orders = Order.limit(25)
  end
end

But you understand, HTML is old school; now we want to render PDFs.

For this, we will use Prawn!

In general, I like to create a fairly generic method in ApplicationController in order to dynamically use it in my OrdersController:

class ApplicationController < ActionController::Base
    private

    # collection: ActiveRecord_Relation
    # column_names: Array of symbols or strings that represent the attributes I want to extract
  def create_pdf_from(collection, column_names)
    headers = column_names.map { |header| "<font size='12'><b>#{header}</b></font>" }
    attributes = collection.pluck(column_names)

    pdf = Prawn::Document.new
    # The title of the document is the name of the model
    pdf.text collection.klass.name.humanize, align: :center, size: 24

    pdf.table([headers, *attributes], width: pdf.bounds.width, header: true,
              cell_style: {
                borders: %i[top bottom left right], padding: 5,
                size: 10,
                inline_format: true
              })

    pdf.move_down 10
    pdf.text "Rendered #{collection.size} records", align: :right, size: 12
    pdf
  end
end

To render a PDF file, we will use respond_to to respond based on the requested format:

class OrdersController < ApplicationController
  def index
    @orders = Order.limit(25)
    respond_to do |format|
      format.html
      format.pdf do
        pdf = create_pdf_from(@orders, %i[id price username shipping_address])
        send_data pdf.render, filename: 'orders.pdf', type: 'application/pdf'
      end
    end
  end
end

And voilà 🎉

When I access the URL http://localhost:3000/orders.pdf on my server, a download starts with the file:

Pros and Cons of Using Prawn

Prawn is IMO the best tool to create PDF on the fly. I already used WickedPDF to generate PDF from HTML views, but it does not support well very complex views.

Pros

Lightweight and fast: Prawn is designed to be performant and uses minimal resources. This makes it an excellent choice for applications where PDF generation needs to be quick and efficient.
Flexible: Prawn offers great flexibility for creating complex PDF documents with various graphic and textual elements. You can easily add text, images, tables, shapes, and even draw directly on the PDF.
Self-contained: Prawn requires no external dependencies, which simplifies its installation and usage. You can easily integrate it into your Ruby on Rails project!
Rich documentation: Prawn has comprehensive documentation, making it easy to find solutions and learn best practices. The documentation is provided in PDF form… quite amusing.

Cons

DSL: It is important to note that despite its simplicity, it requires a little adaptation time. Indeed, like all libraries that manipulate graphics (I think of TKinter or SDL), Prawn has its own rules. In my opinion, you need to spend some time on the documentation to really get the hang of the tool.
Limited HTML integration: Prawn is not a gem that converts HTML views to PDF. However, it is important to note that HTML tags are supported in a limited way. You have a good example of this in how I style my table headers. If you are looking to render HTML views in PDF, use WickedPDF.

Conclusion

By following this guide, you have learned to generate PDFs on demand using the Prawn gem for your Ruby on Rails projects.

Prawn stands out for its lightness, speed, and flexibility, making PDF generation both powerful and easy to integrate. Although it has some limitations, its advantages make it a solid option for most PDF generation needs.

I encourage you to continue exploring the many possibilities offered by Prawn and to experiment with its various features to meet the needs of your projects. Feel free to share your own experiences and tips in the comments, I would love to read them!

To make sure you don't miss any of my upcoming articles on Ruby and Rails, subscribe.

9 things that 🚨Rubocop🚨 don’t want you to use

Just The V — Tue, 23 Jul 2024 07:00:00 +0000

One day, I got lost in the Rubocop documentation. I was struck by a realization: there are many Ruby features I didn't know existed because Rubocop tells us not to use them.

Today, I wanted to share with you the 9 discoveries that surprised me, which Rubocop recommends avoiding!

And / Or Operators (Style/AndOr)

Did you know it is possible to write:

ary = %w[hello world]
ary.size == 2 **and** ary.last == 'world'
=> true

So why use && and || when you can directly write and and or?

The answer is quite simple, it's a matter of precedence compared to other operators.

The precedence table provided by the Ruby documentation shows us that the or and and operators are among the last to be evaluated in a Ruby expression.

In practice, this means we can form quite strange expressions, as indicated in the RubyStyle guide:

true or true and false # => false (it's effectively (true or true) and false)
true || true && false # => true (it's effectively true || (true && false)
false or true and false # => false (it's effectively (false or true) and false)
false || true && false # => false (it's effectively false || (true && false))

And it is due to its rather misleading behavior that we favor using && and ||.

Then Keyword (Style/MultilineIfThen)

There is a keyword then, which is accepted by Rubocop for one-line if-elsif blocks.

a = rand(10)

if a < 3 then "Low"
elsif a < 6 then "Average"
elsif a < 8 then "High"
end

It is an interesting feature! It somewhat resembles a case block but allows chaining different conditions easily.

Rubocop's rule recognizes that the following syntax is bad practice:

a = rand(10)

if a < 3 then
  "Low"
elsif a < 6 then
  "Average"
elsif a < 8 then
  "High"
end

Which makes sense since then is completely unnecessary in this case.

BEGIN and END blocks (Style/BeginBlock)

This was also a real discovery. By using BEGIN, we can execute code when our Ruby script starts. END does the same, but when our script finishes:

# test.rb
BEGIN { pp 'Hello World!'}
END { pp 'Goodbye World!'}

pp "Running my script..."
---

$ ruby test.rb
"Hello World!"
"Running a script"
"Goodbye World!"

I admit that in my daily life, I don't really think about using this syntax. I imagine it can be useful when designing CLI applications. To prepare and clean up a program.

?c → 'c' (Style/CharacterLiteral)

This one is very short. When you type ? followed by an ASCII character, it returns the ASCII character as a string:

$ irb
001> ?a
=> "a"
002> ?\t
=> "\t"

What's the point? I don't really see either.

In fact, this feature was implemented to allow obtaining the ASCII code of the character. Before Ruby 1.9, you could do:

001> ?a
=> 97
002> ?\t
=> 9

But since Ruby 1.9, it only returns the character. The ASCII code can still be found via the .ord method.

A good anecdote to tell at meetups!

There are a lot of aliases for collection methods (Style/CollectionMethods)

We are used to using .map, .select, or .include? when manipulating an Enumerable. But did you know there is an alias for these methods?

Here is the list of methods with an alias that should be used (according to Rubocop):

.collect => .map
.collect! => .map!
.collect_concat => .flat_map
.inject => .reduce
.detect => .find
.find_all => .select
.member? => .include?
.lenght => .size

This Cop exists for one reason only: to ensure the use of a single method name throughout the project. In reality, I understand that it is impractical to have a project containing both .collect and .map. It can require a mental effort to remember that they are the same thing.

We have another justification for this choice in the RubyStyle documentation:

“The rhyming methods are inherited from Smalltalk and are not common in other programming languages. The reason the use of select is encouraged over find_all is that it goes together nicely with reject and its name is pretty self-explanatory.”

% behaves like sprintf (Style/FormatString)

I discovered that we can use % like sprintf:

001> sprintf("%5d", 10)
=> "   10"
002> "%5d" % 01
=> "   10"

Basically, it's a shortcut but does exactly the same thing as sprintf.

We can pass arguments to it in the form of an Array if using multiple arguments during formatting:

001>  "Name: %s, Age: %d" % ["V", 23]
=> "Name: V, Age: 23"
002> "Name: %{name}, Age: %{age}" % { name: "V", age: 23 }
=> "Name: V, Age: 23"

Rubocop's rule is also there to ensure the use of a single method between sprintf, format, and %.

%w[] is not only a story of

In Ruby, we are fortunate to have %w[Hello World] notation to create an array of strings. But did you know it is possible to use almost any non-alphanumeric character as a delimiter?

%w{Hello World}
%w/Hello World/
%w@Hello World@
%w-Hello World-
%w*Hello World*
%w&Hello World&
# <> behaves like [] or ()
%w<Hello World>
...

So why do we use []? The answer is given in the RubyStyle doc:

We most often use [] because it aligns with the array syntax [0, 1, 2]. It's as simple as that!

But there are a few small exceptions like %q which uses only parentheses (). But also regexes that use %r{} because parentheses () and square brackets [] are frequently used in regexes.

FlipFlop Operator (Lint/FlipFlop)

This is a rather interesting find! The FlipFlop Operator. Let's see an example right away, and I'll explain the details:

# test.rb
text = <<~EOF
  random line 1
  start
  interesting line 1
  interesting line 2
  end
  random line 2
EOF

text.each_line do |line|
  puts line if (line.chomp == 'start'..line.chomp == 'end')
end
---

$ ruby test.rb
start
interesting line 1
interesting line 2
end

The FlipFlop operator works in two phases, "flip" and "flop".

The operator "flips" (becomes true) when the first condition is true, and "flops" (becomes false again) when the second condition is true. Between these two points, it remains true, even if the first condition becomes false.

Honestly, I quite like this syntax.

Rubocop advises against using the FlipFlop operator in Ruby because it complicates code readability, making its behavior opaque to those unfamiliar with the operator. It encourages the use of clearer and more explicit alternatives such as loops and conditions to improve code maintainability.

There are a lot of Perl-style global variables (Style/SpecificGlobalVars)

I'm not going to list them all, but Ruby exposes many so-called “Perl-style” variables. You can find a complete list here.

Basically, these are variables that start with $ and can be found in two forms: the short form, or the long form in English.

Here's a small example of variables I liked:

# Print file name
puts $0
puts $PROGAM_NAME

# Print required files
puts $:
puts $LOAD_PATH

# Print error backtrace and error information
begin
  File.read('non_existant_file.txt')
rescue
  puts $ERROR_POSITION
  puts $@

  puts $ERROR_INFO
  puts $!
end

There are many others, most of them having their equivalent in short/long versions.

Conclusion

I am delighted to see the diversity and richness of Ruby's features we explored today, even if Rubocop sometimes advises us to avoid them.

This variety demonstrates the flexibility and power of the language, offering us multiple ways to write and structure our code. Discovering these less common aspects can inspire us to experiment further and deepen our understanding of Ruby.

I would be very curious to know what the latest Rubocop Cop that taught you about our favorite language.

Feel free to subscribe so you don't miss my next breakdown on Ruby/Rails topic.

Everything you needed to know about respond_to 🔎

Just The V — Thu, 18 Jul 2024 07:06:49 +0000

In Rails, creating a controller that returns an HTML view is standard. But did you know that it is possible to return HTML, CSV, JSON, PDF, XML, and many other formats using the respond_to method in the same endpoint ?

That's what we'll explore today!

What exactly is respond_to?
You can deal with a LOT of formats in the same endpoint
You can set default actions
You can set up customised Mime Types
You can mix variants and formats easily !
Conclusion

What exactly is `respond_to`?

To answer this question, let's look at a concrete example of using respond_to.

Let's start with this controller, ArticlesController, which has only one method: show.

class ArticlesController < ApplicationController
  def show
    @article = Article.find(params[:id])
  end
end

Thanks to Rails' convention, we all know that the show method will return an HTML view. This HTML view is templated via the file app/views/articles/show.html.erb. All these rules are implicit because the default format is HTML.

But imagine that tomorrow you want to be able to return JSON instead of HTML, without changing your logic.

You would use respond_to!

class ArticlesController < ApplicationController
  def show
    @article = Article.find(params[:id])
    respond_to do |format|
      format.html # will render show.html.erb
      format.json { render json: @article }
    end
  end
end

From now on, you can pass a particular argument to your route: the format.

Let's see how how it works using the routes helpers :

$ bin/rails console
> app.article_path(1) # by default, format is HTML
=> "article/1"
> app.article_path(1, format: :json)
=> "article/1.json"

So, simply by adding the extension .json at the end of your route, it will call for JSON format !

Now that we have the basics, let's look at some advanced use cases for respond_to.

You can deal with a LOT of formats in the same endpoint

As seen earlier, you can return JSON and HTML in the same method. But in fact, there are many other possible formats!

class ArticlesController < ApplicationController
  def show
    @article = Article.find(params[:id])

    respond_to do |format|
      format.html # show.html.erb
      format.json { render json: @article } # will automatically use #to_json
      format.xml  { render xml: @article.attributes } # will use #to_xml
      format.csv  { render csv: @article.attributes.to_a.to_csv }
      format.pdf  { render pdf: @article.generate_pdf } # let's assume that generate_pdf returns a pdf file
    end
  end
end

With this syntax, you can handle many formats. I have listed here those I have already used in production projects, but there are many others. As many as your application supports MimeTypes.

You can set default actions

Suppose you want to define a default action when the format is not supported. There is the use of format.any that can save you!

class ArticlesController < ApplicationController
  def show
    @article = Article.find(params[:id])

    respond_to do |format|
      format.html # show.html.erb
      format.any { head :not_acceptable }
    end
  end
end

You can also specify in the any argument the formats you want to consider in your default action:

class ArticlesController < ApplicationController
  def show
    @article = Article.find(params[:id])

    respond_to do |format|
      format.html # show.html.erb
      format.any(:json, :xml, :csv) { head :not_acceptable }
    end
  end
end

It is important to note that if your route is called with an unsupported format, respond_to will raise an ActionController::UnknownFormat error.

You can set up customised Mime Types

Have you set up your own Mime Type? respond_to can still help you!

# config/initializers/mime_types.rb
Mime::Type.register "application/custom_mime_type", :custom

class ArticlesController < ApplicationController
  def show
    @article = Article.find(params[:id])

    respond_to do |format|
      format.custom { render plain: 'Hello World!' }
    end
  end
end

What is good to note here is that the HTTP response will always have the correct content-type header. In our case, the content-type will be application/custom_mime_type!

You can mix variants and formats easily !

Variants are a very powerful feature in Rails. Suppose you want to do a very simple A/B test:

class ArticlesController < ApplicationController
  def show
    @article = Article.find(params[:id])
    request.variant = [:a, :b].sample # always variant a or b

    respond_to do |format|
      format.html do |variant|
        variant.a { @ author = nil } # show.html+a.erb
        variant.b { @ author = @article.author } # show.html+b.erb
        variant.none { head :no_content } # but you can still catch if there is no variant
      end
    end
  end
end

Here we will only return HTML. Depending on the variant declared in request.variant, we can, for example, assign a value to @author.

We always have access to variant.none to be able to perform processing when no variant has been assigned to the request.

Conclusion

The respond_to method is a powerful tool, allowing you to respond to HTTP requests in various formats such as HTML, JSON, XML, CSV, and PDF. We have seen how respond_to can improve the flexibility of Rails applications by handling multiple formats in the same endpoint and setting default actions for unsupported formats.

I hope this article has made you appreciate the respond_to method. Don't hesitate to subscribe so you don't miss my next breakdown of Ruby and Rails.

Binary Decision Tree in Ruby ? Say hello to Composite Pattern 🌳

Just The V — Mon, 01 Jul 2024 07:23:16 +0000

Decision trees are very common algorithms in the world of development. On paper, they are quite simple. You chain if-else statements nested within each other. The problem arises when the tree starts to grow. If you're not careful, it becomes complex to read and, therefore, difficult to maintain.

In this article, we'll see how we implemented decision trees at Wecasa to make them as readable and maintainable as possible.

Before we go any further, let's take some time to define what a Composite is.

What Links Composite and Binary Decision Tree?

Composite is a structural design pattern. It is a way of arranging objects in a tree structure, which allows us to have a logical hierarchy.

When we talk about a decision tree, we can represent it as boxes that can contain boxes, which can contain boxes, which can contain… a final result.

It's precisely this recursive aspect that makes the decision tree so powerful.
Let's take an example. We want to create a decision tree to calculate the amount of the promotion a customer is eligible for on our e-commerce site.

In input, our tree receives a User object with all its attributes.
In output, our tree returns a number.

Each node in our tree has a condition. You can notice by the color code that we have three types of Composites here: Creation Date, Zip Code, and whether the user has already made a purchase. Now that our example is set, let's see how this translates into code!

Firstly, we need tools !

In our implementation of the decision tree, we will need three classes:

The Node Class: The base class for all other classes. Its purpose is to encapsulate the common logic for all different Nodes in my tree.

class Node
  attr_accessor :left_node, :right_node

  def call(user)
    raise NotImplementedError
  end

  private

  # this method is used to ease composites definition
  def call_with_condition(user)
    if yield
      left_node.call(user)
    else
      right_node.call(user)
    end
  end
end

The Leaf Class: Its purpose is to end the tree. You can find them as bottom nodes without any child nodes. The only job they have to accomplish is to return the value they encapsulate.

class Leaf < Node
  attr_accessor :value

  def initialize(value)
    self.value = value
  end

  def call(_)
    value
  end
end

The Composite Classes: Their role is to contain the condition to guide between the success branch and the failure branch, to proceed to the next step in the algorithm. They also contain a method to set arguments. We will see later why this method is useful.

class CreationDateComposite < Node
  attr_accessor :days

  def initialize(left_node, right_node)
    self.left_node = left_node
    self.right_node = right_node
  end

  def call(user)
    call_with_condition(user) do
      self.days.ago > user.created_at
    end
  end

  def set_days(days)
    self.days = days
    self
  end
end

class ZipCodeComposite < Node
  [...]
end

class HaveBoughtComposite < Node
  [...]
end

I only show CreationDateComposite so you understand the logic, no need to show the rest.

How We Finally Manage to Create a Binary Decision Tree

Thanks to all the classes we have built, we will now create our first complete tree. Here is the proposed implementation:

class PromotionTree
  # We use Singleton because we don't need to rebuild the tree
  # everytime we call the class
  include Singleton

  TREE = CreationDateComposite.new(
    ZipCodeComposite.new(
      BoughtComposite.new(
        Leaf.new(60),
        Leaf.new(150)
      ),
      BoughtComposite.new(
        Leaf.new(30),
        Leaf.new(100)
      )
    ).set_zip_code('75'),
    BoughtComposite.new(
      Leaf.new(30),
      ZipCodeComposite.new(
        Leaf.new(75),
        ZipCodeComposite.new(
          Leaf.new(78),
          Leaf.new(0)
        ).set_zip_code('78')
      ).set_zip_code('75')
    )
  ).set_days(7).freeze

  def call(user)
    TREE.call(user)
  end
end

And now we can simply use the tree :

user = User.last
PromotionTree.instance.call(user) # => 60 🎉

That being explained, this implementation offers several benefits:

No if-else mixed in my business logic: By encapsulating conditions in separate objects, we have a clear separation of responsibilities. Each condition is handled by a specific composite, making the code more readable, elegant and maintainable.
Centralization of conditions in separate objects: This allows easy reuse and modification of conditions without touching the main application logic. Conditions can be changed or extended by creating new composites or modifying existing ones thanks to OOP.
Ease of testing: Each component of the decision tree can be tested in isolation, simplifying the unit testing process. Tests can focus on specific conditions without having to simulate the entire decision tree.
Extensibility: Adding new conditions or modifying existing conditions is simple and straightforward. Just create new composite nodes and insert them into the existing decision tree.
It's easy to build a new tree: Let's say tomorrow I want to build a new kind of tree. I always have all my Nodes ready to be used.

But apart from this, I can see some downsides :

The setup cost is High: I think it's not that pertinent to use this if you setup this kind of architecture if you don't plan to create other trees.
It uses recursion: The limit of your tree will be the limit of your Stack Size. So if your tree is bigger than your allowed stack size, you won't be able to use it. Fortunately, this value is quite big : 10867 for my setup. But it can depend on your setup !
You need to get into the habit to read it quickly: At first it's kinda disturbing. The fact that we need to read on the top the Composite, and the bottom the value it used is quite weird. But don't be afraid of this syntax, I will publish another article to show you how I implemented a DSL for Tree building based on this architecture.

Conclusion

Using Composite to implement decision trees allows us to structure our conditions in a clear and maintainable way. Rather than getting lost in a maze of nested if-else statements, we have a logical hierarchy of decisions, each node playing a well-defined role.
Thank you for reading. I invite you to subscribe so you don't miss the next articles that will be released.

Why Kernel#times is slower than while ???

Just The V — Sat, 11 May 2024 23:35:29 +0000

Recently, I came across an article titled “Ruby might be faster than you think” In this article, John Hawthorn revisits the code snippet from the CrystalRuby README and optimizes it to show that Ruby is just as performant, if not more, than the alternative presented by CrystalRuby.

I understood everything in the article except for one part. The author replaces the use of Kernel#times with a while loop, and this change almost halved the code execution time.

Seriously??? Halved? If it was that simple and dumb, why am I not putting while loops everywhere now?

So, I quickly replicated his Benchmark to check the discrepancy, and more importantly, to see how significant it is.

I run this benchmark:

require 'benchmark/ips'

def fib_while(n)
  a = 0
  b = 1
  while n > 0
    a, b = b, a + b
    n -= 1
  end
  a
end

def fib_times(n)
  a = 0
  b = 1
  n.times { a, b = b, a + b; nil }
  a
end

Benchmark.ips do |x|
  x.report('while loop') { fib_while(30) }
  x.report('times loop') { fib_times(30) }
  x.compare!
end

And to my surprise, I got this output:

$ rbenv local 3.2.0 && ruby iterations.rb

Warming up --------------------------------------
          while loop    88.145k i/100ms
          times loop    88.970k i/100ms
Calculating -------------------------------------
          while loop    871.169k (± 0.9%) i/s -      4.407M in   5.059392s
          times loop    885.111k (± 0.6%) i/s -      4.448M in   5.026107s

Comparison:
          times loop:   885110.9 i/s
          while loop:   871169.3 i/s - 1.02x slower

I’m devastated. We’ve been lied to. I test several combinations of the Benchmark, but nothing changes. Locally, both methods are completely equal in terms of performance.

Well, fortunately, I finally understood.

The problem was with my Ruby version. I was running my Benchmark on Ruby version 3.2.0. Here’s the output once the same script was run on 3.3.0:

$ rbenv local 3.3.0 && ruby iterations.rb

Warming up --------------------------------------
          while loop   212.807k i/100ms
          times loop   109.784k i/100ms
Calculating -------------------------------------
          while loop      2.133M (± 0.8%) i/s -     10.853M in   5.087899s
          times loop      1.103M (± 3.2%) i/s -      5.599M in   5.080973s

Comparison:
          while loop:  2133283.8 i/s
          times loop:  1103244.8 i/s - 1.93x slower

🤯🤯🤯

Wow. That’s a significant difference! So all this time, John Hawthorn was running his benchmark on Ruby version 3.3.0. He could have told us!

Proud of this discovery, it led me to a question. How does the impact of versions really affect performance? And especially, what is the state for versions prior to 3.2.0?

I then take the oldest version I have locally on my computer and test it:

$ rbenv local 2.7.1 && ruby iterations.rb

Warming up --------------------------------------
          while loop    26.937k i/100ms
          times loop    20.069k i/100ms
Calculating -------------------------------------
          while loop    269.869k (± 0.1%) i/s -      1.374M in   5.090573s
          times loop    200.938k (± 0.1%) i/s -      1.024M in   5.093709s

Comparison:
          while loop:   269869.1 i/s
          times loop:   200938.2 i/s - 1.34x slower

The performance gap between version 3.3.0 and 2.7.1 is astonishing.

But then comes a question, why is it so much faster in 3.3.0 compared to 3.2.0?

The answer: ✨YJIT Compiler✨

Without going into details, the use of YJIT drastically increases the performance of our while loop. From what I understand, while loops are much more predictable in terms of execution path, allowing YJIT to be very efficient.

In conclusion, if you want your Ruby application to be efficient, keep it updated!

How I manage to optimize my Active Admin in 4 simple tricks

Just The V — Sun, 07 Jan 2024 14:13:14 +0000

ActiveAdmin is a commonly used tool for creating admin interfaces in Ruby on Rails applications. It's incredibly useful for quickly setting up an admin interface focused solely on the data you want to display. However, we often encounter pages that make numerous SQL requests and take a long time to load.

Today, we're going to look at three things I always do to optimize my ActiveAdmin views.

Data Set Presentation
Introduction to ActiveAdmin
Filters
       1️⃣ Always Use Custom Filters
       2️⃣ Preload Your Own Collection and Cache It
Index
       3️⃣ Preload Data in Your Controller
       4️⃣ Preload Data in Your View
Results
       Server-Side Rendering:
       Rack-mini-profiler:
Conclusion

Data Set Presentation

To illustrate our examples, let's imagine that you need to integrate an admin interface for a temp agency.

You will have 4 tables:

A table to store clients who pay to find temporary workers (Owner)
A table to store all your available temporary workers (User)
A table to store all the missions (Mission)
A table to store all the mission shifts (MissionShift)

create_table "users" do |t|
  t.string "email"
  t.string "first_name"
  t.string "last_name"
end

create_table "owner" do |t|
  t.string "name"
end

create_table "missions" do |t|
  t.string "description"
  t.string "title"
  t.bigint "client_id", null: false
end

create_table "mission_shifts" do |t|
  t.bigint "mission_id", null: false
  t.date "day"
  t.datetime "begin_time"
  t.datetime "end_time"
  t.bigint "user_id"
end

The relationships are :

A User have many MissionShifts.
A MissionShift belongs to a Mission.
A Mission belongs to an Owner.

That being explained, let’s dig into our use case !

Introduction to ActiveAdmin

Our goal is to use ActiveAdmin to create our admin interface as quickly as possible. You want a page that displays:

The names of the missions
The client to whom the mission belongs
How many MissionShifts are staffed with a User

By reading a bit of the documentation, you discover ActiveAdmin's wonderful DSL.

You quickly come up with this code:

ActiveAdmin.register Mission do
  index do
    selectable_column
    column :title
    column :owner
    column('Mission Shifts') do |mission|
      mission_shifts = mission.mission_shifts
      "#{mission_shifts.count(:user_id)}/#{mission_shifts.size}"
    end
    actions
  end
end

Which results in this:

You're ready to conquer the world with this admin page!

Yet, you should know that this page contains 3 sources of N+1 queries. To prove this, we'll use the “rack-mini-profiler” gem. This gem allows you to trace the server's path while rendering the page.

Here's a screenshot of what rack-mini-profiler shows us:

We have 148 SQL calls in the view 😲. That's huge!

Looking at the server side, here's the information we get when loading the page:

Completed 200 OK in 741ms (Views: 455.5ms | ActiveRecord: 266.5ms | Allocations: 1035126)

The page takes a lot of time to load and allocates a huge amount of memory!

The purpose of this article is to show you how to significantly reduce these SQL calls and memory allocation, thereby optimizing the time it takes for the page to render and reducing memory leaks!

Filters

1️⃣ Always Use Custom Filters

The first tip I'd like to share today is well-known. It doesn't solve our N+1 issue, but it greatly reduces the memory allocated by the page:

Never leave the default filters on!

In fact, ActiveAdmin tries to be helpful and generates filters for all attributes of your table.

If you have many attributes, it's hard to navigate.
If you have relationships with other models, ActiveAdmin will preload the entire ActiveRecord collection. In our case, we have the Owner and MissionShift models included by default.

Always specify at least one filter:

ActiveAdmin.register Mission do
  filter :title

  [...]
end

Here's the server-side rendering when I load the page:

Before the modification: Completed 200 OK in 620ms (Views: 422.9ms | ActiveRecord: 186.0ms | Allocations: 928758)
After the modification: Completed 200 OK in 581ms (Views: 403.4ms | ActiveRecord: 168.0ms | Allocations: 703878)

There's a huge difference in memory allocation!

2️⃣ Preload Your Own Collection and Cache It

If you still want a filter for a Model, write your own query to load the data:

ActiveAdmin.register Mission do
  filter :owner, as: :select, collection: lambda {
    Owner.pluck(:name, :id)
  }
  [...]
end

Here's the server-side rendering when I load the page:

Completed 200 OK in 666ms (Views: 337.9ms | ActiveRecord: 316.7ms | Allocations: 761030)

It's still better than with the default filters.

If you want to go even further in optimization, you can also set up a caching logic like this:

ActiveAdmin.register Mission do
  filter :owner, as: :select, collection: lambda {
    Rails.cache.fetch('owners_name_id', expires_in: 1.hour) do
      Owner.pluck(:name, :id)
    end
  }
  [...]
end

This gives us:

Completed 200 OK in 816ms (Views: 531.6ms | ActiveRecord: 248.3ms | Allocations: 711373)

In terms of allocation, we've come a long way!

Index

On our index page, we have two problems:

Displaying the Owner column
Displaying the number of MissionShifts that have a User per Mission

To summarize how ActiveAdmin works, for each line, it makes 3 SQL queries:

One to find the Owner
One to find the MissionShifts
One to count the MissionShifts that have a User

As you can see, all our N+1s are actually concentrated here.

The only way to solve our issues is by preloading as much data as possible. For this, we have two ways:

Preload the data in the controller
Load the data once and memoize it in the view

3️⃣ Preload Data in Your Controller

ActiveAdmin allows us to create our own controller methods. So far, we have only played with the #index method, so if we want to preload data, this is the place!

Let's modify our file to preload the Owner data directly from the controller:

ActiveAdmin.register Mission do
   [...]
  index do
    [...]
    column('Owner') do |mission|
      owners.fetch(mission.owner_id)
    end
    [...]
  end

  controller do
    # before loading anything, we preload Owners

    def index
      @owners = Owner.pluck(:id, :name).to_h
      # call for the initial index method
      super
    end
  end
end

If we look at the rack-mini-profiler, we get this:

We have reduced our database calls by ~30. Why this number? Well, as we have the same Owner multiple times on different Missions, ActiveAdmin kept the call in cache and pulled out the information rather than making a new request.

This technique works well unless you have a large volume of data in the Owner table. If you want to optimize a bit more, you can also use the cache. And if you want to optimize even further, you can reuse the cache we set up together in the filters to use the same values twice on the page.

4️⃣ Preload Data in Your View

Preloading data in the controller is good, but we might load too much. The Mission table has a larger volume than Owner, so we can't afford to preload the entire table. Unfortunately, we don't know which Missions will be loaded on the page at the controller level.

But there is one place where we do know which Missions are displayed: in the view!

In other words:

ActiveAdmin.register Mission do
  index do
    column('Sample Column') do
      missions.count # => 50
    end
  end
  controller do
    def index
      pp missions.count # => NameError - undefined local variable or method `missions' for #<Admin::MissionsController:0x000000000a4128>:
      super
    end
  end
end

Let's use this to our advantage!

Our goal is to preload the number of MissionShifts with a User as well as the total number of MissionShifts per Mission.

The first step is to find a query to preload this data for a set of Missions:

class Mission < ApplicationRecord
[...]
  # will output missions with "id", "total_shifts" and "shifts_with_user"
  def self.mission_shifts_with_users
    self.left_joins(:mission_shifts)
        .select(:id,
                'COUNT(mission_shifts.id) AS total_shifts',
                'COUNT(DISTINCT CASE WHEN mission_shifts.user_id IS NOT NULL THEN mission_shifts.id END) AS shifts_with_user')
        .group('missions.id')
  end
end

We want to use this query in our view so that we only have to look up our mission in it and extract the information we need.

ActiveAdmin.register Mission do
[...]
  index do
    [...]
    column('Mission Shifts') do |mission|
      @missions_with_mission_shifts ||= missions.mission_shifts_with_users
      mission_shifts = @missions_with_mission_shifts.find { |m| m.id == mission.id }

      "#{mission_shifts.shifts_with_user}/#{mission_shifts.total_shifts}"
    end
  end
end

By using memoization, we only make the query once, and it is usable for all our Missions.

If we take a tour of rack-mini-profiler, we get:

We have eliminated almost 100 database calls by preloading the data for Owners and MissionShifts.

Results

Here are the results with all the tips applied:

Server-Side Rendering:

Before: Completed 200 OK in 741ms (Views: 455.5ms | ActiveRecord: 266.5ms | Allocations: 1035126)
After: Completed 200 OK in 200ms (Views: 187.3ms | ActiveRecord: 5.9ms | Allocations: 517789)

Memory allocation was halved.

The response time is around 200ms (which is acceptable).

Rack-mini-profiler:

Before:

After:

The numbers speak for themselves, only 6 SQL queries compared to 148 before. It's a huge gap for the performance of your applications.

The important indicator to look at is the % in sql, which we reduced from 15.6% to 3.5%, a huge difference!

Conclusion

In conclusion, this article demonstrated how to transform an initially heavy and inefficient ActiveAdmin interface into a significantly more effective and faster version. Thanks to four simple yet powerful tricks, we drastically reduced SQL queries, improved memory management, and optimized loading time. These improvements are not just technical gains; they translate into a smoother and more professional user experience. For Ruby on Rails developers using ActiveAdmin, these methods offer a concrete way to enhance the performance of their applications while maintaining the ease and speed of development that this gem offers.

What is the fastest way to remove data using Rails ?

Just The V — Thu, 28 Dec 2023 20:13:46 +0000

Efficient data record deletion is a crucial consideration for high-traffic Rails applications. In this article, we will explore various deletion methods using ActiveRecord.

Our mission today is to delete an entire section of our database. Our work will impact 3 tables: Accounts, Missions, and Tasks.

An Account has several Missions, and a Mission has several Tasks.

Our goal is to delete all Accounts, Missions, and Tasks as quickly as possible!

1. Dataset 💽
2. Deletion Methods 🗑️
       1. #destroy_all
       2. #in_batches(of: 1,000).destroy_all
       3. #delete_all
       4. #truncate
       5. Add on_delete: :cascade on the foreign key
3. Benchmark 🥊
       Interpretation of Results
       Recommendations

Dataset 💽

For today's benchmark, we will start with a classic scenario of a two-level has_many relationship.

Here is the database schema we will be using:

# db/schema.rb
create_table "accounts", force: :cascade do |t|
  t.string "first_name"
  t.string "last_name"
  t.string "phone"
  t.string "email"
  t.string "role"
  t.datetime "created_at", null: false
  t.datetime "updated_at", null: false
  t.index ["email"], name: "index_accounts_on_email", unique: true
end

create_table "missions", force: :cascade do |t|
  t.bigint "account_id", null: false
  t.string "name"
  t.date "due_date"
  t.datetime "created_at", null: false
  t.datetime "updated_at", null: false
  t.index ["account_id"], name: "index_missions_on_account_id"
end

create_table "tasks", force: :cascade do |t|
  t.bigint "mission_id", null: false
  t.string "title"
  t.text "description"
  t.string "status"
  t.datetime "created_at", null: false
  t.datetime "updated_at", null: false
  t.index ["mission_id"], name: "index_tasks_on_mission_id"
end

To see how the data is generated, you can access my repository.

In my Models, I default to the following configuration, with dependent: :destroy

(We will discuss the different possibilities later)

# app/models/account.rb
class Account < ApplicationRecord
  has_many :missions, dependent: :destroy
end

# app/models/mission.rb
class Mission < ApplicationRecord
  belongs_to :account
  has_many :tasks, dependent: :destroy
end

# app/models/task.rb
class Task < ApplicationRecord
  belongs_to :mission
end

Deletion Methods 🗑️

Let's look at all the methods we will compare today

1. #destroy_all

The destroy_all method is a common approach for deleting records using ActiveRecord. It instantiates each record and calls destroy individually, triggering associated callbacks. It's generally the slowest approach, but also the safest to use.

Account.destroy_all

Since all Models have their dependant: :destroy relationship, destroy_all will trigger by callback the deletion of Missions associated with the Account we want to delete. But, as we delete a mission, we will also delete all the associated Tasks.

It's hassle-free, but very slow!

2. #in_batches(of: 1,000).destroy_all

I see a lot of ideas that deleting records in batches increases performance. In fact, it can reduce memory load and improve execution time.

Account.in_batches(of: 1,000).destroy_all

3. #delete_all

The delete_all method deletes records from the database without going through ActiveRecord validation. So, we have no validation or callback. This means that data deletion will be refused at the database level, as integrity will be lost.

Therefore, we must conscientiously order the deletion as follows:

Task.delete_all
Mission.delete_all
Account.delete_all

In theory, this method is much more efficient than any use of destroy

4. #truncate

The truncate method is a radical approach that deletes all table data in one operation.

Account.connection.truncate_tables('accounts', 'missions', 'tasks')

If you are sure you want to delete all of your tables, this will always be the fastest way to delete your data. However, it is impossible to scope the data; it will really reset your table.

5. Add on_delete: :cascade on the foreign key

There is a way to delete your tables much more quickly by adding a cascade parameter to your foreign key.

For this, we need a migration:

# db/migrate/20231227130700_add_delete_cascade.rb
class AddDeleteCascade < ActiveRecord::Migration[7.0]
  def change
    remove_foreign_key :missions, :accounts
    add_foreign_key :missions, :accounts, on_delete: :cascade
    remove_foreign_key :tasks, :missions
    add_foreign_key :tasks, :missions, on_delete: :cascade
  end
end

This will transform the declaration of our foreign key in the schema as follows:

# db/schema.rb
add_foreign_key "missions", "accounts", on_delete: :cascade
add_foreign_key "tasks", "missions", on_delete: :cascade

What does this change?

Now, when we delete an Account with #delete, all records that depend on this Account will also be deleted. It's like a callback, but entirely managed by the database. This technique is very efficient! The only problem is that records deleted by the cascade are not logged.

Benchmark 🥊

For the benchmark, we will delete the same set of data each time, which contains:

100,000 Accounts
500,000 Missions (5 per Account)
1,500,000 Tasks (3 per Mission)

All this makes us a nice total of about 2M records. Let's see together which method is the most efficient!

Method	Average (s)	Min (s)	Max (s)
#destroy_all	412	386	443
#destroy_all with batches	515	492	551
#delete_all	7	5	10
#delete_all on top of a database cascade	4.7	2.9	7.7
#truncate	1.8	1.2	2.5

Well, the first thing to say is that clearly, #destroy_all and #destroy_all with batches are clearly behind the others!

Here is the graphical representation of the 10 trials that were conducted for the 3 fastest methods:

So here is the ranking, very predictably:

🥇#truncate

🥈#destroy_all on top of the cascade

🥉#destroy_all

truncate is therefore much more efficient than the other competitors. This result is not surprising, as, as mentioned earlier, truncate will delete the table all at once.

Interpretation of Results

The benchmark results reveal significant differences between data deletion methods in a Rails application. Let's take a closer look at each method:

#destroy_all

With an average of 412 seconds, #destroy_all proves to be the slowest method. This slowness is due to the instantiation of each record and the execution of associated callbacks, which creates an additional burden.
#destroy_all with batches

Surprisingly, this method, with an average of 515 seconds, is even slower than the classic #destroy_all. Although it is supposed to be more efficient in theory thanks to batch management, the results indicate that batch processing can, in some cases, worsen performance.
#delete_all

Significantly faster with an average of only 7 seconds, #delete_all avoids the costs associated with ActiveRecord callbacks and validations. However, it requires careful management of the deletion order to maintain data integrity.
#delete_all on top of a database cascade

With an average of 4.7 seconds, this method proves even more effective. It takes advantage of cascade deletion triggers at the database level, offering a quick and direct way to manage dependencies.
#truncate

By far the fastest method with an average of 1.8 seconds. As it resets tables without regard to individual records, #truncate offers unmatched performance, particularly suited to scenarios where the entirety of a table's data needs to be erased.

The graphical representation clearly confirms the superiority of #truncate in terms of speed, followed by methods based on the database cascade, and finally the #destroy_all approaches.

Recommendations

Considering the results, here are the recommendations for choosing the appropriate deletion method depending on specific needs:

For a secure and controlled deletion: Use #destroy_all. Ideal when callbacks and validations are crucial for data integrity and business logic.
For total deletions without integrity constraints: Prefer #truncate. This method is recommended in test scenarios or when you need to completely reset a table.
For optimized performance with integrity constraints: Consider #delete_all with a cascade parameter on foreign keys. This approach is suitable when data integrity is managed at the database level and ActiveRecord callbacks are not necessary.
In any case: Avoid #destroy_all with batches.

In conclusion, data deletion in Rails applications requires a balance between efficiency, security, and data integrity. This benchmark reveals that each method has its distinct advantages: #destroy_all ensures secure deletion despite its slowness, #delete_all optimizes performance while managing data integrity at the database level, and #truncate stands out for its unmatched speed in complete resets.

In the end, the choice of the appropriate method should be guided by the specific needs of your application and the technical compromises it implies. A deep understanding of these options is crucial to maintaining a balance between performance and reliability in managing your Rails application's data.

Forem: Just The V

Handbook to migrate your Postgres from Heroku to Kamal

Table of Contents

Add Postgres to Production

Edit deploy.yml

Edit secrets

Edit database.yml

Setup Postgres for Preprod

Edit deploy.preprod.yml

Edit secrets

Edit database.yml

Migrate the database

Download the backup

Upload the backup to S3

Run the migration script

Conclusion

Deploy your Preprod and Production Rails Application using Kamal

Prepare your Preprod environment

Install Kamal

Setup Prod

Setup Preprod

Ressources

Conclusion

📩My journey to send 100 mails to 500k effortlessly📩

Table of Contents

The Mail

V1: Deliver Now (up to 300 emails)

V2: Deliver Later (up to 100,000 emails)

V3: Perform All Later (up to +500,000 emails)

Other possible alternatives I explored

Monkey Patching Application Mailer

Using the Mail Provider’s Native Bulk Send

Using BCC

Conclusion

🚩Effortless Feature Management in Rails : A Guide to Using Flipper with Active Admin

Table of Contents

Feature Flags Management

Use a Feature Flag in Your Code

How I Integrate Flipper UI in ActiveAdmin

1. Only Admins have access to Flipper UI

2. Flipper UI must be accessible on the Admin Panel

3. Admin Panel must be accessible on the Flipper UI

Conclusion

Make your Rails App Configurable in 4 Ways

Introduction

Table of Contents

1. Constants

Explanation

Pros

Cons

When to Use It?

2. Configuration File

Explanation

Pros

Cons

When to Use It?

3. Configuration Model

Explanation

Pros

Cons

When to Use It?

4. Variable Model

Explanation

Pros

Cons

When to Use It?

TL;DR

Conclusion

The easiest guide to generate PDF📜 using Prawn in your Rails project

Table of Contents

What is Prawn?

Managing the Cursor

Managing Tables

Let’s build something together!

Pros and Cons of Using Prawn

Pros

Cons

Conclusion

9 things that 🚨Rubocop🚨 don’t want you to use

And / Or Operators (Style/AndOr)

What exactly is `respond_to`?