Ruby on Rails interview questions [Part-1]

Q:1 What is the MVC architecture pattern and how does Rails implement it?

Approach: Explain the separation of concerns between Model, View, and Controller components and their responsibilities in Rails.

The MVC (Model-View-Controller) pattern separates application logic into three interconnected components. In Rails, Models handle data and business logic using Active Record, Views manage the presentation layer through ERB templates and helpers, and Controllers orchestrate the flow between models and views while handling HTTP requests. This separation promotes code organization, reusability, and maintainability. Rails follows convention over configuration, automatically mapping URLs to controller actions and providing structured directories for each component.

Q:2 Explain the difference between has_many and belongs_to associations.

Approach: Define the relationship direction and explain the foreign key placement in database tables.

belongs_to establishes a one-to-one connection where the current model contains the foreign key, indicating it “belongs to” another model. has_many creates a one-to-many relationship where the current model can have multiple instances of another model. The foreign key is stored in the associated model’s table, not the current model. For example, a User has_many Posts, while a Post belongs_to a User. The posts table contains a user_id foreign key, establishing this relationship in the database schema.

1
class User < ApplicationRecord
2
  has_many :posts
3
end
4

5
class Post < ApplicationRecord
6
  belongs_to :user
7
end

Q:3 What are Rails migrations and why are they important?

Approach: Explain database schema versioning and the benefits of using migrations for database changes.

Rails migrations are Ruby classes that provide a database-agnostic way to alter your database schema over time. They’re important because they allow teams to collaborate on database changes, maintain version control of schema modifications, and provide rollback capabilities. Migrations ensure that database changes are applied consistently across different environments (development, staging, production). They’re timestamped and executed in order, maintaining a clear history of database evolution. This approach eliminates manual SQL scripts and reduces deployment errors.

1
class CreatePosts < ActiveRecord::Migration[7.0]
2
  def change
3
    create_table :posts do |t|
4
      t.string :title, null: false
5
      t.text :content
6
      t.references :user, null: false, foreign_key: true
7
      t.timestamps
8
    end
9
  end
10
end

Q:4 How do you handle validation in Rails models?

Approach: Describe built-in validations and custom validation methods to ensure data integrity.

Rails provides built-in validations that run before saving records to the database, ensuring data integrity at the application level. Common validations include presence, length, format, and uniqueness checks. You can also create custom validations using methods or validator classes. Validations prevent invalid data from being persisted and provide user-friendly error messages. They’re triggered automatically during save operations and can be bypassed using methods like save(validate: false) when necessary.

1
class User < ApplicationRecord
2
  validates :email, presence: true, uniqueness: true, format: { with: URI::MailTo::EMAIL_REGEXP }
3
  validates :name, presence: true, length: { minimum: 2, maximum: 50 }
4
  validates :age, numericality: { greater_than: 0, less_than: 150 }
5

6
  validate :custom_validation
7

8
  private
9

10
  def custom_validation
11
    errors.add(:email, "cannot be from blocked domains") if email&.ends_with?("blocked.com")
12
  end
13
end

Q:5 What is the difference between find and where in Active Record?

Approach: Compare the return types and use cases for these two query methods.

find is used to retrieve a single record by primary key and raises an exception if not found, while where returns an Active Record relation (which can contain multiple records) and never raises an exception for empty results. find immediately executes the query and returns the model instance, whereas where is lazy-loaded and can be chained with other query methods. Use find when you need a specific record by ID and want to handle missing records with exceptions, and use where for filtering records based on conditions.

1
# find - returns single record or raises RecordNotFound
2
user = User.find(1)  # Raises ActiveRecord::RecordNotFound if ID 1 doesn't exist
3

4
# where - returns ActiveRecord::Relation
5
users = User.where(active: true)  # Returns empty relation if no matches
6
active_admins = User.where(active: true).where(role: 'admin')  # Chainable

Q:6 Explain the Rails request/response cycle.

Approach: Walk through the complete flow from browser request to server response.

The Rails request/response cycle begins when a browser sends an HTTP request to the Rails server. The request hits the router, which matches the URL to a specific controller action based on routes.rb configuration. The dispatcher creates an instance of the appropriate controller and calls the specified action method. The controller interacts with models to fetch or manipulate data, then renders a view template (or returns JSON). The view combines the template with data to generate HTML, which is sent back as an HTTP response to the browser. Middleware components can intercept and modify requests/responses throughout this cycle.

