Repository pattern for data access in Flask - Performance & Optimization

Performance: Repository pattern for data access

MEDIUM IMPACT

This pattern affects how data is fetched and managed, impacting server response time and client perceived loading speed.

Fetching user data multiple times in different parts of the app

Flask

class UserRepository:
    def __init__(self):
        self.cache = {}

    def get_user(self, user_id):
        if user_id not in self.cache:
            self.cache[user_id] = User.query.filter_by(id=user_id).first()
        return self.cache[user_id]

class UserService:
    def __init__(self, repo):
        self.repo = repo

    def get_user_name(self, user_id):
        return self.repo.get_user(user_id).name

    def get_user_email(self, user_id):
        return self.repo.get_user(user_id).email

Caches user data on first fetch, avoiding repeated database queries and reducing server load.

📈 Performance GainSingle database query per user, reducing server response time and improving LCP.

Fetching user data multiple times in different parts of the app

Flask

class UserService:
    def get_user_name(self, user_id):
        return User.query.filter_by(id=user_id).first().name

    def get_user_email(self, user_id):
        return User.query.filter_by(id=user_id).first().email

Multiple queries to the database for the same user cause repeated database hits and slow response.

📉 Performance CostTriggers multiple database queries, increasing server response time and delaying LCP.

Performance Comparison

Pattern	Database Queries	Server Response Time	Client Load Impact	Verdict
Direct multiple queries	Multiple per user	High	Slower LCP	[X] Bad
Repository with caching	Single per user	Low	Faster LCP	[OK] Good

Rendering Pipeline

The repository pattern reduces redundant data fetching, which lowers server processing time and speeds up sending data to the client, improving the critical rendering path.

→Server Processing

→Network Transfer

→Client Rendering

⚠️ BottleneckServer Processing due to multiple database queries

Core Web Vital Affected

LCP

This pattern affects how data is fetched and managed, impacting server response time and client perceived loading speed.

Optimization Tips

1Cache data in the repository to avoid repeated database queries.

2Minimize server processing time to improve LCP.

3Use repository pattern to centralize and optimize data access.

Performance Quiz - 3 Questions

How does using a repository pattern with caching affect database queries?

A Reduces repeated queries by caching data

B Increases the number of queries

C Has no effect on queries

D Makes queries slower

DevTools: Network

How to check: Open DevTools, go to Network tab, reload the page, and observe the number and timing of API calls fetching data.

What to look for: Look for repeated API calls fetching the same data; fewer calls indicate better repository caching.

Practice

1. What is the main purpose of using the Repository pattern in a Flask application?

easy

A. To create HTML templates for the frontend

B. To speed up the Flask server response time

C. To handle user authentication automatically

D. To separate data access logic from business logic

Solution

1. Step 1: Understand the role of repository pattern

   The repository pattern is designed to separate how data is accessed from how it is used in the app logic.

2. Step 2: Identify the correct purpose in Flask context

   In Flask, this means keeping database queries inside repository classes, so the rest of the app doesn't need to know database details.

3. Final Answer:

   To separate data access logic from business logic -> Option D

4. Quick Check:

   Repository pattern = separation of concerns [OK]

Hint: Repository pattern means separate data from app logic [OK]

Common Mistakes:

• Thinking it speeds up server response
• Confusing it with authentication handling
• Assuming it creates frontend templates

2. Which of the following is the correct way to define a repository class method to get all users in Flask?

easy

A. def get_all_users(): return User.query.all()

B. def get_all_users(self): return User.query.all()

C. def get_all_users(self): return User.all()

D. def get_all_users(self): return User.query.get_all()

Solution

1. Step 1: Check method signature in a class

   Repository methods inside a class must have self as the first parameter.

2. Step 2: Verify correct SQLAlchemy query syntax

   To get all records, use User.query.all(). Other options use incorrect method names or miss self.

3. Final Answer:

   def get_all_users(self): return User.query.all() -> Option B

4. Quick Check:

   Method with self + User.query.all() = correct [OK]

Hint: Repository methods need self and correct query syntax [OK]

Common Mistakes:

• Omitting self parameter in method
• Using wrong query method like User.all()
• Using User.query.get_all() which doesn't exist

3. Given this repository method in Flask:

def get_user_by_id(self, user_id):
    return User.query.filter_by(id=user_id).first()

What will repo.get_user_by_id(5) return if no user with ID 5 exists?

medium

A. None

B. Raises an exception

C. An empty list []

D. A User object with id 5

Solution

1. Step 1: Understand SQLAlchemy filter_by().first() behavior

   The first() method returns the first matching record or None if no match is found.

2. Step 2: Apply to user_id 5 with no matching user

   Since no user with ID 5 exists, the method returns None, not a list or exception.

3. Final Answer:

   None -> Option A

4. Quick Check:

   filter_by().first() returns None if no match [OK]

Hint: filter_by().first() returns None if no record found [OK]

Common Mistakes:

• Expecting an empty list instead of None
• Thinking it raises an exception
• Assuming it returns a dummy User object

4. You wrote this repository method:

def add_user(self, user):
    db.session.add(user)
    db.session.commit

What is the error here?

medium

A. Missing parentheses after commit method call

B. db.session.add should be db.add

C. user parameter should be a dictionary, not an object

D. commit should be called before add

Solution

1. Step 1: Check method calls on db.session

   The commit method must be called with parentheses: commit().

2. Step 2: Identify the missing parentheses error

   Without parentheses, commit is just a reference, so changes are not saved.

3. Final Answer:

   Missing parentheses after commit method call -> Option A

4. Quick Check:

   commit() needs parentheses to execute [OK]

Hint: Always call commit() with parentheses [OK]

Common Mistakes:

• Forgetting parentheses on commit
• Using db.add instead of db.session.add
• Calling commit before add

5. You want to implement a repository method that returns all users whose email ends with '@example.com'. Which of these is the best way to write it using SQLAlchemy in Flask?

hard

A. def get_example_users(self): return User.query.filter(User.email.contains('@example.com')).first()

B. def get_example_users(self): return User.query.filter_by(email='@example.com').all()

C. def get_example_users(self): return User.query.filter(User.email.endswith('@example.com')).all()

D. def get_example_users(self): return User.query.filter(User.email == '@example.com').all()

Solution

1. Step 1: Understand filtering by string suffix in SQLAlchemy

   To filter emails ending with a string, use filter(User.email.endswith(...)).

2. Step 2: Check each option's correctness

   def get_example_users(self): return User.query.filter(User.email.endswith('@example.com')).all() uses endswith and all() to get all matches, which is correct. def get_example_users(self): return User.query.filter_by(email='@example.com').all() uses filter_by with exact match, not suffix. def get_example_users(self): return User.query.filter(User.email.contains('@example.com')).first() uses contains but returns only first match. def get_example_users(self): return User.query.filter(User.email == '@example.com').all() uses equality check, not suffix.

3. Final Answer:

   def get_example_users(self): return User.query.filter(User.email.endswith('@example.com')).all() -> Option C

4. Quick Check:

   Use endswith() + all() for suffix filtering [OK]

Hint: Use endswith() for suffix filtering in queries [OK]

Common Mistakes:

• Using filter_by for partial matches
• Using contains but returning only first result
• Using equality operator instead of endswith