Why models represent data in Ruby on Rails - Performance Evidence

Performance: Why models represent data

MEDIUM IMPACT

This concept affects how efficiently data is managed and accessed in a Rails application, impacting server response time and page load speed.

Managing user data in a Rails app

Ruby on Rails

def user_name
  @user ||= User.find(params[:id])
  @user.name
end

Caches the user object on first call, avoiding repeated database queries.

📈 Performance Gainsingle database query per request, faster response, better LCP

Managing user data in a Rails app

Ruby on Rails

def user_name
  User.find(params[:id]).name
end

This code queries the database every time the method is called, causing repeated database hits.

📉 Performance Costtriggers multiple database queries, increasing server response time and slowing LCP

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Repeated database calls without caching	N/A	N/A	Blocks rendering due to slow server response	[X] Bad
Model caching with memoization	N/A	N/A	Faster server response enables quicker paint	[OK] Good

Rendering Pipeline

Models handle data retrieval and business logic before the view renders content. Efficient model use reduces database calls and speeds up server response, which helps the browser start rendering sooner.

→Server Processing

→Data Fetching

→HTML Rendering

⚠️ BottleneckDatabase queries triggered by model calls

Core Web Vital Affected

LCP

This concept affects how efficiently data is managed and accessed in a Rails application, impacting server response time and page load speed.

Optimization Tips

1Avoid repeated database queries by caching model data during a request.

2Use models to organize data access and reduce server processing time.

3Eager load related data in models to minimize query count and speed up page rendering.

Performance Quiz - 3 Questions

How does using models to represent data affect page load speed in Rails?

A It has no effect on page load speed.

B It reduces repeated database queries, speeding up server response.

C It increases the number of database queries, slowing down the server.

D It only affects client-side rendering, not server response.

DevTools: Network

How to check: Open DevTools, go to Network tab, reload the page, and observe the number and timing of API/database requests.

What to look for: Look for repeated or slow database queries that delay the initial HTML response, which slows LCP.

Practice

1. Why do Rails models represent data in an application?

easy

A. Because models control the server configuration

B. Because models handle user interface design

C. Because models organize and manage data from the database

D. Because models manage network requests

Solution

1. Step 1: Understand the role of models in Rails

   Models are designed to represent and organize data, connecting to database tables.

2. Step 2: Identify what models do not handle

   Models do not manage UI, server setup, or network requests; those are handled by other parts of the app.

3. Final Answer:

   Because models organize and manage data from the database -> Option C

4. Quick Check:

   Models = Data organization [OK]

Hint: Models = data holders, not UI or server [OK]

Common Mistakes:

• Confusing models with views or controllers
• Thinking models handle UI or network
• Assuming models configure servers

2. Which of the following is the correct way to define a model named Book in Rails?

easy

A. def Book; end

B. class Book < ApplicationRecord; end

C. class Book < Controller; end

D. module Book; end

Solution

1. Step 1: Recall Rails model inheritance

   Models inherit from ApplicationRecord to connect with the database.

2. Step 2: Check other options for correctness

   Controllers inherit from Controller, not models; methods and modules are not models.

3. Final Answer:

   class Book < ApplicationRecord; end -> Option B

4. Quick Check:

   Model class inherits ApplicationRecord [OK]

Hint: Models inherit ApplicationRecord, not Controller [OK]

Common Mistakes:

• Using Controller instead of ApplicationRecord
• Defining model as a method or module
• Missing inheritance entirely

3. Given the model User with attributes name and email, what will User.first.name return if the first user in the database has name "Alice"?

medium

A. nil

B. "email"

C. An error because name is not defined

D. "Alice"

Solution

1. Step 1: Understand what User.first does

   This fetches the first user record from the database.

2. Step 2: Access the name attribute

   Since the first user's name is "Alice", User.first.name returns "Alice".

3. Final Answer:

   "Alice" -> Option D

4. Quick Check:

   User.first.name = "Alice" [OK]

Hint: User.first returns first record; access attributes directly [OK]

Common Mistakes:

• Assuming attribute returns nil if present
• Thinking name is undefined
• Confusing attribute with method name

4. What is wrong with this model code? class Product < ApplicationRecord validates :price, presence: true validates :price, numericality: true end

medium

A. The validations are correct and will work as expected

B. The numericality validation is missing an option to allow only numbers

C. The validations should be combined into one line

D. The numericality validation should be numericality: { only_integer: true } if only integers are allowed

Solution

1. Step 1: Review the model definition

   The class correctly inherits from ApplicationRecord.

2. Step 2: Check the validations

   Presence ensures not blank, numericality ensures it's a number. Both are correct and standard.

3. Final Answer:

   The validations are correct and will work as expected -> Option A

4. Quick Check:

   Model code is syntactically valid and validations proper [OK]

Hint: Presence + numericality is standard for price fields [OK]

Common Mistakes:

• Thinking numericality requires additional options like only_integer
• Believing validations must be combined into one
• Assuming only_integer is required without specification

5. You want to create a model Order that stores customer orders with a status attribute limited to 'pending', 'shipped', or 'cancelled'. How should you represent this in the model to enforce these allowed values?

hard

A. Use a validation like validates :status, inclusion: { in: ['pending', 'shipped', 'cancelled'] }

B. Use a database enum type without any model validation

C. Use a string attribute without validation and check status manually in controllers

D. Use validates :status, presence: true only

Solution

1. Step 1: Understand the need to limit allowed values

   The status attribute should only accept specific strings.

2. Step 2: Use model validation to enforce allowed values

   Using validates :status, inclusion: { in: [...] } ensures only allowed statuses are saved.

3. Final Answer:

   Use a validation like validates :status, inclusion: { in: ['pending', 'shipped', 'cancelled'] } -> Option A

4. Quick Check:

   Status inclusion validation enforces allowed values [OK]

Hint: Use inclusion validation to limit attribute values [OK]

Common Mistakes:

• Relying only on presence validation
• Skipping model validation and checking in controllers
• Assuming database enum alone is enough without model checks