Q:7 What are Rails callbacks and when would you use them?

Approach: Explain the lifecycle hooks available in Active Record and provide practical examples.

Rails callbacks are hooks that allow you to trigger logic at specific points in an object’s lifecycle, such as before/after creation, validation, saving, or destruction. They’re useful for tasks like setting default values, sending notifications, logging changes, or cleaning up associated data. Common callbacks include before_save, after_create, before_destroy, and after_update. While powerful, callbacks should be used judiciously as they can make code harder to test and debug. Consider using service objects or observers for complex business logic instead of overloading models with callbacks.

1
class User < ApplicationRecord
2
  before_save :normalize_email
3
  after_create :send_welcome_email
4
  before_destroy :cleanup_user_data
5

6
  private
7

8
  def normalize_email
9
    self.email = email.downcase.strip if email.present?
10
  end
11

12
  def send_welcome_email
13
    UserMailer.welcome_email(self).deliver_later
14
  end
15

16
  def cleanup_user_data
17
    posts.destroy_all
18
    profile.destroy if profile.present?
19
  end
20
end

Q:8 How do you implement authentication in a Rails application?

Approach: Discuss popular authentication solutions and basic implementation approaches.

Authentication in Rails can be implemented using gems like Devise, Clearance, or custom solutions. The basic approach involves creating a User model with password encryption (using bcrypt), implementing session management, and adding controller methods to handle login/logout. Devise is the most popular solution, providing generators for views, controllers, and models with features like password reset, email confirmation, and account locking. Custom implementation gives more control but requires handling security concerns like password hashing, session management, and CSRF protection manually.

1
# Custom authentication example
2
class User < ApplicationRecord
3
  has_secure_password
4
  validates :email, presence: true, uniqueness: true
5
end
6

7
class SessionsController < ApplicationController
8
  def create
9
    user = User.find_by(email: params[:email])
10
    if user&.authenticate(params[:password])
11
      session[:user_id] = user.id
12
      redirect_to root_path
13
    else
14
      flash[:alert] = "Invalid credentials"
15
      render :new
16
    end
17
  end
18

19
  def destroy
20
    session[:user_id] = nil
21
    redirect_to root_path
22
  end
23
end

Q:9 What is the difference between render and redirect_to?

Approach: Explain the HTTP behavior and use cases for each method.

render generates and returns an HTTP response without changing the URL, staying within the same request cycle. It’s used to display templates, JSON, or other content types. redirect_to sends an HTTP redirect response (302 by default) that instructs the browser to make a new request to a different URL, creating a new request cycle. Use render when you want to display a view with the current request’s data (like form errors), and use redirect_to after successful form submissions or when you want to change the URL. Each controller action should only call one of these methods.

1
class PostsController < ApplicationController
2
  def create
3
    @post = Post.new(post_params)
4

5
    if @post.save
6
      redirect_to @post, notice: 'Post created successfully'  # New request
7
    else
8
      render :new  # Same request, shows validation errors
9
    end
10
  end
11

12
  def show
13
    @post = Post.find(params[:id])
14
    render json: @post  # Returns JSON response
15
  end
16
end

Q:10 How do you handle background jobs in Rails?

Approach: Discuss job processing libraries and queuing strategies for asynchronous tasks.

Background jobs in Rails are handled using libraries like Sidekiq, Resque, or Active Job (Rails’ built-in abstraction). These tools allow you to perform time-consuming tasks asynchronously, improving application responsiveness. Common use cases include sending emails, processing images, generating reports, or calling external APIs. Active Job provides a unified interface that works with multiple backends. Jobs are typically stored in Redis or database queues and processed by worker processes. Proper error handling, retry logic, and monitoring are essential for production deployments.

1
# Using Active Job
2
class SendEmailJob < ApplicationJob
3
  queue_as :default
4

5
  def perform(user_id, email_type)
6
    user = User.find(user_id)
7
    case email_type
8
    when 'welcome'
9
      UserMailer.welcome_email(user).deliver_now
10
    when 'newsletter'
11
      UserMailer.newsletter(user).deliver_now
12
    end
13
  rescue StandardError => e
