DEV Community: Nemwel Boniface

Rails Authorization Beyond Models: Securing Dashboards and Service Controllers with CanCanCan

Nemwel Boniface — Fri, 06 Feb 2026 08:44:00 +0000

Hello friends! I’m back with more Ruby on Rails concepts I refreshed this week to stay productive and avoid the social media "doom scroll." 2026 is the year we kill the bad habits hindering our potential, and for me, that means trading the doom-scroll for the docs.

Introduction - Authentication and Authorization. What are these?

Authentication and authorization are often confused, and many people think they are the same, but they are not. Similarly, their ease of implementation is often confused. You might think they are easy to integrate. But are they really? Let me explain.

Authentication, which is verifying who you are, is the easy part. A quick Devise gem install and a migration, and your system knows its users.

Authorization, which decides what they can do, is where the mess begins. Most of us start with CanCanCan basics: you add load_and_authorize_resource to a PostsController, and magic happens. Admins edit, users read. Life is good.

But what happens when you have a controller that doesn't map neatly to a database table? Think about a DashboardController or a SearchController. There is no "Dashboard" table in your database.

Suddenly, the magic breaks and reality sinks in. You start getting confusing error messages or, even worse, silent security gaps that only appear once a user accidentally accesses classified data.

In this article, we’ll explore how to handle authorization when you need to step outside the standard model framework, specifically using tools like authorize_resource class: false to keep your "non-model" controllers secure.

The Foundation: The Rulebook (Ability.rb)

Before we touch our controllers, we have to understand the Source of Truth. In CanCanCan, your app/models/ability.rb file is the rulebook. Everything we do in the rest of the app is just asking this one file a single question: "Is this user allowed to do X to Y?". Let me show you the anatomy of one below:

class Ability
  include CanCan::Ability

  def initialize(user)
    user ||= User.new # guest user

    if user.admin?
      can :manage, :all
    else
      # Scenario A: Database Model Permission
      # Users can manage their own posts
      can :manage, Post, user_id: user.id

      # Scenario B: Abstract Permission
      # Users can read the dashboard, even though there is no Dashboard model
      can :read, :dashboard 
    end
  end
end

Pay close attention to Scenario B. Notice how we defined that permission using a symbol (:dashboard) instead of a class name like Post. In Rails, we are used to everything being linked to a database table. But here, we are telling the rulebook that "Dashboard" is just a concept, a place the user can go. Understanding this shift from Classes to Symbols is the key to solving our future "Model Not Found" headaches.

The "Secure by Default" Mindset

Before we look at specific tools, we need to set a baseline. In a professional application, you shouldn't have to remember to add security; security should be there by default. You should only have to turn it off when you explicitly mean to, in very rare situations. In your ApplicationController, I recommend adding this:

class ApplicationController < ActionController::Base
  # Throw an error if a controller action runs without checking authorization first.
  check_authorization unless: :devise_controller?
end

Think of this as your Authorization Alarm System. If you create a new controller and forget to define any permissions, Rails will yell at you with a CanCan::AuthorizationNotPerformed error, which is much better to have your app crash during development because you forgot a security check than to have it silently expose private data in production. We skip devise_controller? because Devise handles its own "Who are you?" logic, and we don't want to get locked out of the login page!

Now that the alarm system is armed, let me show you how we satisfy it in different scenarios below:

Scenario 1: The Standard CRUD Resource (This is the Happy Path)

Imagine you have a Product model and a standard ProductsController to handle the basics: looking at a list, viewing a single item, or editing details. The Solution would be to add the load_and_authorize_resource at the top of the controller. This will then tell CanCanCan: _"Hey, look at the controller name (Products), find the matching model (Product), load the data into a variable (like@product`), and check the Rulebook to see if this user is allowed to be here."_

You are to use this ideally 90% of the time if your controller maps directly to a database table and performs standard RESTful actions. Example:

The beauty here is Clarity. By moving the data loading and the security check to a single line at the top, your controller actions stay "pure." They only focus on what happens after the door has been opened.

Scenario 2: The "Service" Controller (When there is no Database Model)

This is where the confusion usually starts. You have a controller that performs a service-like a DashboardsController, a SearchController, or a ReportsController. If you check your database, you will find that there is no "Dashboards" table. Dashboard here is just a page that aggregates data from other places.

If you try to use ur favourite load_and_authorize_resource here, CanCanCan will go looking for a Dashboard model, fail to find it, and crash your app because it does not exist. The solution is using authorize_resource class: false.

This tells CanCanCan: "I need to secure this controller, but stop looking for a matching database class. Just check if the user is allowed to access the concept of this controller.". When you set class: false, CanCanCan converts the controller name into a symbol (e.g., DashboardsController becomes :dashboard) and checks your Rulebook for that specific symbol. This is best used whenever your controller represents a concept, a process, or a service rather than a specific row in a database table.
Example (Recall our Ability.rb had can :read, :dashboard.):

If a user tries to access this page without the can :read, :dashboard rule in their ability.rb, they’ll get an "Access Denied" error. With this, you get the same level of security as a standard model, but without the database baggage.

Scenario 3: The Complex or Expensive Action

Sometimes, checking permissions at the very start of a request is too "blunt". Imagine you have an action that kicks off a heavy background job or calls an external API that charges you per request. You ideally don't want to waste any CPU cycles or money until you are 100% sure the user has the right to be there. The solution is the explicit inline authorize!

This is the manual approach, and instead of letting the controller handle security automatically at the top, you take the wheel and tell CanCanCan exactly when and what to check inside the method itself.

Situations when you are supposed to use this include:

When your logic is too dynamic for the standard helpers.
When you need to do some "cheap" setup (like checking params) before doing an "expensive" authorization check.
When your action handles multiple different types of objects at once.

Example usage:

By using authorize! manually, you ensure that your expensive code is protected by a high-security gate. If the user isn't authorized, the method stops right there and raises an exception before the HeavyReportingJob ever gets queued.

Summary and a useful Cheat Sheet

Choosing the right tool comes down to two questions: "Does this match a database table?" and "When do I need the check to happen?"

Scenario	Mapped to DB?	Tool to Use	The "Why"
Standard RESTful (Posts, Users)	Yes	`load_and_authorize_resource`	The magic bullet. Loads data and checks rules automatically.
Service/Concept (Dashboard, Search)	No	`authorize_resource class: false`	Authorizes against a symbol so Rails doesn't look for a missing class.
Complex/Expensive Actions	Maybe	Explicit `authorize!` in the action	Gives you total control. Best for guarding expensive API calls or background jobs.

Conclusion

Doom-scrolling gives you a dopamine hit that lasts five seconds. Solving a tricky authorization bug gives you a secure, professional application that stays protected while you sleep.

By moving past the basic "magic" and mastering tools like class: false and explicit authorize! calls, you stop fighting the framework and start making it work for your specific needs. In 2026, we aren't just building apps that "work"; we are building apps that are secure, intentional, and architected for the long haul.

Next time Rails "yells" at you about a missing model, don't reach for your phone to scroll. Reach for your ability.rb and check if you're trying to authorize a class that doesn't exist.

Do you prefer the "magic" of automated authorization, or are you a "manual control" developer who likes to see every security gate in your code? I’d love to hear your horror stories about AccessDenied errors in the comments!

A Quick Side Note: While I’m heads-down building this search engine, I’m also looking to pitch in on new projects. If you’re looking for a mid-level Rails engineer with solid JavaScript experience who prioritizes security, authorization logic, and building defensive, scalable systems, I'd love to chat. You can find me on [LinkedIn/Twitter] or check out my other work here.

I hope this was useful information for you. See you in my next article.

What Happens When a User Deletes Their Account? A Guide to Rails ActiveRecord dependent: Strategies

Nemwel Boniface — Tue, 20 Jan 2026 06:25:43 +0000

Hello friends! I'd like to show you Ruby on Rails concepts I refreshed this week to Avoid Social Media Doom Scrolling.

Introduction

We’ve all been there. You’re at the end of a high-intensity coding session, or maybe you're in the middle of a Pomodoro break. Your brain is fried, and the easiest "hit" is a social media feed scroll. Suddenly, you're deep into doom-scrolling, watching phenomenal creators like Simon Squibb ask people, "What’s your dream?" (He is honestly my favourite creator right now, and his videos are raw and authentic and a whole vibe! Who’s your favorite creator lately?)

This week, I decided to fight the scroll. I closed the "Trending" tab and opened the Rails Documentation instead. My goal was to master ActiveRecord Association Dependencies.

If you're building a user-centric app, like the "Google-style" search engine I’m currently architecting, you quickly realize that choosing how a record "dies" is just as critical as how it lives. In a search engine that tracks saved queries, leads, and API keys, our strategy has to balance two things: User Privacy (deleting personal data) and Business Continuity (preserving lead data for analytics).

Here is how I structured my models to ensure my database doesn't become a "ghost town" of orphaned records.

1. The Clean Sweep: `dependent: :destroy`

In my app, when a user deletes their account, I want their Saved Searches to vanish. These are private and hold zero value once the owner is gone.

I chose :destroy because it’s the "polite" way to say goodbye. Unlike a cold database delete, :destroy instantiates each record and triggers its specific callbacks. If you have logic that says "Notify the search engine to de-index this query when deleted," this is the only way to ensure that "cleanup" logic actually executes.

class User < ApplicationRecord
  has_many :saved_searches, dependent: :destroy
end

2. The Bulk Cleanup: `dependent: :delete_all`

Sometimes, you don’t need a polite goodbye; you need raw speed. Imagine a user has millions of Audit Logs. Calling :destroy would try to load every single log into Ruby memory, a surefire way to crash your server or hang your database.

:delete_all skips the Rails middleware entirely. It sends a single, sharp SQL command directly to the database. This, however, has a Trade-off: If your AuditLog has a before_destroy hook that cleans up a file on Amazon S3, it will not run. Use this only for "passive" data where speed is the priority over side effects.

class User < ApplicationRecord
  # If we had millions of log entries, we didn't need to process
  has_many :audit_logs, dependent: :delete_all
end

3. The "Legacy" Handover: `dependent: :nullify`

This was the trickiest one for me to grasp, but it’s vital for B2B apps. In our search engine scenario, if a User generates a Lead and then deletes their account, the business still needs that Lead record to calculate conversion rates.

If I delete the lead, I break the business analytics. By using nullify, the user_id on the Lead becomes NULL, but the record itself stays on the "shelf." The user’s privacy is respected (their name is gone), but the business value is preserved.