14
    Rails.logger.error "Failed to send email: #{e.message}"
15
    raise  # Re-raise to trigger retry
16
  end
17
end
18

19
# Enqueuing jobs
20
SendEmailJob.perform_later(user.id, 'welcome')
21
SendEmailJob.set(wait: 1.hour).perform_later(user.id, 'newsletter')

Q:11 What are Rails concerns and how do you use them?

Approach: Explain the DRY principle application through mixins and shared functionality.

Rails concerns are modules that encapsulate shared functionality and can be included in multiple classes, promoting code reuse and organization. They’re stored in app/models/concerns and app/controllers/concerns directories. Concerns help extract common methods, validations, associations, or scopes that multiple models or controllers might need. They support both class and instance methods through ClassMethods modules and can include other concerns. This pattern follows the DRY principle and makes code more maintainable by centralizing shared logic.

1
module Timestampable
2
  extend ActiveSupport::Concern
3

4
  included do
5
    scope :recent, -> { where('created_at > ?', 1.week.ago) }
6
    before_save :update_modified_by
7
  end
8

9
  class_methods do
10
    def created_today
11
      where(created_at: Date.current.beginning_of_day..Date.current.end_of_day)
12
    end
13
  end
14

15
  def time_since_creation
16
    Time.current - created_at
17
  end
18

19
  private
20

21
  def update_modified_by
22
    self.modified_by = Current.user&.id
23
  end
24
end
25

26
# Usage in models
27
class Post < ApplicationRecord
28
  include Timestampable
29
end
30

31
class Comment < ApplicationRecord
32
  include Timestampable
33
end

Q:12 How do you optimize database queries in Rails?

Approach: Discuss N+1 queries, eager loading, and other performance optimization techniques.

Database query optimization in Rails involves several strategies: using includes to prevent N+1 queries through eager loading, joins for filtering with associations, and select to limit returned columns. Index your database columns that are frequently queried. Use find_each for batch processing large datasets. Implement database-level constraints and consider counter caches for frequently counted associations. Tools like Bullet gem help identify N+1 queries during development. For complex queries, sometimes raw SQL or database views are more efficient than Active Record methods.

1
# N+1 problem
2
posts = Post.all
3
posts.each { |post| puts post.user.name }  # Executes N+1 queries
4

5
# Solution with includes
6
posts = Post.includes(:user)
7
posts.each { |post| puts post.user.name }  # Executes 2 queries total
8

9
# Other optimizations
10
class Post < ApplicationRecord
11
  belongs_to :user, counter_cache: true
12
  scope :published, -> { where(published: true) }
13
  scope :with_comments, -> { joins(:comments).distinct }
14
end
15

16
# Batch processing
17
User.find_each(batch_size: 1000) do |user|
18
  user.update_last_login
19
end
20

21
# Select specific columns
22
User.select(:id, :name, :email).where(active: true)

Q:13 What is the difference between Class and Module in Ruby?

Approach: Compare inheritance capabilities and usage patterns between classes and modules.

Classes in Ruby support inheritance and can be instantiated to create objects, while modules cannot be instantiated and don’t support inheritance but can be included in classes as mixins. Classes use single inheritance (one superclass) but can include multiple modules. Modules are used for namespacing and sharing functionality across multiple classes. Classes define object blueprints with state and behavior, while modules provide shared behavior without state. You can check ancestry with ancestors method and use prepend or include to add module functionality to classes.

1
# Module example
2
module Greetable
3
  def greet
4
    puts "Hello, I'm #{name}"
5
  end
6
end
7

8
# Class with inheritance
9
class Person
10
  include Greetable
11

12
  attr_accessor :name
13

14
  def initialize(name)
15
    @name = name
16
  end
17
end
18

19
class Employee < Person
20
  attr_accessor :company
21

22
  def initialize(name, company)
23
    super(name)
24
    @company = company
25
  end
26
end
27

28
# Usage
29
emp = Employee.new("John", "TechCorp")
30
emp.greet  # "Hello, I'm John"
31
puts Employee.ancestors  # Shows inheritance chain

Q:14 How do you implement caching in Rails?

Approach: Explain different caching strategies and their appropriate use cases.

Rails provides multiple caching strategies: page caching (entire pages), action caching (controller actions), fragment caching (view portions), and low-level caching (arbitrary data). Fragment caching is most common, using cache helpers in views with cache keys that include model objects and timestamps. Rails.cache provides methods like fetch, read, write for low-level caching. Cache stores include memory, file system, Redis, and Memcached. Implement cache expiration strategies using touch: true in associations and consider Russian Doll caching for nested cache dependencies.

1
# Fragment caching in views
2
<% cache @post do %>
3
  <h1><%= @post.title %></h1>
4
  <p><%= @post.content %></p>
5

6
  <% cache @post.comments do %>
7
    <% @post.comments.each do |comment| %>
8
      <% cache comment do %>
9
        <p><%= comment.body %></p>
10
      <% end %>
11
    <% end %>
12
  <% end %>
13
<% end %>
14

15
# Low-level caching in models/controllers
16
class Post < ApplicationRecord
17
  def expensive_calculation
18
    Rails.cache.fetch("post_#{id}_calculation", expires_in: 1.hour) do
19
      # Expensive operation here
20
      complex_computation
21
    end
22
  end
23
end
24

25
# Cache expiration
26
class Comment < ApplicationRecord
27
  belongs_to :post, touch: true  # Updates post's updated_at when comment changes
28
end

Q:15 What are Rails engines and when would you use them?

Approach: Explain engines as miniature applications and their use cases for modularity.

Rails engines are miniature applications that can be mounted inside other Rails applications, providing a way to share functionality across multiple applications or organize large applications into smaller, manageable pieces. Engines have their own routes, controllers, models, views, and assets. They’re useful for creating reusable components like admin panels, authentication systems, or business-specific modules. Engines can be packaged as gems for distribution or kept within the same repository for internal modularization. They help maintain separation of concerns and enable teams to work on different parts of an application independently.

1
# Creating an engine
2
# rails plugin new blog_engine --mountable
3

4
module BlogEngine
5
  class Engine < ::Rails::Engine
6
    isolate_namespace BlogEngine
7

8
    config.generators do |g|
9
      g.test_framework :rspec
10
    end
11
  end
12
end
13

14
# Mounting in main application routes
15
Rails.application.routes.draw do
16
  mount BlogEngine::Engine, at: "/blog"
17
  # Other routes
18
end
19

20
# Engine routes (blog_engine/config/routes.rb)
21
BlogEngine::Engine.routes.draw do
22
  resources :posts
23
  root to: "posts#index"
24
end

Q:16 How do you handle errors and exceptions in Rails?

Approach: Discuss rescue blocks, custom error pages, and exception handling strategies.

Rails error handling involves using rescue blocks in controllers, custom error pages for different HTTP status codes, and application-wide exception handling. Use rescue_from in ApplicationController to handle specific exceptions globally. Create custom error pages in public/ directory (404.html, 500.html) or use dynamic error pages with controllers. Log exceptions appropriately and consider using error tracking services like Bugsnag or Rollbar in production. Handle different exception types differently: validation errors should show user-friendly messages, while system errors might redirect to error pages.

1
class ApplicationController < ActionController::Base
2
  rescue_from ActiveRecord::RecordNotFound, with: :record_not_found
3
  rescue_from ActionController::ParameterMissing, with: :parameter_missing
4
  rescue_from StandardError, with: :internal_server_error
5

6
  private
7

8
  def record_not_found(exception)
9
    Rails.logger.warn "Record not found: #{exception.message}"
10
    render file: Rails.root.join('public', '404.html'), status: :not_found, layout: false
11
  end
12

13
  def parameter_missing(exception)
14
    render json: { error: "Missing parameter: #{exception.param}" }, status: :bad_request
15
  end
16

17
  def internal_server_error(exception)
18
    Rails.logger.error "Internal error: #{exception.message}"
19
    ExceptionNotifier.notify_exception(exception) if Rails.env.production?
20
    render file: Rails.root.join('public', '500.html'), status: :internal_server_error, layout: false
21
  end
22
end
23

24
# In specific controllers
25
class PostsController < ApplicationController
26
  def show
27
    @post = Post.find(params[:id])
28
  rescue ActiveRecord::RecordNotFound
29
    flash[:alert] = "Post not found"
30
    redirect_to posts_path
31
  end
32
end