class User < ApplicationRecord
  has_many :leads, dependent: :nullify
end

4. The Soft Block: `dependent: :restrict_with_error`

I want you to think of this as the "Safety Valve." Sometimes, a user cannot be allowed to leave yet. In my app, if a user has Active API Keys, letting them delete their account would leave external integrations in a broken state.

Instead of a hard crash, :restrict_with_error adds a message to the errors object. This allows me to tell the user in the UI: "You can't close your account while you have active API keys. Please disable them first." It’s a UX-friendly way to protect critical system resources.

class User < ApplicationRecord
  # "You can't leave us while you still have an active API Key!"
  has_many :api_keys, dependent: :restrict_with_error
end

5. The Hard Guard: `dependent: :restrict_with_exception`

This is the ultimate safety net for financial data. I use this for Billing Subscriptions. If the system attempts to delete a user who still has an active billing record, Rails will raise a hard ActiveRecord::DeleteRestrictionError.

This isn't for a "nice UI message." This is for your "Security-First" logic, a last line of defense to ensure your financial integrity is never compromised by a stray user.destroy call.

class User < ApplicationRecord
  has_many :billing_subscriptions, dependent: :restrict_with_exception
end

Short Recap

When a user leaves, not all data should be treated the same. Privacy, performance, and business continuity pull in different directions. Pick :destroy when cleanup must run, :delete_all for raw speed, :nullify to keep business artifacts, and :restrict_with_* to block dangerous deletions.

Conclusion

Doom-scrolling gives you a dopamine hit that lasts five seconds. Solving a database integrity problem gives you a stable application that lasts years.

By strategically picking between :destroy, :nullify and :restrict, I’ve ensured that my system handles user churn like a pro. My advice? Next time you’re bored, don't check the "Trending" tab. Check your schema.rb. There is always a relationship that could be handled more gracefully.

Which dependent strategy do you find yourself reaching for most often? Are you a "Clean Sweep" developer who keeps a pristine database, or do you lean heavily on :nullify to protect business analytics? I’d love to hear how you handle the "afterlife" of your data in the comments!

A Quick Side Note: While I’m heads-down building this search engine, I’m also looking to pitch in on new projects. If you’re looking for a mid-level Rails engineer with solid JavaScript experience who cares about building defensive, scalable systems, I’d love to chat. You can find me on [LinkedIn/Twitter] or check out my other work here.

I hope this was useful information for you. See you in my next article.

Architecture Backwards: Engineering a Self-Defending System Before the UI Arrives

Nemwel Boniface — Fri, 09 Jan 2026 07:28:31 +0000

Happy New Year!

As we kick off 2026, many of us are starting new projects or refining old ones. This year, I’ve decided to challenge the "industry standard" of MVP development. Instead of racing to build a login page, I’m spending my time in the trenches of the core engine.

Introduction

In the rush to launch a Minimum Viable Product (MVP), the standard advice is almost always: Start with the User. Build the login page, the profile, and the "Join Now" button. We often prioritise Authentication and Authorization, then move to the core logic, the actual reason the product exists, nearly as an afterthought.

This approach works, and it’s the industry standard. But what if I tell you there’s a more resilient way to architect a system? One that isn't as glamorous or visually aesthetic, but is infinitely more stable?

Lately, I’ve been building a new system where I’ve intentionally flipped the script. I am working backwards, starting with the "brain" of the engine rather than the face of the app. I am two weeks into development, and I haven't even touched a User module. Instead, I’ve spent my time building Self-Defence Mechanisms and Telemetry.

Hear me out, while authentication and authorisation in your system is vital, we have battle-tested gems like Devise and CanCanCan that can be dropped in later and will solve this for you in minutes. The core health of your system, however, cannot be "dropped in" as an afterthought and therefore needs a complete system architecture shift. Here is why the most scalable systems are built from the inside out using what I call the Sensor & Suitcase pattern, which I will introduce in the second section below.

1. The "Horizontal" Nature of Users

When working with a modern Ruby on Rails application, the User resource can be treated as a horizontal layer. I want you to think of the User layer as the front door to your house. It’s how people get in, and it’s what they see first. But before I invite guests over, I want to make sure the foundation is solid and the electricity is wired correctly. Because Rails emphasises Convention over Configuration architecture, adding a user_id to a record later is often just a simple migration away. I have the expensive luxury of treating "Identity" as a pluggable module because the framework and the core language, Ruby, are designed for developer happiness. I am actually happy working with this stack for the project.

However, when we talk about the core engine, the part that actually does the work, this should be seen as vertical. If that engine is fragile, it won't matter how many users you have or how beautiful your login page is.

If your core system cannot handle the "real world" problems that come with scale, such as race conditions, API rate limits, or cache stampedes, the system will collapse under the weight of its own success.

1.1 The Tortoise and the API

This might feel like a re-invention of the story of the Hare and the Tortoise. The "Hare" approach is to race toward a UI, a "Join Now" button, and a beautifully designed user dashboard. It looks fast, but it’s tripping over every unhandled exception along the way.

By building "Backwards," I am the Tortoise. I am building a system that knows how to protect itself first. I am ensuring that when the "Hare" (the User) finally arrives, the ground beneath them is solid, monitored, and reinforced.

2. Building the "Defensive By Design Perimeter."

Before a single user is able trigger any request through my new system, I needed to know that the system will protect its most expensive resource: External API Credits!

I am making use of what is called the Sensor & Suitcase pattern. By implementing the Sensor & Suitcase pattern, we shift the architecture from being reactive (fixing things when users complain) to proactive (handling failures before the user even notices).

Here is why this "Backwards" approach is a game-changer for your system:

1. Total Visibility (The Sensors): Most developers fly blind until an error log hits their inbox. By using ActiveSupport::Notifications to broadcast every “heartbeat”, you create a "Black Box" recorder for your app. Remember that a heartbeat is any user-defined activity and can be something like a user requesting a resource from my system. This way, you aren't just guessing how the system performs; the system is telling you exactly where it feels strain in real-time.

# The following snippets of code and all that follow are  
# intentionally simplified to communicate architectural  
# intent rather than production-ready implementations.
# Implementation of the 'Sensor' within the service layer
def fetch_resource(query, location)
  # Wrapping the core logic in a 'Sensor' block
  ActiveSupport::Notifications.instrument('<Module name>::external_call', {
    query: query,
    location: location
  }) do |payload|
    result = <Module name>::Client.execute(query, location)

    # Enrich the sensor data with metadata for real-time telemetry
    payload[:status] = result.status
    payload[:duration_ms] = result.duration

    result
  end
end

2. De-risking Through Isolation (The Suitcase): External APIs are often the "chaos variables" of web development. By packing those risks into SolidQueue background jobs, you decouple your app’s success from an outsider's failure. If a third-party service hangs for 10 seconds, your user doesn't see a spinning loading icon; they see a finished task because your "Suitcase" is handling the heavy lifting in the background.

# The 'Suitcase' - Isolating external volatility from the main request thread
class <Module name>::IngestJob < ApplicationJob
  queue_as :external_api

  # Defensive retries with exponential backoff to handle provider downtime
  retry_on <Module name>::ExternalError, wait: :exponentially_longer, attempts: 3

  def perform(signal_id)
    signal = <Module name>::Signal.find(signal_id)

    # Perform the 'heavy lifting' away from the user's eyes
    <Module name>::Ingestor.new(signal).call
  rescue StandardError => e
    # Log the failure for the 'Black Box' recorder
    <Module name>::Telemetry.record_failure(e)
    raise e
  end
end

3. The "Snappiness" Factor: In a Rails 8 monolith, speed is often about what you don't do during the request-response cycle. This pattern strips the main thread down to its bare essentials, ensuring your UI stays lightning-fast while the complex logic executes safely behind the scenes.

The Core Benefit here is that you aren't just building a feature; you are building a self-healing perimeter. Your system defends its own performance metrics, regardless of how the outside world (or the user) behaves.

3. Solving the "Thundering Herd" Problem

One of the most satisfying parts of this "Backwards" approach was preparing for a "Thundering Herd" before it ever happened. This refers to the moment when multiple requests hit your system at once for the same resource.

Usually, this is where most systems start to show off their glamorously covered-up cracks. In a situation where 10 users request the same data at the exact same millisecond, a standard app might fire off 10 expensive, redundant calls to an external API.

However, by focusing on the "Self-Defence" layer first, I solved this before a single user ever signed up on my system. I used atomic increments in Redis and PostgreSQL row locking to make the system smarter. Now, when those 10 requests hit at the same time, the system identifies the "herd" and performs one expensive API call, while the other nine requests simply wait for a heartbeat to share that single result.

Instead of 10 separate stresses on the engine, it’s just one. This is the difference between a panicked crowd and an organised queue.

# Utilizing PostgreSQL Advisory Locks to organize the 'Herd'
def find_or_create_resource(query, location)
  # Create a unique lock key based on the specific search parameters
  lock_key = Digest::SHA256.hexdigest("#{query}:#{location}")

  # Ensure only ONE process handles the expensive external call
  <Module name>::Database.with_advisory_lock(lock_key) do
    # Re-check cache inside the lock; the first worker filled it already
    return cached_result if cached_result.present?

    # This is the single 'Tortoise' worker performing the expensive API trip
    execute_expensive_external_call(query, location)
  end
end

4. The Admin-First Dashboard

Because I haven't spent a single minute working on a "User Profile" page, I had the time to build something much more valuable: a Telemetry Dashboard.

Right now, this dashboard isn't for a customer; it’s for the system (and, okay, it's for me to geek out on until I go live! xD). Instead of looking at user avatars or bios, I am looking at the "System’s Efficiency." I’ve built a metric I call the Vault Ratio. This metric tracks how many requests are served from the "Vault" (my local, optimized data) versus how many require a slow, expensive trip to an external API.

By seeing these numbers move in real-time, I can tune the engine while it’s still on the workbench. I’m not guessing if my caching strategy works; I’m watching the "Vault" grow stronger every day. By the time the first user signs up, they aren't entering a construction site; they are stepping into a fully furnished house.

# The core logic behind the Telemetry Dashboard
def today_snapshot
  date = Date.current
  {
    discovery_requests:  <Module name>::Metrics.read('discovery.requests', date),
    cache_hits:          <Module name>::Metrics.read('discovery.cache_hits', date), # Local Rails cache
    vault_hits:          <Module name>::Metrics.read('discovery.vault_hits', date), # Persistent optimized data
    external_calls:      <Module name>::Metrics.read('discovery.external_calls', date), # Expensive credit usage
    signals_created:     <Module name>::Metrics.read('signals.created', date)
  }