Q:17 What is the difference between merge and joins in Active Record?

Approach: Compare how these methods combine query conditions and their effects on the result set.

joins creates SQL JOIN clauses to combine tables but only affects the WHERE conditions and doesn’t load associated records into memory. merge combines query scopes and conditions from associated models, allowing you to apply scopes defined in other models to your current query. Use joins when you need to filter records based on associated table conditions without loading the associations. Use merge when you want to apply existing scopes from associated models to create more readable and maintainable queries. merge is particularly useful with named scopes.

1
class User < ApplicationRecord
2
  has_many :posts
3
  scope :active, -> { where(active: true) }
4
end
5

6
class Post < ApplicationRecord
7
  belongs_to :user
8
  scope :published, -> { where(published: true) }
9
  scope :recent, -> { where('created_at > ?', 1.week.ago) }
10
end
11

12
# Using joins - only filters, doesn't load user data
13
posts_with_active_users = Post.joins(:user).where(users: { active: true })
14

15
# Using merge - applies User's active scope
16
posts_with_active_users = Post.joins(:user).merge(User.active)
17

18
# More complex merge example
19
Post.joins(:user)
20
    .merge(User.active)
21
    .merge(Post.published)
22
    .merge(Post.recent)
23

24
# This is more readable than:
25
Post.joins(:user)
26
    .where(users: { active: true })
27
    .where(published: true)
28
    .where('posts.created_at > ?', 1.week.ago)

Q:18 How do you implement file uploads in Rails?

Approach: Discuss Active Storage, image processing, and file validation strategies.

Rails file uploads are typically handled with Active Storage (Rails 5.2+), which provides a unified API for uploading files to cloud services or local storage. Active Storage creates attachment associations in models and handles file metadata, variants for image processing, and direct uploads. For image processing, integrate with ImageMagick or libvips through the image_processing gem. Implement validations for file size, content type, and dimensions. Consider security aspects like virus scanning and content type verification. For large files, use direct uploads to avoid server memory issues.

1
# Model with Active Storage
2
class User < ApplicationRecord
3
  has_one_attached :avatar
4
  has_many_attached :documents
5

6
  validate :avatar_validation
7

8
  private
9

10
  def avatar_validation
11
    return unless avatar.attached?
12

13
    if avatar.byte_size > 5.megabytes
14
      errors.add(:avatar, 'File size must be less than 5MB')
15
    end
16

17
    unless avatar.content_type.in?(['image/jpeg', 'image/png', 'image/gif'])
18
      errors.add(:avatar, 'Must be a JPEG, PNG, or GIF image')
19
    end
20
  end
21
end
22

23
# Controller handling uploads
24
class UsersController < ApplicationController
25
  def update
26
    if @user.update(user_params)
27
      redirect_to @user, notice: 'Profile updated successfully'
28
    else
29
      render :edit
30
    end
31
  end
32

33
  private
34

35
  def user_params
36
    params.require(:user).permit(:name, :email, :avatar, documents: [])
37
  end
38
end
39

40
# View with file upload
41
<%= form_with model: @user do |form| %>
42
  <%= form.file_field :avatar, accept: 'image/*' %>
43
  <%= form.file_field :documents, multiple: true %>
44
  <%= form.submit %>
45
<% end %>
46

47
# Displaying images with variants
48
<%= image_tag @user.avatar.variant(resize_to_limit: [300, 300]) if @user.avatar.attached? %>

Q:19 What are Rails serializers and how do you use them?

Approach: Explain JSON serialization patterns and popular serializer gems for API responses.

Rails serializers provide a way to customize JSON output for API responses, offering more control than the default to_json method. Popular gems include Active Model Serializers and jsonapi-serializer (formerly fast_jsonapi). Serializers define which attributes to include, handle associations, compute derived values, and format data consistently. They separate presentation logic from models and support conditional attributes, nested serialization, and different serialization contexts. This approach is essential for building clean APIs and controlling data exposure.

1
# Using Active Model Serializers
2
class UserSerializer < ActiveModel::Serializer
3
  attributes :id, :name, :email, :created_at, :full_name
4

5
  has_many :posts, serializer: PostSerializer
6

7
  attribute :avatar_url, if: :has_avatar?
8

9
  def full_name
10
    "#{object.first_name} #{object.last_name}"