end

The Lesson I have learned so far: Embrace the trenches

In the past, I was always afraid of staying in the backend trenches for too long. There is a constant pressure to "show progress" through UI and buttons. But if there is one thing I’ve learned from systems that I didn’t architect well in the past, it’s this: Don’t be afraid to stay in the back-end longer than it feels comfortable.

Remember the story of the tortoise and the hare. The slow, intentional pace you take now is what prevents the dreaded 3:00 AM headaches down the line.

When you build an engine that is self-defending and observable from day one, adding the "User" front-facing layer isn't going to be a stressful launch; it will be just a normal Tuesday. This approach gives you the confidence to sleep soundly, whether your system is handling 10 users or 10,000 users concurrently.

Conclusion

As a parting shot and a last word of advice from an engineer implementing best software practices that help global businesses thrive, to build software that helps businesses truly thrive, we have to prioritize the "brain" over the "face." Focus on your system’s core logic and bulletproof it first. Make it exist, make it resilient, and then make it pretty.

The users might not see the Redis locks or the background workers, but they will certainly feel the stability.

Is the "Sensor & Suitcase" pattern something you or your team would consider for your next project? I’d love to hear how you handle the "Defensive" side of your builds in the comments!

A Quick Side Note: While I’m heads-down building, I’m also looking to pitch in on new projects. If you’re looking for a mid-level Rails engineer with solid JavaScript experience who cares about building defensive, scalable systems, I’d love to chat. You can find me on [LinkedIn/Twitter] or check out my other work here.

I hope this was useful information for you. See you in my next article.

Building a Custom Audit Trail in Ruby on Rails Without PaperTrail

Nemwel Boniface — Thu, 21 Aug 2025 11:14:21 +0000

Introduction

Auditability in a system is a key feature, and having a way in which you can do that in your application will definitely help a lot. In your system, you need to know who did what, who created what, updated what, deleted what, and when this was done. Please note that for deletes, it is not a hard delete but a “soft” delete option whereby you have a boolean field maybe called “Archived,” which is set to false by default and set to true when you press to delete it (Archive it).

While I know there exist gems that can do this for you, such as the papertrail gem, you may want to reduce the number of dependencies in your application by coming up with your own custom maker checker. This involves adding fields in your database table, such as created_by, deleted_by, modified_by, etc. Look, hear me out, this may sound counterintuitive to add a created_by field, but the aim of making a maker checker is to add all the needed fields.

Prerequisites

Ruby v 3+
Rails V 7/8
Rails app with Devise for Authentication
Some experience with Rails MVC

Let's get started:

Assume that you have a table called modules. To add the auditable fields, run the following migration to create a migration file that we will update below:

rails g migration AddAuditFieldsToModules

Update your migration file to look like the one shown below:

class AddAuditFieldsToModules < ActiveRecord::Migration[7.2]
  def change
    change_table :modules do |t|
      # Audit fields
      t.references :created_by, type: :uuid, foreign_key: { to_table: :users }
      t.references :modified_by, type: :uuid, foreign_key: { to_table: :users }
      t.references :deleted_by, type: :uuid, foreign_key: { to_table: :users }
      t.datetime :deleted_on

      # Archive status
      t.boolean :archive_status, default: false, null: false

      # Indexes
      t.index :archive_status
      t.index :deleted_on
    end
  end
end

Run rails db:migrate to update your Schema file.

The next step would be to create a Current model inside app/models/current.rb, which inherits from ActiveSupport::CurrentAttributes and update it as follows:

class Current < ActiveSupport::CurrentAttributes
  attribute :user
end

The Current class file is needed to provide a thread-safe way to access the current user (or other request-specific attributes) throughout your application, particularly in models where you normally can't access controller-level information like the current_user devise helper method. By using ActiveSupport::CurrentAttributes, it creates a globally accessible but request-specific storage that your Auditable concern can use to automatically track who created, modified, or deleted (In our case, a delete is actually an archive) records. This maintains clean separation of concerns while ensuring your audit trail always captures the correct user, whether the action originates from controllers, background jobs, or other parts of your application. The Current pattern is the Rails-recommended way to handle this cross-cutting concern without polluting your models with controller logic.

Our next step will be creating an auditable concern module inside app/models/concerns/auditable.rb file and add the following code to it:

module Auditable
  extend ActiveSupport::Concern

  included do
    # Associations
    belongs_to :created_by, class_name: 'User', optional: true
    belongs_to :modified_by, class_name: 'User', optional: true
    belongs_to :deleted_by, class_name: 'User', optional: true

    # Scopes
    scope :active, -> { where(archive_status: false) }
    scope :archived, -> { where(archive_status: true) }

    # Callbacks
    before_create :set_created_by
    before_save :set_modified_by
  end

  # Instance method for archiving
  def archive!
    update(
      archive_status: true,
      deleted_by: Current.user,
      deleted_on: Time.current,
      modified_by: Current.user
    )
  end

  # Instance method for unarchiving
  def unarchive!
    update(archive_status: false, modified_by: Current.user)
  end

  private

  def set_created_by
    self.created_by ||= Current.user
    self.modified_by ||= Current.user
  end

  def set_modified_by
    return unless !new_record? && Current.user
    self.modified_by = Current.user
  end
end

Ok, ok, I know that this may seem like a lot, but we are mostly done now, you can relax.

The Auditable concern provides automatic tracking of record authorship and changes through a complete audit trail system. It adds three user associations (created_by, modified_by, deleted_by) to any model that includes it, along with scopes for filtering active/archived records. Using Rails callbacks, it automatically stamps records with the current user (via Current.user) during creation, updates, and soft deletion (archiving). The concern also provides explicit archive! and unarchive! methods that handle soft deletion while maintaining referential integrity and a complete change history. This creates a self-contained audit system that tracks the complete lifecycle of records while keeping the implementation DRY and consistent across different models. The soft delete functionality preserves data by setting an archive_status flag rather than physically removing records.

In case you may still need a way to perform a hard delete, you can extend the functionality by adding this to your Auditable concern. Please note that this may be counterintuitive, as the record will no longer be there. So, setting the "deleted_on" or "deleted_by" will not be there as the record will be gone.

# Callbacks
    before_destroy :set_destroyed_by

  def set_destroyed_by
    self.deleted_on = Time.current
    self.deleted_by = Current.user
    self.archive_status = true # Archive when destroyed
  end

Inside our module.rb model file, we shall add the following to first include the auditable module, including all its functionality, adding it into our module model class, and using the scope to create a query shortcut that automatically filters for non-archived records.

# Auditability concern
  include Auditable

Our setup is mostly complete, and you do not need to make any changes to your controller logic and The only place you need to make changes is in your destroy action, as shown below, which instead of performing an actual hard delete, calls the archive method, which we defined in our auditable concern earlier:

def destroy
    @module.archive! # Soft delete / archive
    respond_to do |format|
      format.html { redirect_to modules_url, notice: "The Module '#{@module.name}' was successfully deleted." }
      format.json { head :no_content }
    end
  end

So, why are we re-inventing the wheel?

So, why would someone want to use this approach as opposed to using pre-existing gems such as PaperTrail?

Eliminating dependencies caused by using gems. While some gems are very useful, some may stop receiving updates, which may mean, further down the line, you may be forced to migrate to a custom auditability form or move to another gem
It is in line with the native Rails way of doing things; you probably don't need those gems if you can implement it custom. Such a custom approach is generally faster than using PaperTrail by upto 2-3 times, reducing the amount of “magic” happening in your code.
There is complete transparency of what is going on, what is being collected, and how everything works. This is unlike when using a gem, and there is some “magic’ that happens behind the scenes, and you do not fully understand how it works in the first place.
To have control over the data you want to collect/ track in your system. While some gems are very useful for a quick fix for data collection, some may be designed to collect an excessive amount of data, which may not be needed and may definitely increase the database costs. Customization allows you to collect the least amount of data, only the ones that you need, and nothing more.
This approach incorporates query efficiency in situations where you would like to know who did what; you just get it in the table columns instead of doing complex queries, making your application data load faster.
For scenarios where you are using cloud storage, this will help you to avoid using cloud offerings such as AuditLog, which charges per event. This in place saves on costs for the company.

When it is better to use existing solutions:

While the pros of a custom approach are undeniable, there exist scenarios where you may need to use pre-existing gems as opposed to a custom solution like ours:

It may be a regulatory Requirement for the company. For example, healthcare systems bound by HIPAA may require complete object versioning with cryptographic signing of all changes.
In situations where you need to perform cross-model Search in your system. This occurs when you need to search audit trails globally.
In a situation where you need a Full Change History in your system. Gems such as PaperTrail have reify for undo functionality
When a separation of concerns is needed. This is where the production database and the audit database are in two separate databases, keeping everything neat and maintainable.

Areas for Improvement (What Could Be Better)

While this approach is clean and avoids extra dependencies, there are several considerations to keep in mind if you want to make it production-ready:

Sometimes your system performs certain tasks, such as background jobs, where in such scenarios, there usually isn’t a current_user value, and it will be nil, which would make auditing hard. In such situations, assigning such changes to a dedicated System user account when no explicit user is available would be a safe workaround. For example:

def set_created_by
    # Assign the system user if no current user is present
    user = Current.user || User.find_by(email: 'system@yourdomain.com')
    self.created_by ||= user
    self.modified_by ||= user
  end

When working with Rails APIs and you are exposing some of the audit fields, such as created_by or modified_by, directly through JSON APIs, you may unintentionally leak personal information (e.g., user IDs, emails). From a compliance standpoint, you may need to consider whether those fields should be public, anonymized, or restricted to admin roles.

Alternatives & Extensibility

Just as Rails has some best practices for using the framework effectively, below are my best practices rules, which I highly recommend considering when choosing to have a custom audit mechanism for your application, may it be a custom audit tooling or a ready-made software:

It is best to focus on capturing the changes, and not just actors: While I am aware that my current approach only records who changed a record, but not what they changed, I would recommend extending the functionalities with a changes_log JSON column or an associated audit_logs table that stores the changes made.
Embracing database-level auditing: databases such as PostgreSQL offer native auditing solutions using triggers or extensions such as pg_audit, which are battle-tested solutions that can help you to log all operations at the database layer.
KISS (Keep it simple, stupid) and choose a hybrid approach of just recording “who/when” directly in your model (just as in my demonstrated examples), combined with a dedicated audit log table or external log system for mission-critical changes.