11
  end
12

13
  def avatar_url
14
    Rails.application.routes.url_helpers.url_for(object.avatar) if object.avatar.attached?
15
  end
16

17
  def has_avatar?
18
    object.avatar.attached?
19
  end
20
end
21

22
class PostSerializer < ActiveModel::Serializer
23
  attributes :id, :title, :content, :published_at
24

25
  belongs_to :user, serializer: UserSerializer
26
end
27

28
# Controller usage
29
class Api::UsersController < ApplicationController
30
  def show
31
    user = User.find(params[:id])
32
    render json: user, serializer: UserSerializer
33
  end
34

35
  def index
36
    users = User.includes(:posts)
37
    render json: users, each_serializer: UserSerializer
38
  end
39
end
40

41
# Custom serialization without gems
42
class User < ApplicationRecord
43
  def as_json(options = {})
44
    super(options.merge(
45
      only: [:id, :name, :email],
46
      methods: [:full_name],
47
      include: { posts: { only: [:id, :title, :published_at] } }
48
    ))
49
  end
50
end

Q:20 How do you implement authorization in Rails?

Approach: Discuss role-based access control and popular authorization gems like Pundit or CanCanCan.

Authorization in Rails controls what authenticated users can do, typically implemented using gems like Pundit, CanCanCan, or custom solutions. Pundit uses policy classes that define permissions for each model, providing a clean separation of authorization logic. CanCanCan uses ability classes with a DSL to define rules. Both support role-based access control, resource-based permissions, and conditional authorization. Implementation involves checking permissions in controllers and views, handling unauthorized access gracefully, and organizing complex permission logic maintainably.

1
# Using Pundit
2
class PostPolicy < ApplicationPolicy
3
  def show?
4
    record.published? || record.user == user || user.admin?
5
  end
6

7
  def create?
8
    user&.present?
9
  end
10

11
  def update?
12
    record.user == user || user.admin?
13
  end
14

15
  def destroy?
16
    record.user == user || user.admin?
17
  end
18

19
  class Scope < Scope
20
    def resolve
21
      if user&.admin?
22
        scope.all
23
      elsif user
24
        scope.where(published: true).or(scope.where(user: user))
25
      else
26
        scope.where(published: true)
27
      end
28
    end
29
  end
30
end
31

32
# Controller usage
33
class PostsController < ApplicationController
34
  before_action :authenticate_user!, except: [:index, :show]
35

36
  def index
37
    @posts = policy_scope(Post)
38
  end
39

40
  def show
41
    @post = Post.find(params[:id])
42
    authorize @post
43
  end
44

45
  def create
46
    @post = current_user.posts.build(post_params)
47
    authorize @post
48

49
    if @post.save
50
      redirect_to @post
51
    else
52
      render :new
53
    end
54
  end
55

56
  def update
57
    @post = Post.find(params[:id])
58
    authorize @post
59

60
    if @post.update(post_params)
61
      redirect_to @post
62
    else
63
      render :edit
64
    end
65
  end
66
end
67

68
# View usage
69
<% if policy(@post).update? %>
70
  <%= link_to 'Edit', edit_post_path(@post) %>
71
<% end %>
72

73
<% if policy(@post).destroy? %>
74
  <%= link_to 'Delete', @post, method: :delete, data: { confirm: 'Are you sure?' } %>
75
<% end %>

Q:21 What is the difference between present? and exists? in Rails?

Approach: Compare memory usage and database query behavior between these two methods.

present? loads records into memory to check if the collection contains any elements, while exists? performs a database query (SELECT 1) without loading records, making it more memory-efficient for large datasets. present? is useful when you need to work with the records afterward, but exists? is better for simple presence checks. exists? can also accept conditions to check for specific records. Use exists? for conditional logic where you only need to know if records exist, and present? when you’ll use the loaded records immediately after the check.

1
# exists? - performs COUNT query, doesn't load records
2
if User.where(active: true).exists?
3
  puts "Active users found"
4
end
5

6
# More specific exists check
7
if User.exists?(email: '[email protected]')
8
  puts "Admin user exists"
9
end
10

11
# present? - loads records into memory
12
users = User.where(active: true)
13
if users.present?
14
  puts "Found #{users.count} active users"
15
  users.each { |user| puts user.name }  # Records already loaded
16
end
17

18
# Performance comparison
19
# Inefficient - loads all records just to check presence
20
if User.where(active: true).present?
21
  # Only checking existence, wasted memory
22
end
23

24
# Efficient - only checks existence
25
if User.where(active: true).exists?
26
  # Minimal database query
27
end
28

29
# When you need both check and data
30
users = User.where(active: true)
31
if users.present?
32
  # Work with loaded users
33
  process_users(users)
34
end

Q:22 How do you handle database transactions in Rails?

Approach: Explain ACID properties and Rails transaction methods for data consistency.

Rails transactions ensure data consistency by wrapping multiple database operations in a single atomic unit that either completes entirely or rolls back completely. Use ActiveRecord::Base.transaction or model instance transactions to group operations. Transactions automatically rollback on exceptions and can be manually rolled back using raise ActiveRecord::Rollback. Nested transactions use savepoints in supported databases. Consider transaction isolation levels for concurrent access scenarios and be aware that transactions lock database resources, so keep them short and focused.

1
# Basic transaction usage
2
def transfer_money(from_account, to_account, amount)
3
  ActiveRecord::Base.transaction do
4
    from_account.withdraw(amount)
5
    to_account.deposit(amount)
6

7
    # Both operations succeed or both fail
8
    TransactionLog.create!(
9
      from_account: from_account,
10
      to_account: to_account,
11
      amount: amount
12
    )
13
  end
14
rescue ActiveRecord::RecordInvalid => e
15
  Rails.logger.error "Transfer failed: #{e.message}"
16
  false
17
end
18

19
# Model-level transactions
20
class User < ApplicationRecord
21
  def deactivate_with_cleanup
22
    transaction do
23
      update!(active: false, deactivated_at: Time.current)
24
      posts.update_all(published: false)
25
      profile.destroy! if profile.present?
26

27
      # Manual rollback condition
28
      raise ActiveRecord::Rollback if some_condition_fails?
29
    end
30
  end
31
end
32

33
# Nested transactions with savepoints
34
User.transaction do
35
  user = User.create!(name: 'John')
36

37
  begin
38
    User.transaction(requires_new: true) do  # Creates savepoint
39
      profile = user.create_profile!(bio: 'Invalid bio that might fail')
40
      raise ActiveRecord::Rollback if profile.invalid?
41
    end
42
  rescue ActiveRecord::StatementInvalid
43
    # Handle savepoint rollback
44
    Rails.logger.warn "Profile creation failed, but user creation continues"
45
  end
46

47
  # User creation continues even if profile failed
48
end

Q:23 What are Rails view helpers and how do you create custom ones?

Approach: Explain built-in helpers and demonstrate creating reusable view logic.

Rails view helpers are methods that assist in generating HTML and formatting data in views, promoting code reuse and keeping views clean. Built-in helpers include link_to, form_with, image_tag, and formatting helpers like number_to_currency. Custom helpers are created in app/helpers/ directory and are automatically available in views. They should contain presentation logic, not business logic, and can accept parameters to make them flexible. Helpers can be tested separately and shared across multiple views and layouts.

1
  module ApplicationHelper
2
    def page_title(title = nil)
3
      if title.present?
4
        "#{title} | MyApp"
5
      else
6
        "MyApp - Welcome"
7
      end
8
    end
9

10
    def flash_class(level)
11
      case level.to_sym
12
      when :notice then "alert alert-info"
13
      when :success then "alert alert-success"
14
      when :error   then "alert alert-danger"
15
      when :alert   then "alert alert-warning"
16
      else "alert alert-info"
17
      end
18
    end
19

20
    def user_avatar(user, size: 'medium')
21
      sizes = { small: 32, medium: 64, large: 128 }
22
      dimension = sizes[size.to_sym] || sizes[:medium]
23

24
      if user.avatar.attached?
25
        image_tag user.avatar.variant(resize_to_limit: [dimension, dimension]),
26
                  alt: user.name,
27
                  class: "avatar avatar-#{size}"
28
      else
29
        image_tag "default_avatar.png",
30
                  width: dimension,
31
                  height: dimension,
32
                  alt: "Default Avatar",
33
                  class: "avatar avatar-#{size}"
34
      end
35
    end
36
  end