Auditing may feel daunting at first. However, knowing what amount of data you want to collect is the first step. Don’t sweat it.

Conclusion

The choice ultimately depends on your application’s specific requirements. However, using the custom approach as I have demonstrated is an excellent fit for most mid-sized applications, prioritizing maintainability and performance.

If you need a lightweight, Rails-native auditing functionality, this approach works perfectly well. However, if you need full versioning, support for cryptographic trails, or cross-model searching capabilities, it would be better to stick with PaperTrail or database-level solutions.

I hope this was useful information for you. See you in my next article.

How to Automate Daily Task Emails in Rails using Whenever and Cron

Nemwel Boniface — Wed, 16 Jul 2025 06:49:51 +0000

Background

I have been working on a task assignment system where one of the tasks I need to do is to send everyone at the end of the work day stats of what tasks they had at the start of the work day and what tasks they have been able to close and if there are any new tasks that they were assigned during that work day. Initially, I created a manual method to send emails to them by using a button that I had to click at the end of each workday. This approach worked perfectly well. However, in situations where I was not there physically to click the button to send out the daily tasks reports to all users, this quickly became an issue for me, and coming up with a way to automate this process is no longer an option, but mandatory. This is where the Ruby Whenever gem comes in.

Introduction: Whenever Gem

Whenever Gem is a Ruby DSL(domain-specific language) for managing Unix-style cron jobs. It translates your Ruby syntax into actual crontab entries that your system can use and understand. As a result, it works reliably on Unix-based systems (Linux, macOS). Still, it is not compatible with Windows unless you use a Unix-like environment (such as WSL) or adapt your jobs to Windows Task Scheduler.

The Gem provides a clear syntax for writing and deploying cron jobs. A cron job is a time-based job schedule that allows users to automate tasks by scheduling commands or scripts to run at specific times/ intervals. The scheduled tasks are known as cron jobs and are all defined in a configuration file known as the crontab. A cron is a daemon that runs in the background and checks the crontab file for scheduled tasks to run. Remember that a daemon is a computer program that runs in the background, performing tasks without direct user interaction.

What are schedulers?

Schedulers are components that trigger certain tasks at specific intervals (hourly, daily, weekly, etc). Schedulers operate in the background, outside of the request/ response lifecycle (You do not run them when a user visits your website).

While Rails does not have a native (inbuilt) scheduler for arbitrary cron-style jobs, we have options for using Background jobs using ActiveJobs + Sidekiq. Or asynchronous work and making use of external scheduler tools (such as whenever + sidekiq-scheduler) for repeating jobs.

Prerequisites:

Rails V7
PostgreSQL database
Ruby V 3+
Preferred web browser
Visual studio code
Some experience with Rails MVC architecture

Installing the Whenever Gem

Installing the whenever Gem and configuring it to work is fairly straightforward in Ruby on Rails. To install the whenever gem, add the following to your GEMFILE and run bundle install to install the package to your application.:

gem 'whenever', require: false

Optionally run the following in your terminal:

bundle add whenever

Then run the command wheneverize . to create the schedule.rb file inside the config/ directory. This step is very crucial as the schedule.rb file is where you define your cron jobs using Ruby DSL syntax (e.g., every :day, at: '5:05pm'). Without this file, the whenever gem has no instructions to generate crontab entries.

If you would like to follow along with me through the article, I created this GitHub repository which you can clone to test out the setup.

Real world practice: Sending out an email every weekday at 5:05 pm

This is a relatable situation where you may want to automate the process of sending out emails every workday at 5:05 pm. To do this, we will first create a mailer. In your terminal, head over and type:

rails g mailer DailyMailer

This generates a file in the app/mailers/ directory called daily_mailer.rb, which we are going to open so that we can edit it by adding the following to it:

Class DailyMailer < ApplicationMailer
  def daily_email
    mail (to: "user@gmail.com", subject: "My update"
  end
end

The next step will be to create a view inside the app/views/daily_mailer/ directory called daily_email.html.erb adding this line: <h1>Hello! This is your daily update at 5:05 pm </h1> to it.

We shall then create a Rake task inside the lib/tasks/ creating the file called email.rake, using the command touch lib/tasks/email.rake, and open it to edit it as follows:

namespace :email do
  desc "Your daily email"
  task send_daily_email: :environment do:
    DailyMailer.daily-email.deliver_now
  end
end

We shall now run the command: rails email:send_daily_email, to test out our current setup.

How the Automation Flow Works

Before we test locally with Letter Opener, let’s visualize the full workflow:

Key Steps showcased in the flowchart include:

schedule.rb which defines the cron schedule in Ruby (e.g., "Weekdays at 5:05 PM").
crontab system converts this into a background process.
Rake Task which executes your custom logic (e.g., querying tasks).
Mailer which formats and sends the email.
Letter Opener (Dev) / SMTP (Prod) which handles delivery of your email.

Integrating the email send automation with the Whenever Gem

We are now going to ensure that after every work day at 5:05 pm, users can receive an email sent to them. Open the config/schedule.rb file and inside it add:

every :week, at: '5:05 pm', on: [:monday, :tuesday, :wednesday, :thursday, :friday] do
  rake "email:send_daily_email"
end

To be able to check the output, run the command whenever in your terminal. In case nothing happens on your end, not to worry. It means that you do not have any SMTP server configured, and this is where we will resolve it in the next section of the article, the letter_opener gem.

Local testing using the letter_opener gem

In case you do not have an email SMTP setup locally, we will use the letter_opener Gem that catches any email that we want to send. Instead of trying to connect to an SMTP server, it renders the email in our browser and is an amazing tool for testing, as it will show your email like an HTML page for you. This means that:

We do not have to configure an email server
We can see and test emails quickly
We do not send any actual emails over the internet

If you are following along upto here, right now when we try to send the email by connecting to localhost:25, it fails because we do not have an SMTP server configured locally. But with the letter opener gem configured, when our app tries to send an email using the mail() or deliver_now(), letter opener intercepts it and saves it as an HTML page. Then it automatically opens the page in your browser for you. The letter opener gem inline allows you to test your mailer easily, with no error messages, no ECONNREFUSED, and you can review your email layout. Amazing right?

How to use the letter opener gem

You will add the gem 'letter_opener' to your Gemfile in the development group, and run bundle install. Open the config/environments/development.rb file and edit it to add the following configurations:

config.action_mailer.perform_deliveries = true
config.action_mailer.delivery_method = :letter_opener
# Don't care if the mailer can't send.
config.action_mailer.raise_delivery_errors = false

# Disable caching for Action Mailer templates even if Action Controller
# caching is enabled.
config.action_mailer.perform_caching = false

config.action_mailer.default_url_options = { host: "localhost", port: 3000 }

These settings configure Action Mailer to actually send emails in development mode, preview them in the browser using the letter_opener Gem, suppress delivery errors, disable caching for email templates, and generate proper URLs using localhost:3000 as the base. Amazing right?

Once this has been done, run: rails email:send_daily_email in your terminal. If you have followed along so far, your default email browser will be opened, and you will see something similar to what I have below.

Up to this point, it will load the email in the browser as expected. The application will no longer attempt to connect to localhost:25 (SMTP port) and will instead open your browser.

Up to where we are, we have been able to test out our setup, and we all validated that it works perfectly fine.

Notes about the letter_opener gem:

Is not for production, it is a tool for development testing alone
Helps you test and view emails quickly without sending them explicitly over an SMTP network
Fixes the connection refused error for local testing

Considerations while using the whenever and the letter_opener gems

When you update the schedule.rb file, and you run the command whenever, Rails will automatically assume RAILS_ENV = production by default. So, when you run whenever without specifying any flags, it shows you the schedule tasks for production and not for development. This may mean that you are not going to see any output and you may think that your setup is all wrong. Luckily, we have a few work a rounds for this and below are some options to use when testing out in development mode. See attached screenshot below as an example.

Remember that running the whenever command is essential because it converts your human-readable schedule written in Ruby (in schedule.rb) into raw cron syntax that your system understands. Without this step, your defined jobs won’t actually get scheduled (We mentioned that whenever doesn't run jobs itself. It simply tells your operating system when and how to run them by updating the crontab). If you skip this step, your background jobs will never run, no matter how well your Rake tasks or mailers are written.

To fix this, we have a few options, starting with the temporary option, which is running the command shown below which will allow you to preview the schedule for development environment.

whenever --set environment=development

The other solution will be:

whenever --update-crontab --set environment=development

To explicitly set the environment in the schedule.rb file at the top of the schedule.rb file, you will add the following:

set :environment, "development"
set :output, "log/cron.log"

After adding this to our schedule.rb file, we will need to run the command whenever --update-crontab With the flag --update-crontab because running whenever alone simply previews what the generated cron entries would look like but it does not install them. To actually schedule your tasks, you must run whenever --update-crontab, which writes those entries into your system's active crontab.

To confirm whether this was successful run crontab -l in your terminal. If you were s, you should see something like:

Always remember that: the whenever Gem does not send emails itself, it just tells your OS (using cron) to run the command at a specific time. In our case, we want it to run every time at 5:05 pm every workday. The cron service will run RAILS_ENV=development bundle exec rake email:send_daily_email

Conclusion

Technology exists to help us work faster and focus on what truly matters. Let it handle repetitive, automatable tasks like sending daily emails at specific times so you can focus on building smarter systems.

By using the whenever gem together with letter_opener, we’ve implemented a powerful and practical scheduling pattern. With this setup, we’ve removed human dependency from a critical workflow and learned how to safely test scheduled jobs in a development environment without the need for a live email server.

This one marks the end of the step by step guide on automating tasks using Whenever Gem and Cron. What will you be automating next in your systems? I would love to hear about that.

I hope this was useful information for you. See you in my next article.

Stimulus.js Explained: A Beginner’s Guide for Ruby on Rails Developers

Nemwel Boniface — Mon, 10 Feb 2025 07:26:10 +0000

Introduction

Hello friends!

We all have to agree on one thing, JavaScript is the king of the web. It is very true that it is the undisputed language that powers over 98.7% of websites, making it the dominant language for web interactivity. You can get so far with plain HTML and CSS when working on your websites. You will however want to have some reactivity on your website. Imagine without JavaScript in your website, you may not be able to implement features such as changing content on the DOM.

As Ruby on Rails developers, we often prefer server-side rendering for speed and SEO benefits and at all costs, we try to reduce the reliance of JavaScript on our applications and rely on server-side rendering of content and sending it to our views to be shown to the client side. This has multiple advantages as this approach allows for pages to load quickly and be indexed by search engines without requiring JavaScript to render content. This is however still limiting and thus need for JavaScript to add that pop to our application reactivity.

This is where Stimulus.js comes in. It is a lightweight JavaScript framework that adds interactivity to HTML designed to enhance static or server-rendered HTML by connecting JavaScript objects to elements on the page using simple annotations. Let this not be confused with Turbo, Turbo focuses on enhancing client-side interactivity by handling page updates, while Stimulus is more focused on managing client-side behavior and adding interactivity to HTML elements.

This article will give you a general overview of Stimulus, covering its features, explain why Stimulus is useful, especially in Ruby on Rails, and give a comparison with other libraries such as React or Jquery. In a future article, we will cover how to set up and use Stimulus in your Ruby on Rails applications.

Stimulus JS deep dive

We earlier mentioned about JavaScript objects. In Stimulus, these JavaScript objects are called controllers. Stimulus uses data-controller attributes to continuously monitor the pages. For each attribute, Stimulus looks at the attribute’s value to find a corresponding controller class, creates a new instance of that class, and connects it to the element. I would like you to think of it this way: just like the class attribute is a bridge connecting HTML to CSS, Stimulus’s data-controller attribute is a bridge connecting HTML to JavaScript.

Stimulus JS core concepts

Stimulus JS builds on controllers with three key concepts: actions, targets, and values. Let’s discuss the further:

1.Actions, which connect controller methods to DOM events using data-action attributes. Actions allow you to specify what action to take when eg a button is clicked. As an example, assume that you have a controller called hello_controller that has a method called greet, and you would like to connect that greet method to an HTML button, your action would look similar to this:

<button data-action="click->hello#greet"> Greet </button>

where the data action is a click event and that maps it to the greet method in the hello controller.

2.Targets, which locate elements of significance within a controller. Assuming that you have an input field and you would like when you click the button, the value that is in the input field will be captured and that value will be used somewhere else, this is where the data-<controllerName>-target attribute comes in. For example, we have our input field, we may want to reference this value as follows:

// Our views
<div data-controller="greet">
  <input type="text" data-greet-target="name" placeholder="Enter your name">
  <button data-action="click->greet#sayHello">Say Hello</button>
  <p data-greet-target="output"></p>
</div>

// Hello controller
import { Controller } from "@hotwired/stimulus";

export default class extends Controller {
  static targets = ["name", "output"];

  sayHello() {
    this.outputTarget.textContent = `Hello, ${this.nameTarget.value}!`;
  }
}

In the code shown above, the Stimulus controller "hello" defines the nameTarget and the outputTarget to reference the HTML input and paragraph. It then updates the paragraph with a greeting message when the button is clicked.

3.Values, allow you to store and update dynamic data within a Stimulus controller using the data-* attributes. They automatically sync between the HTML and JavaScript, making it easy to manage dynamic data inside Stimulus controllers without manually handling DOM updates. A good example is using values to create a counter that increments or decrements when a button is clicked.

Phew! That was almost a lot of technical content on Stimulus JS, right? Ok, let's take it easier now.

Why anyone should be using Stimulus.js in their applications

We have so far seen what Stimulus is, and had an understanding of its core features. But why should you want to use it anyway? Let’s explore more below:

Can help you with basic interaction enhancement. Take an example of when you want to implement a toggle button functionality in your website.
Form input handling. A great example is the sample I shared earlier when covering the stimulus js concepts (Actions, targets, values).
Fast and lightweight. As compared to similar libraries such as React, it is lightweight and minimal making sure that your application does not experience any lags due to heavy packages.
It has a seamless integration with Ruby on rails. Stimulus is designed to easily work with Ruby on Rails, especially alongside Turbo, and does not affect the existing backend structure.
Has automatic element identification - uses data-targets to reference elements within a controller, reducing the need for manual document.querySelector calls and keeping JavaScript neatly organized.
Stimulus allows for progressive enhancement of your web applications' client views. It works on top of server-rendered pages, thus ensuring that the core functionality remains intact even if JavaScript is disabled, This improves accessibility and SEO of the web pages.

Despite using Stimulus.js showing real tangible benefits to our applications, they also have some serious considerations that are worth factoring in when using Stimulus over other libraries such as React or Vue.

Stimulus may not be well suited for applications that are very complex and need single page (SPA) functionalities. If your app requires complex state management, virtual DOM updates, or client-side routing, you may need a framework like React or Vue.

The fact that Stimulus is tightly coupled with HTML and relies heavily on the data-* attributes in HTML, leads to having the code become cluttered if not managed properly. This is especially true in large applications.

While this might not be necessarily true for everyone, however, the syntax that Stimulus uses is not really intuitive at first glance and requires additional reading to try and have a grasp of the syntax to understand the moving parts. This extra layer of complexity might not really suit everyone and they may find it hard to start working on it quickly.

One of the determining factors of the use of a tool is usually the community behind it. Unlike other libraries such as React, Stimulus has a relatively smaller community backing it which would bring a challenge in finding resources or even help when you run into a challenge. You however need not worry because I am here to bridge that gap! 😄

Conclusion

Just like any tool out there, it has its strengths and its weaknesses. In my own opinion, Stimulus is an amazing tool that I believe everybody should be using especially in their Rails applications to add some reactivity to their pages. Stimulus features such as reusable components make it an attractive tool allowing you to define a feature once and reuse it multiple times allowing you to stick to programming principles such as DRY and KISS.

In my next article, we shall go deeper into the technical bits covering a practical demonstration of how to use Stimulus JS in your Ruby on Rails applications.

That wraps up this introduction to Stimulus. I hope you found it insightful, and I look forward to sharing a hands-on guide in the next article.

Mastering Code Reviews: The Ultimate How-To Series

Nemwel Boniface — Mon, 28 Aug 2023 10:43:29 +0000

Introduction

Hello friends!

Picture this, assigned a certain amount of features to implement. how will you know that the code submitted by them is functioning according to the given project requirements? You check it! This is where the code review process kicks in.

This will be a multiple series where I aim to teach you all you need to know about code reviewing. In this article, I will teach you what we mean by code review, why code review is important, what are the qualities of a good code review, what makes up a good code reviewer, list down some drawbacks associated with the code review process, and wrap it up with a conclusion. In a later article, I will do a hands-on tutorial on how to make use of the GitHub review features available to perform a code review.

At the end of the series, you will be more equipped to start making reviews for your peers and add code reviewing as a skill under your belt.

Sounds interesting right? Let's dive straight in!

What do we mean by Code review?

Code review in software engineering means the systematic, collaborative, and iterative process in which one or more developers examine code written by team members scanning for errors in the code to assess whether that submitted code does exactly what it is supposed to do as per the provided project requirements.

Code review is collaborative since it involves at least two people, the author of the code and another person who reviews the code. It is systematic since to perform a meaningful code review, there needs to be a set standard followed to approach the code review process. It is also iterative since if there are errors found, the code will be sent back for revisions and when done put back into review. This process is repeated until the code satisfies the provided project requirements.

Why is the code review process important?

Code review is one of the most important steps in the software development lifecycle. So what are the advantages that you will accrue from doing code reviews?

For your junior developers in your team, code review facilitates the transfer of knowledge and helps them to learn faster. This is because as they collaboratively receive feedback on their code from their peers or the seniors, they can learn new ways of doing something or why implementing features differently is better.
It serves as a bug detection avenue that might have been missed by the written tests for the project. This is because the code reviewer will generally be someone who is knowledgeable and has some understanding of the future implications of not re-writing a code block and rectifying it during the code review process.
We often have the "Make it work optimize later". Code review helps to eliminate code that is unreadable or unnecessarily complex making it unmaintainable. It is here where that complex code will be rewritten when you are provided with suggestions of how to better approach an issue. This will in turn make the code readerable and maintainable.
Code review ensures consistency of the whole code base. This is because different organizations have different ways in which they structure their code. This is always enforced during the code review process where any code that is not up to the company's standard is returned to the author and changes are required.
Code review enhances the interaction and collaboration of the different team members. This is because different people might be the ones to review your code and in this way, you get to interact with different people within the organization.

What are the qualities of a good code review?

We have to acknowledge that anyone can give a code review. However, we have to ask ourselves, was the review given of quality? Below are some of the pointers for a good code review:

One that is provided promptly. It would not be good if you had to wait for a long time to receive a review of your code. Remember that time is of the essence when creating software and you would be required to also start working on another feature which requires that this feature be approved.
One that is thorough and does not miss some of the important aspects. It would hurt if you received few changes to make in the first review and when you submit your code for a re-review, the code reviewer introduces new issues that were not mentioned in the first review. One that is constructive and does not deviate from the project requirements. The reviewer needs to raise issues in the code that are actionable and not guessed issues.
One that uses respective language and tone and acknowledges your efforts so far. We all make mistakes and the best you can do is to be respectful to someone when you are suggesting changes. This would make the one who is to make the changes respected and acknowledged and will make the changes with enthusiasm.
One that offers a learning opportunity. This depends on the kind of changes that will be requested and the approach that will be used by the reviewer which will either help the junior developer learn by offering constructive feedback or break them by adding unrealistic changes to be made.

What makes up a good code reviewer?

We can all see why code reviews are very important and by now, you might be itching to get your hands dirty reviewing your friend's code. But wait! Do you have the qualities required to become a good code reviewer? Let's see if you possess any of the below qualities. A good code reviewer is one who:

Has strong communication skills. Remember that when performing a code review, you will be explaining to someone, "This code is great, but it has some issues. Here is a suggested way to fix it, and here is why you should consider making this change".
Has a strong technical understanding of the underlying technologies being used. You cannot make a code review for something that you do not understand and this is why to become a good code reviewer, you need to have mastery of the underlying technologies to be used.
Is empathetic and patient. The truth is making changes to your code is hard. Most of the time, the author might not be able to implement exactly how it is supposed to be implemented and this is where being empathetic and patient comes into play. You will be better able to accommodate everyone even the least experienced developers in your team.
Is one who can think critically. Making a code review involves assessing the code. It is up to you as the code reviewer to assess whether this submitted code is optimum or might require changes. This is where the skill of critical thinking comes into play.

What are some drawbacks associated with the code review process?

While it is evident that the code review process does have many advantages, it is not always bliss, and like everything, there are drawbacks related to performing code reviews. They include:

Sometimes the code review process can be very time-consuming. This is based on the fact that there could be multiple revisions which take time to both implement changes and re-review.
The code review process could lead to conflicts between team members. When one of the team members feels that the other party is intentionally requesting changes even though the project works perfectly fine that could lead to a lot of conflicts between team members.
Sometimes the code review process could be subjective and might not be objective. Remember that the code review process relies on what someone thinks about a specific code and might not be as objective as someone would want it to be.
With the possibility of making numerous revisions of the code, this would significantly slow down the development lifecycle making it take longer to implement features than they should have taken. This has a direct effect on cost since the longer a project takes to be completed the higher the cost involved in its development.

Conclusion.

From my discussion above, we can see why code reviews are important. We also flipped the other side of the coin and saw the cons that come with the code review process. Would you be willing to do a code review for your peer or suggest it to your team members? Please let me know in the comments section bel

This brings us to the end of the first part of this series. After reading this article, are you able to define what code review is, what are the advantages of performing code reviews, how you can distinguish whether the code review you received was good or not, and for those who are already excited about code reviews, the qualities that would help make them good code reviewers?

Part B of this series will include a practical tutorial teaching you how to perform reviews making use of the GitHub review features. Stay tuned!

If you read till this point, I send a big thank you.

That is it for today's class. I hope this was useful information for you. See you in my next article.

Mastering Technical Writing: A Step-by-Step Guide for Beginners

Nemwel Boniface — Sun, 18 Jun 2023 16:43:03 +0000

Introduction

Hello my esteemed reader! This article is well suited for beginners in technical writing but will still benefit seasonal writers who would like to take their writing skills to the next level. This will be a multiple series where I aim to take you from point A where you know nothing about technical writing to point Z where you write meaningful articles that people actually want to read.

In this short article, I will explain what technical articles are, discuss the characteristics of a good article, extensively explore steps that you can take to write a good article, and conclude with a summary as I answer the question, "are technical articles limited to software related articles alone?".

What do we mean by "Technical articles"?

Technical writing. A huge word that most people get wrong and only associate with software-related articles and publications. However, today I am here to demystify this misconception and explain to you my reader why technical writing is not restricted to software-related articles alone.

For us to understand what this is, we need to have an understanding of what the two terms technical and writing mean. Technical means "relating to a particular subject, art, or craft, or its techniques." anywhere mentioning software? no. The term Writing encompasses the process of documenting ideas, thoughts, or facts. Therefore combining the two, technical writing is the process of conveying complex and specialized information clearly and concisely.

What are the indicators of a good article?

Have you ever read an article and something about it spelled out quality? Well, quality is one subjective term. However, in technical writing, we have standardized indicators of what a quality article is that I will list below:

An article with a purpose and has a target audience. This is an article that clearly defines the scope of the specific article that is being written and has an identified audience beforehand.
An article that combines the written text with visual aids such as images, gifs, and screenshots to further explain a specific concept shedding more light on it by using visuals to arouse more interest.
An article that makes use of relatable examples and analogies. Research has it that when hard concepts are accompanied with an analogy that the readers can relate to, they end up remembering that concept by relating it to the analogy that was used to explain it.
An article that is consistent throughout and has accurate information. Nothing hurts more than an article whose flow seems inconsistent and whose content is misleading.
An article that has been proofread and is free of grammatical and spelling errors.

What are the steps to follow when writing an article?

Anyone can write an article. However, not everyone is able to write a good article. Luckily enough with the right preparation, we can all be able to write resourceful artiles and this will be what will separate your article from the vast majority of sub standard articles published online following the steps highlighted below:

Preparation - they say, given 10 hours to cut down a tree, use 7 hours of that time sharpening your axe and 3 hours to cut it down. This is the step where you get to understand what you are going to write it and why you actually need to write it. It is in this stage where you choose the medium which you will use to relay your thoughts through your article.
Research - before you even start to write about an article, you need to get an understanding of the topic at hand and do an assessment of whether this is something that you are capable of writing about. Here is where you get your hands dirty busy going deep that topic/ domain to get an understanding of it before writing about it.
Organization - with extensive research, comes a monolith of data that will not make sense as information. You need to sit back, organize your thoughts and see what bits of all this raw data combined will lead to a meaningful information for your article.
Once you have your thoughts organized, Writing the article is the next logical step. It is in this step where you jot down your thoughts either on paper or on an online editor that offers grammar and spelling checks such as Grammarly.
The last and final step is to proofread your work. In this step I advice sitting on your article for a few days and asking a friend to proof check your work and this will allow you to have a third eye/ opinion that will help you see if your article has a good thought/ logical flow.

Conclusion

From the steps listed above, it is evident that technical articles are not restricted to software related articles alone. A technical article can be any article written for a specific domain, be it hospitality, engineering or medicine all qualify as technical articles. Therefore when someone says that other articles are not technical articles, please direct them to this article where they will also get enlightened.

This brings us to the end of the first part of this series. After reading this article, are you able to recognize a well researched and written article? Please do let me know in the comment section. In the next article, I shall walk you through how you can develop an appropriate writing style in technical writing and how you can structure your article.

If you read till this point, I send a big thank you.

That is it for today's class. I hope this was useful information for you. See you in my next article.

Implementing Custom Slugs with FriendlyID in Rails: A Step-by-Step Technical Guide

Nemwel Boniface — Mon, 29 May 2023 07:38:21 +0000

Introduction:

Have you ever wondered how applications like Instagram or Twitter use your username as the unique identifier in your browser URL and not the ID of your account?

In the development of applications, the use of eg usernames instead of the ID is called slugging. In programming, slugs are the human readable unique identifying parts of a web address typically at the end of the URL (Uniform Resource Locator).

Using custom slugs for our applications offers many advantages that I will discuss later in the article. Implementing them in our applications is relatively easy and luckily for us who use Ruby on Rails, we get the advantages of using a mature stable framework where many functionalities have solutions that were already implemented for us.

In Ruby on Rails, we have a gem called friendly_id that makes the process of generating human-readable slugs simple by allowing us to replace ids in our URLs with slugs. Using friendly_id gem lets our applications work with friendly URLs eg https://www.my_app/users/nemwelboniface instead of https://www.my_app/users/1.

Typically, the implementation of custom slugs in Rails involves leveraging gems like FriendlyID that streamline the process and offer additional functionalities like resolving slug conflicts and automatically generating easily readable slugs.

Within this article, we shall delve into a comprehensive step-by-step walk through that demonstrates how to implement custom slugs in Rails with the assistance of the FriendlyID gem. My guide will encompass essential aspects such as installation, configuration, migration, and code generation, enabling a seamless integration of custom slugs into your Rails application. By the conclusion of this tutorial, you will possess the necessary knowledge and tools to craft personalized and user-friendly URLs tailored to meet your specific needs.

Let's dive in and unlock the power of custom slugs in Rails!

Prerequisites:

Rails V7
PostgreSQL database
Ruby V 3+
Visual studio code
Some experience with Rails MVC architecture.

Project set-Up

To set up the custom slugs functionality in our application, we need to add the friendly_id gem to our Gemfile and run bundle install.

gem "friendly_id"
bundle install

If you would like to follow along, I created a new branch called friendly_id in this repository where you can follow along with me. If you would like to know how to create a new Rails application, kindly have a look at the first part of this article I wrote.

Our next step will involve adding a slug column to our desired table. In our case, it will be the Users table. Therefore we shall run the following line in our terminal which will create a migration file that adds a slug column to our Users table.

rails g migration AddSlugToUsers slug:uniq

We shall also need to generate the friendly configuration file and a new migration with the following command:

rails generate friendly_id

We are now free to run the migrations to update the schema file with the new columns added by the migration files created.

rails db:migrate

We are going to head over to our Users model inside app/models/user.rb file and add the following:

class User < ApplicationRecord
  extend FriendlyId
  friendly_id :name, use: :slugged
end

With the line for "extend FriendlyId" we are extending the functionalities of the User model with the methods that are provided by the FriendlyId module. This is what allows us to use the "friendly_id" method in the next line.

With the line "friendly_id :name, use: :slugged" this is the line that configures the friendly_id gem for the user model. This is where we specify that the name attribute of the user model should be used as the basis for generating the slugs. The :slugged option indicates that the friendly_id gem should use the slugged module to generate the slug.

Making use of the above means that when a new user record is being created, the friendly_id gem will generate a slug based on the name attribute. The slug is then stored inside the slug column in our user's table.

In addition to the above, let us head back to our user's model inside app/models/user.rb file and create a to_param method. Our User model shall now be like this with all the changes made:

class User < ApplicationRecord
  extend FriendlyId
  friendly_id :name, use: :slugged

  def to_param
    slug
  end
end

This method is necessary when using the friendly_id gem to ensure that our slug is used in the URL instead of the default ID. What it does is overrides the default behavior of Rails when generating URL's for model instances.

By defining the to_param method and returning the slug value, you are instructing Rails to use the slug attribute when generating the URL's for instances of our model.

We are almost done now. We need to make some slight adjustments to our controllers. Head over to our users controller in app/controllers/users_controller.rb file and inside the show action and set_user method, replace this:

@user = User.find(params[:id])

with:

@user = User.friendly.find(params[:id])

What is happening here is we are using the friendly_id gem to find a user's record based on its slug. The params[:id] value is passed in as the argument to the find method. Basically using the friendly.find, the user record will be found based on its slug attribute instead of the ID which is the default behavior of ActiveRecord.

The last step involves running the following in our Rails console:

User.find_each(&:save)

Note that running the above line is only necessary if you're adding friendly_id to an already existing Rails application and you need to generate slugs for already existing users.

What that line does is it iterates over each user's record and calls the save method on them. This triggers the saving process and generation of slugs for each user based on the friendly_id configuration in our user model.

This step is not necessary if you setup friendly_id before creating users in your application. If you find having to run the line in your console application tedius, you have an option of creating a rake task that can be used to automate that process for you. However, this is beyond the scope of what we were to learn in this article. I will however consider writing an article about rake tasks upon request from someone in the comments section.

Pros and cons of using custom slugs

We have covered the technical setup and I believe that so far you have an idea of why having custom slugs in your application is a good thing. Below I will list a few advantages that I have found from using custom slugs in my own applications:

It has helped me to improve the SEO of my applications ten fold as search engines tend to give more weight to keywords in the URL when determining the relevance of a page.
Using custom slugs gives you a human readable URL that gives more context and describes what thet specific webpage you are viewing contains. This rings true especially when creating blogs where you can have th title of a blog as the slug for a blogs show page.
Using custom slugs has given my applications alot of flexibility as the slugs are more flexible and meaningful than numeric ID's. Having keywords in the slugs has really helped users of my applications to identify and remember the contents of webpages that they visited from my application.
Persistence and a sense of security in my application as unline numerical IDs are sequential and predictable by revealing th order in which records were created, having the custom slugs give me a sense of security as they remain consistent even if the record is moved or re-ordered in the database.

Despite using slugs showing real tangible benefits to our applications, they also have some serious considerations which are worth factoring when using custom slugs over the default ID's. You need to ensure that the slugs are unique, they can handle situations where the title or the attribute that is used for the slug is changed and also properly handling URL redirections when slugs are modified.

Luckily for us, in Rails all the above concerns are already handled by the friendly_id gem where the process of handling these edge case is simplified. This is one of the many advantages we get from using a mature and stable framework like Ruby on Rails for development of our applications.

Conclusion

Would you like to use friendly_id in your applications after reading my short article? Please let me know in the comments section below.

This one marks the end of the Step-by-Step Guide: Implementing Custom Slugs with FriendlyId in Rails article guide.

That is it for today's class. I hope this was useful information for you. See you in my next article.

From Theory to Practice: Using Active Storage for File Management in Rails

Nemwel Boniface — Thu, 04 May 2023 09:31:05 +0000

Introduction

Welcome all! As we learned in my previous article, Active Storage is an inbuilt library in Ruby on Rails that simplifies the process of file uploads in our applications.

The fact that it is an inbuilt library means that we do not have to add the active storage gem in our Gemfile to use it, rather we can directly out of the box start to use it.

This is the part B of my Ultimate Guide to Active Storage in Rails series where I aim to teach you all that is required to know about Active Storage. In this part of the series, I aim to walk you through the technical setup of Active Storage and how to use it in our applications. As a bonus, at the end I will show you how you can write your own custom validations to limit the file size of an uploaded file. Part A of the series can be found here.

Prerequisites:

Rails V7
PostgreSQL database
Ruby V 3+
Visual studio code
Some experience with Rails MVC architecture.

If you would like to follow along with me, I created a GitHub repository for this specific tutorial which has all the code that will be listed here. You can find the GitHub repository here and the branch name with the code is "activestorage". If you like, give me a follow!

Project setup

To get started, we are going to create a new rails project which will use PostgreSQL as our database. (PostgreSQL is optional and you can use whichever RDMS you wish to use.) In your terminal, type and hit enter:

rails new activestorage_tutorial --database=postgresql
cd activestorage_tutorial

This command will create a new rails application for us with all the dependencies required to have a fully functional fullstack application in minutes, configured to use PostgreSQL as its database.

Once completed, you need to cd into the new directory and open it with the text editor of your choice. Our next steps will be to update our config for our database to ensure that rails can work with our local PostgreSQL database. Go to config -> database.yml file, edit the development and test blocks and add your username and password. Below is an example:

development:
  <<: *default
  database: activestorage_tutorial_development
  username: nemwel
  password: root

test:
  <<: *default
  database: activestorage_tutorial_test
  username: nemwel
  password: root

our next steps will involve creating our database with rails db:create

Users Resource

We want to implement and test the file upload functionality and we will need to have a User who will have the following properties: name, email, profile_photo, phone_number. In your terminal type:

rails generate scaffold User name email phone_number:integer profile_photo

Below are the files generated by the scaffold:

Note: In rails, all the properties for an object(User) are default type string. Therefore not defining the datatype for eg the name will give it a type of string when the columns are generated. Also, we are using string for the profile_photo field because ACtive Storage will generate urls for each uploaded file which will be of type string. I hope this explains why.

We are using the scaffold to generate the users resource for us which includes a user controller, model, migration, views, test files, and an update to our routes with the user's resource.

Let us update our routes to add a root route to the users(index.html.erb) view on application load. add the following line in your routes file(Config -> routes.rb):

root "users#index"

You can now run the migrations with the command below and start your server with rails s and go to http://127.0.0.1:3000/ in your browser.

rails db:migrate

Setup Active storage

Now that we have our application set up, it is time to setup Active Storage. Go to your terminal and type:

rails active_storage:install

Which will generate three tables as we learned in my previous article, and migrate with rails db:migrate to update our schema.

In our application since a user should only have one profile_photo at any given period, we are going to go to our user model in app -> models -> user.rb file and add the has_one_attached association. Add the following inside our user model:

class User < ApplicationRecord
  has_one_attached :profile_photo
end

Our next step will be to update our views. We want to be able to upload images from our local machines, store them, and retrieve them to display it in our browser.

We shall first update our file upload. Let's go to app -> views -> users -> new.html.erb (If you generated the Users resource with scaffold, the form will not be in this file but can be found inside the _form.html.erb partial). We ideally want to update the input field for the profile photo to a file upload field. Update this:

<%= form.text_field :profile_photo %>

to:

<%= form.file_field :profile_photo %>

that will allow us to upload a file.

Once we can upload files, our next steps should be to ensure that we are now able to display the files that we uploaded. We shall go to app -> views -> users -> index.html.erb (If you generated the users resouce with scaffold, the markup will be found in the _user.html.erb partial instead). We will change the markup for displaying the image to:

<% if user.profile_photo.attached? %>
  <image src="<%= (url_for(user.profile_photo))%>">
<% end %>

We are checking through the active_storage_attachments table to see if there is a profile_photo for this specific user. If such a file exists, create a custom URL for that file that is passed to the image tag.

With that, we have our complete file upload and retrieval all wired up and working as expected.

Additional: some custom validations

Now that we have learned what active Storage is, how to set it up and make it to work, we have not touched on how to ensure the integrity of the files we are uploading.

Imagine a situation where you have limited storage space and you'd like to only allow images that are eg less than 1MB to be uploaded. Ideally, you'd like to have some sort of restrictions on eg the file sizes of the file we are uploading. This is where validations are king and luckily for us, rails provides a way to write our own custom methods.

In our users model, let's add the following:

class User < ApplicationRecord
  has_one_attached :profile_photo

  validate :valid_image

  def valid_image
    return unless profile_photo.attached?

    unless profile_photo.blob.byte_size <= 1.megabyte
      errors.add(:profile_photo, "The image is more than 1MB")
    end
  end
end

In a nutshell, we are using the unless a statement to check if the condition is false. If the condition is truly false, we execute the block of code(In our case, the error message and the image will not be uploaded because the validation failed)

With our above validation set and you try to uload an image whose size is more than 1MB, the following error will be shown:

Conclusion:

I hope that my short article has given you insights on how you can setup and use active storage in your applications and gave you an introduction on custom validations in Ruby on Rails.

This one marks the end of the second series of The Ultimate Guide to Active Storage in Rails. Here, I walked you through the technical set up of Active storage locally in your application and in the last part of the series, I will show you how to link it with Cloudinary to upload your images to an external cloud storage service provider will be coming soon. Be on the lookout for it!

That is it for today's class. I hope this was useful information for you. See you in my next article.

The Ultimate Guide to Active Storage in Rails

Nemwel Boniface — Tue, 25 Apr 2023 17:39:38 +0000

What is Active storage?

When developing an application, you must have faced a situation where you want to include a file upload functionality eg allow your users to upload their profile pictures when they are signing up. Implementing this feature on your own proves to be a cumbersome process and this is where using a mature framework like Ruby on Rails comes to pay dividends.

Active Storage is an inbuilt library in Ruby on Rails that provides an easy way to upload files and associate them with models in a Ruby on Rails application.

It offers an easy way to integrate file uploads from your local machine and store them in both the local disk storage or in external cloud storage service providers such as Cloudinary and simplifies the retrieval and processing of the same files that were uploaded.

Part B of the series is available and can be found here.

Before we continue

While most of us have been rushing to meet our specific needs (Making the file upload functionality work), most of us don't know what constitutes Active storage.

If you're looking to take your Ruby on Rails skills to the next level and learn about working with files, then you've come to the right place. I plan to make this multiple series a one-stop guide for understanding what Active Storage is, its ins and outs, how to setup Active storage in your application covering both file uploads and retrieval to showcase the retrieved file to your screen, and in the last series, I shall walk you through using Active Storage to upload your images to Cloudinary.

This is the first part of the series and in this version of the series, I aim to give an in-depth overview of Active Storage. This article you are reading now covers the theory behind Active Storage and we shall work on the technical setup in our application in part B of the article series.

Active Storage 101

Active Storage makes use of three tables in your application's database namely: active_storage_blobs, active_storage_attachments, and active_storage_variant_records, which are generated when running the command rails active_storage:install to create a migration that will generate the above-mentioned three tables. We shall discuss the three tables in depth below.

1. active_storage_blobs

This table is used to store metadata for the uploaded files where each row represents a record/ file that has been uploaded to your Rails application. The blobs table contains the following columns:

a. id - This is a unique identifier for the blob (file)
b. Key - This is a unique key that is used to retrieve the blob from storage
c. filename - This column contains the original file names of the uploaded files
d. Content_type - This column contains the MIME type of the uploaded file
e. Byte_size - This column contains the size of the uploaded file in bytes
f. Checksum - This column contains a SHA256 hash of the uploaded file. The SHA256 hash is used in Active Storage to ensure the integrity of the uploaded files

2. active_storage_variant_records

This storage is used by Active storage to store the metadata for variant files. In simple terms, the variant files are different versions of a file that has been uploaded and processed by Active Storage to give them a different size, format, or other properties.

When you use Active Storage to process an uploaded file such as resizing images, a new variant file is created and stored in the configured storage service eg local disk storage or an external cloud service such as Cloudinary.

Thus the active_storage_variant_records is used to store the metadata about these variant files including their "variation-digest", which is a unique identifier for the specific processing that was applied to that specific file. This table contains the following columns:

a. id - A unique identifier for the variant record
b. variation-digest - the unique identifier for the processing that was applied to that file
c. blob_id - This is the ID of the original file/ blob that a variant was created from
d. created_at - This is a timestamp for when a variant was first created
e. updated_at - This is a timestamp for when a variant was last updated

Overall, this table allows you to create and store variant files that have been processed from the original uploaded files and make the process of retrieval of the files efficient.

3. active_storage_attachments

This is the table in active_storage that is used for associating uploaded files with records in our application's database.

When you make a file upload to active_storage, you can attach it to a record in your database using Rails associations has_one_attached (here, you mean that a profile_picture belongs to only one User), or has_many_attached (here you mean a User object can have many photos associated to them).

This table is used to efficiently retrieve the uploaded files associated with a particular record in our database. In case you call for eg user.profile_picture, Active_storage will lookup for a corresponding record in "active_storage_attachments" table, retrieve it and display it to you.

Metadata. What do I mean by Metadata?

Metadata refers to information that describes other data. Confusing huh? Stay with me here. In our conext of Active-Storage, metadata refers to the information that is stored about an uploaded file or a variant file such as the filename, the content_type, byte_size and the checksum etc.

Let's say I have a digital photo of myself saved in my local disk as "Nemwelheadshot.png". Metadata for my picture could include data such as: filename, date taken, camera model, aperture, shutter speed, ISO speed, etc.

All the information provided above provides additional context and detail about the photo and they help to organize and simplify the retrieval process of a file.

To sum it all up:

I have mentioned so much above and I would like to finalize this with a personalized summary of what each table's function is:

The active_storage_blobs - this is the main engine of active storage as it stores all the core information about an uploaded file that is necessary for Active Storage to function properly.
The active_storage_variant_records - this is the optimizer of the uploaded files by creating multiple versions of an uploaded file to eg optimize it to take up less space and make the process of file retrieval; faster and efficient.
The active_storage_attachments - this is the middle man of active storage who links a specific uploaded file to a specific object in my database.

I hope that my short article has given you insights on what Active Storage is, what it helps you achieve, why you should use Active Storage in your Rails projects, and most importantly what constitutes Active Storage.

This one marks the end of the first series of The Ultimate Guide to Active Storage in Rails. Part B where I will walk you through the technical set up of Active storage locally in your application and later show you how to link it with Cloudinary to upload your images to an external cloud storage service provider will be coming soon. Be on the lookout for it!

That is it for today's class. I hope this was useful information for you. See you in my next article.

Create an API with Rails 7 and PostgreSQL

Nemwel Boniface — Mon, 22 Aug 2022 07:56:00 +0000

How to Create an API using Ruby on Rails 7 and PostgreSQL database

If you are new to programming like me I am sure that each time you come across this term you think of it as a very complex enigma to decipher. Luckily for you my reader today, I will try to explain to you what an API is in simple terms and walk you through how you can create your API with Ruby on Rails 7.

This will be part A of a two-part series where I will cover creating an API, documenting your API with rswag gem, and deploying the API to Heroku 🚀.

So what is an API?

An application programming interface (API) is like the messenger that takes your requests and tells your system what to do and then returns the response to you. Let's say you walk into a restaurant. You know what you want to eat, but you do not have access to the kitchen. The waiter comes and takes your request and returns your response in this case your food. Easy right?

When creating your website, you might not want it to have static data, that would be very boring. You might want to give it a way of getting dynamic data from somewhere. Ruby on Rails is one of the popular and easy ways to create API and now let's get started.

Our API project

We are going to create an API for a friend's application. You might want to save information about your friends and fetch them dynamically from somewhere and today we are going to do just that.

Prerequisites:

Rails V7
PostgreSQL database
Ruby V 3+
postman
Visual studio code
Some experience with Rails MVC architecture.

Project setup

We shall start by creating a new rails API application with the rails' new command in our terminal.

rails new friends-api --api --database=postgresql
cd friends-api
code .

This creates all our starting files and installs all the dependencies that we are going to need for this project. The --api flag installs the "bare minimum" dependencies excluding the views. This will be our back end remember?

Note: Do not forget to edit your database.yml file to allow Rails to work with your local machine PostgreSQL. Make sure you add your postgres username and passowrd in the development and test blocks. Below is an example:

development:
  <<: *default
  database: friends_api_development
  username: nemwel
  password: root

test:
  <<: *default
  database: friends_api_test
  username: nemwel
  password: root

We now need to create our database but do not migrate it just yet. We will do that when creating our model in a while.

rails db:create

Now let's create our model for our API and lets call it friend and let's assume we want to store the name, phone number, twitter username, his/ her email and maybe the location of the friend.

rails g model friend name:string phone:integer twitter:string email:string location:string

This will create a few files among them our model and a migration. Remember that this is a two-step process and now we need to run the migration so that the changes can persist in the database and we will have a schema.rb file created for us.

rails db:migrate

and now in your db folder, you should have the schema.rb file and our friend table created.

Create the API endpoints

We shall now create the API endpoints. Let's go to app>controllers and create an api folder. Let's create another folder called v1 inside our api folder which will hold the first version of our API.

Inside the app>controllers => api => v1 create our friends_controller and let's create the basic structure of our API friends controller.

class Api::V1::FriendsController < ApplicationController 
end

Awesome, now we can start by creating our API endpoint that will list all the friends that are available:

def index
  friends = Friend.all 

  if friends
    render json: {status: "SUCCESS", message: "Fetched all the friends successfully", data: friends}, status: :ok
  else
    render json: friends.errors, status: :bad_request
  end
end

but wait, we do not have any developers to test with! We will simplify this by going to our db/seeds.rb file and add some seed data that we shall test our API with.

friends = Friend.create([
  {name: "Nemwel Boniface", phone: 754135545, twitter: "@nemwel_bonie", email: "nemwelboniface@outlook.com", location: "Nairobi, Kenya"}
])

Now that everything is all wired up, we need one last thing. Routes! we need to tell our Rails application where and how to handle that request that we are passing to it.

so let's go to our config/routes.rb file and let's add the routes to our friend's controller.

namespace :api do
  namespace :v1 do
    resources :friends
  end
end

Now run your server with rails s and go to http://127.0.0.1:3000/api/v1/friends and you should be able to see your friend listed there.

Note: Do not forget to run rails db:seed.

Now, let's move to create a new friend. we will require two methods, one friends_params, and a create method. Let's get to work now. (Remember we will be working mostly in our friends_controller,rb file).

def create
  friend = Friend.new(friend_params)

  if friend.save
    render json: {status: "SUCCESS", message: "Friend was created successfully!", data: friend}, status: :created
  else
    render json: friend.errors, status: :unprocessable_entity
  end
end

private

def friend_params
  params.require(:friend).permit(:name, :location, :email, :twitter, :phone)
end

perfect! let's now test in our Postman. We are going to make a POST request. Make sure your server is still running. You should see something like this:

Great! our API is working very well so far. For brevity, I will now include the code for the API endpoints for deleting, editing, and showing the details of a specific friend.

# Show a specific friend GET request
def show
  friend = Friend.find(params[:id])

  if friend
    render json: {data: friend}, state: :ok
  else
    render json: {message: "Friend could not be found"}, status: :bad_request
  end
end

# Delete a specific friend DELETE request
def destroy
  friend = Friend.find(params[:id])

  if friend.destroy!
    render json: {message: "Friend was deleted successfully"}, status: :ok
  else
    render json: {message: "Friend does not exist"}, status: :bad_request
  end
end

# Update details for a specific friend. PATCH request
def update
  friend = Friend.find(params[:id])

  if friend.update!(friend_params)
    render json: {message: "Friend was updated successfully", data: friend}, status: :ok
  else
    render json: {message: "Friend cannot be updated"}, status: :unprocessable_entity
  end
end

With this, we can confidently say that we have successfully created our CRUD API endpoints. But wait, when you try to add some data, even wrong data, the API accepts it.

The rule of "Garbage in, garbage out" is something we want to avoid in our API. Let's add some validations to make sure that no fields are empty and that the correct data types of the data are input. So let's go to our friends model and let's add the following:

class Friend < ApplicationRecord
  validates :name, length: { minimum: 2 }
  validates :location, length: { minimum: 2 }
  validates :email, length: { minimum: 2 }
  validates :twitter, length: { minimum: 2 }
  validates :phone, length: { is: 9 }, numericality: true
end

Now if someone tries adding some wrong data or leaves a field as empty, the API will reject it and the integrity of the data we store will be upheld.

This one marks the end of the first series of creating an API with Ruby on Rails 7 and PostgreSQL database. Part B of this series will cover how to document your API using the Rswag gem and then how to deploy your API to Heroku. Stay tuned!

That is it for today's class. I hope this was useful information for you. See you in my next article.

DEV Community: Nemwel Boniface

Rails Authorization Beyond Models: Securing Dashboards and Service Controllers with CanCanCan

Introduction - Authentication and Authorization. What are these?

The Foundation: The Rulebook (Ability.rb)

The "Secure by Default" Mindset

Scenario 1: The Standard CRUD Resource (This is the Happy Path)

Scenario 2: The "Service" Controller (When there is no Database Model)

Scenario 3: The Complex or Expensive Action

Summary and a useful Cheat Sheet

Conclusion

What Happens When a User Deletes Their Account? A Guide to Rails ActiveRecord dependent: Strategies

Introduction

1. The Clean Sweep: dependent: :destroy

2. The Bulk Cleanup: dependent: :delete_all

3. The "Legacy" Handover: dependent: :nullify

4. The Soft Block: dependent: :restrict_with_error

5. The Hard Guard: dependent: :restrict_with_exception

Short Recap

Conclusion

Architecture Backwards: Engineering a Self-Defending System Before the UI Arrives

Introduction

1. The "Horizontal" Nature of Users

1.1 The Tortoise and the API

2. Building the "Defensive By Design Perimeter."

3. Solving the "Thundering Herd" Problem

4. The Admin-First Dashboard

The Lesson I have learned so far: Embrace the trenches

Conclusion

Building a Custom Audit Trail in Ruby on Rails Without PaperTrail

How to Automate Daily Task Emails in Rails using Whenever and Cron

Stimulus.js Explained: A Beginner’s Guide for Ruby on Rails Developers

Mastering Code Reviews: The Ultimate How-To Series

Mastering Technical Writing: A Step-by-Step Guide for Beginners

Implementing Custom Slugs with FriendlyID in Rails: A Step-by-Step Technical Guide

From Theory to Practice: Using Active Storage for File Management in Rails

The Ultimate Guide to Active Storage in Rails

Create an API with Rails 7 and PostgreSQL

1. The Clean Sweep: `dependent: :destroy`

2. The Bulk Cleanup: `dependent: :delete_all`

3. The "Legacy" Handover: `dependent: :nullify`

4. The Soft Block: `dependent: :restrict_with_error`

5. The Hard Guard: `dependent: :restrict_with_exception`