Repository pattern for data access in Express - Deep Dive

Overview - Repository pattern for data access

What is it?

The Repository pattern is a way to organize how your application talks to data sources like databases. It acts like a middleman that hides the details of data storage and retrieval. This means your app code doesn't need to know if data comes from a database, a file, or somewhere else. It helps keep your code clean and easier to change later.

Why it matters

Without the Repository pattern, your app code would be tangled with database details, making it hard to update or switch data sources. This can cause bugs and slow down development. Using this pattern makes your app more flexible and easier to maintain, so you can focus on building features instead of fixing data access problems.

Where it fits

Before learning this, you should understand basic Express app structure and how to connect to databases. After this, you can learn about service layers, dependency injection, and testing strategies that use repositories to improve code quality.

Mental Model

Core Idea

A repository is a simple interface that hides how data is stored and retrieved, letting your app work with data without knowing the details.

Think of it like...

Imagine a library where you ask a librarian for a book instead of searching the shelves yourself. The librarian knows where every book is and handles getting it for you. You just ask for the book by name and get it back.

┌─────────────┐       ┌───────────────┐       ┌───────────────┐
│ Application │──────▶│ Repository    │──────▶│ Data Source   │
│ (Express)   │       │ (Interface)   │       │ (Database)    │
└─────────────┘       └───────────────┘       └───────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding Data Access Basics

Concept: Learn how Express apps typically access data directly from databases.

In a simple Express app, you might write code that talks directly to the database inside your route handlers. For example, using a database client to run queries right where you handle HTTP requests.

Result

Your app can get and save data, but the database code is mixed with your app logic.

Knowing this shows why mixing data access and app logic can make code harder to maintain and test.

2

Foundation

What is a Repository Interface?

Concept: Introduce the idea of a repository as a simple set of methods to get and save data.

A repository defines methods like findAll(), findById(id), save(item), and delete(id). These methods hide the database details. Your app calls these methods instead of writing queries directly.

Result

Your app code becomes cleaner and only talks to the repository, not the database.

Understanding this separation helps keep your app flexible and easier to change.

3

Intermediate

Implementing a Repository in Express

🤔Before reading on: do you think the repository should know about HTTP requests or just data operations? Commit to your answer.

Concept: Learn how to write a repository class that handles database queries separately from Express routes.

Create a class like UserRepository with methods that use a database client (e.g., MongoDB or PostgreSQL) to fetch or save users. Your Express routes then call these methods instead of querying the database directly.

Result

Express routes become simpler and focused on HTTP logic, while the repository handles data details.

Knowing this separation improves code organization and makes testing easier by isolating data access.

4

Intermediate

Benefits for Testing and Maintenance

🤔Before reading on: do you think testing a repository is easier or harder than testing direct database calls? Commit to your answer.

Concept: Understand how repositories make it easier to write tests and change data sources without breaking app code.

Because repositories have a clear interface, you can replace them with fake versions in tests. This means you can test your app logic without needing a real database. Also, if you switch databases, only the repository code changes.

Result

Tests run faster and your app is more resilient to changes in data storage.

Understanding this shows why repositories are key for scalable and maintainable apps.

5

Advanced

Handling Multiple Data Sources

🤔Before reading on: can one repository handle data from both a database and an API? Commit to your answer.

Concept: Learn how repositories can combine data from different sources while keeping the app code simple.

A repository can fetch data from a database and also call external APIs if needed. It merges or transforms data before returning it to the app. The app still calls the same repository methods without knowing where data comes from.

Result

Your app can use complex data sources without changing its logic.

Knowing this flexibility helps design powerful repositories that simplify complex data needs.

6

Expert

Avoiding Common Repository Pitfalls

🤔Before reading on: do you think repositories should contain business logic or only data access? Commit to your answer.

Concept: Understand the boundary between repositories and business logic to keep code clean and maintainable.

Repositories should only handle data access, not business rules. Putting business logic in repositories mixes concerns and makes code harder to test and change. Instead, use a service layer for business logic that calls repositories.

Result

Clear separation of concerns leads to cleaner, more maintainable code.

Understanding this boundary prevents tangled code and supports better app architecture.

Under the Hood

At runtime, the repository acts as an abstraction layer. When the app calls a repository method, it triggers database queries or API calls hidden inside. This isolates the app from database drivers or query languages. The repository manages connections, query building, and data transformation before returning results.

Why designed this way?

The pattern was created to reduce tight coupling between app logic and data storage. Early apps mixed SQL queries with business code, making changes risky. The repository pattern emerged to provide a stable interface, allowing data storage to evolve independently from app logic.

┌─────────────┐
│ Application │
└─────┬───────┘
      │ calls
┌─────▼───────┐
│ Repository  │
│ Interface   │
└─────┬───────┘
      │ executes
┌─────▼─────────────┐
│ Database Client or │
│ External API      │
└───────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does the repository pattern mean you never write SQL or database queries? Commit to yes or no.

Common Belief: Repositories mean you don't write any SQL or database queries in your app.

Reality: Repositories still contain database queries or calls, but they hide these details from the rest of the app.

Why it matters: Thinking you never write queries can lead to ignoring optimization or database-specific features needed inside repositories.

Quick: Should repositories contain business rules like user permissions? Commit to yes or no.

Common Belief: Repositories should include business logic like validation and permissions.

Reality: Repositories should only handle data access; business logic belongs in separate service layers.

Why it matters: Mixing concerns makes code harder to maintain and test, causing bugs and confusion.

Quick: Can one repository handle multiple unrelated data sources easily? Commit to yes or no.

Common Belief: A single repository can manage many different data sources without issues.

Reality: Repositories work best when focused on one data type or source; mixing too many can cause complexity and confusion.

Why it matters: Overloading repositories leads to tangled code and harder debugging.

Quick: Does using repositories automatically make your app faster? Commit to yes or no.

Common Belief: Using repositories always improves app performance.

Reality: Repositories improve code organization but do not inherently speed up data access; performance depends on query efficiency and database design.

Why it matters: Assuming repositories boost speed can lead to ignoring real performance tuning needs.

Expert Zone

1

Repositories can implement caching internally to reduce database calls without exposing caching logic to the app.

2

Using dependency injection with repositories allows swapping implementations easily for testing or different environments.

3

Repositories can return domain-specific objects or data transfer objects (DTOs) to decouple database schemas from app models.

When NOT to use

Avoid repositories in very simple apps where direct database calls are straightforward and unlikely to change. Also, for complex queries involving multiple tables or aggregations, consider using specialized query services or ORM features directly.

Production Patterns

In real-world Express apps, repositories are often paired with service layers that handle business logic. Repositories are injected into services using dependency injection frameworks. This setup supports unit testing by mocking repositories and enables switching databases without changing app code.

Connections

Service Layer Pattern

Builds-on

Repositories handle data access while service layers handle business logic; understanding both clarifies clean app architecture.

Dependency Injection

Supports

Injecting repositories into services or controllers allows easy swapping of implementations, improving testability and flexibility.

Database Abstraction in Operating Systems

Similar pattern

Just like OS abstracts hardware details from applications, repositories abstract data storage details from app logic, showing a common design principle across fields.

Common Pitfalls

#1 Mixing business logic inside repositories.

Wrong approach:

class UserRepository {
async saveUserIfAllowed(user, currentUser) {
if (!currentUser.isAdmin) throw new Error('No permission');
// save user to DB
}
}

Correct approach:

class UserRepository {
async save(user) {
// save user to DB
}
}

class UserService {
constructor(userRepo) { this.userRepo = userRepo; }
async saveUserIfAllowed(user, currentUser) {
if (!currentUser.isAdmin) throw new Error('No permission');
await this.userRepo.save(user);
}
}

Root cause:

Confusing data access responsibilities with business rules leads to tangled code.

#2 Calling database queries directly in Express routes.

Wrong approach:

app.get('/users', async (req, res) => {
const users = await db.query('SELECT * FROM users');
res.json(users);
});

Correct approach:

app.get('/users', async (req, res) => {
const users = await userRepository.findAll();
res.json(users);
});

Root cause:

Not separating concerns causes duplicated and hard-to-maintain code.

#3 Creating one repository for all data types.

Wrong approach:

class Repository {
async findUsers() { /* ... */ }
async findOrders() { /* ... */ }
async saveProduct() { /* ... */ }
}

Correct approach:

class UserRepository { async findAll() { /* ... */ } }
class OrderRepository { async findAll() { /* ... */ } }
class ProductRepository { async save() { /* ... */ } }

Root cause:

Trying to do too much in one place leads to complex and fragile code.

Key Takeaways

The Repository pattern separates data access from app logic, making code cleaner and easier to maintain.

Repositories provide a simple interface hiding database details, so your app code stays flexible.

Using repositories improves testability by allowing fake implementations during testing.

Repositories should only handle data operations; business logic belongs elsewhere to keep concerns separate.

Understanding and applying this pattern helps build scalable, maintainable Express applications.

Practice

1. What is the main purpose of using the Repository pattern in an Express app?

easy

A. To manage user authentication

B. To handle HTTP requests and responses

C. To style the frontend components

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 isolate data access logic from the rest of the application.

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

   In Express apps, it helps keep business logic clean by moving database queries into repositories.

3. Final Answer:

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

4. Quick Check:

   Repository pattern = separate data access [OK]

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

Common Mistakes:

• Confusing repository with routing or middleware
• Thinking it handles UI or styling
• Mixing it with authentication logic

2. Which of the following is the correct way to define a repository class in Express using ES6 syntax?

easy

A. class UserRepository { getAll() { /* code */ } }

B. var UserRepository = new Object({ getAll: function() {} })

C. const UserRepository = () => { return { getAll() {} } }

D. function UserRepository() { this.getAll = () => {}; }

Solution

1. Step 1: Identify ES6 class syntax

   ES6 classes use the class keyword with methods inside without the function keyword.

2. Step 2: Match the correct syntax

   class UserRepository { getAll() { /* code */ } } correctly defines a class with a method getAll() using ES6 syntax.

3. Final Answer:

   class UserRepository { getAll() { /* code */ } } -> Option A

4. Quick Check:

   ES6 class syntax = class UserRepository { getAll() { /* code */ } } [OK]

Hint: ES6 classes use 'class' keyword and method shorthand [OK]

Common Mistakes:

• Using function keyword inside class methods
• Confusing arrow functions with class methods
• Using old object syntax instead of class

3. Given this repository method, what will console.log(users) output?

class UserRepository {
  constructor() {
    this.users = [{id:1, name:'Anna'}, {id:2, name:'Bob'}];
  }
  getAll() {
    return this.users;
  }
}
const repo = new UserRepository();
const users = repo.getAll();
console.log(users);

medium

A. [{id:1, name:'Anna'}, {id:2, name:'Bob'}]

B. undefined

C. Error: getAll is not a function

D. []

Solution

1. Step 1: Understand the constructor initialization

   The constructor sets this.users to an array of two user objects.

2. Step 2: Check the getAll method return value

   The getAll() method returns this.users, so calling it returns the array.

3. Final Answer:

   [{id:1, name:'Anna'}, {id:2, name:'Bob'}] -> Option A

4. Quick Check:

   getAll returns users array [OK]

Hint: getAll returns stored users array directly [OK]

Common Mistakes:

• Assuming getAll returns undefined or empty
• Confusing method call with property access
• Expecting an error due to missing binding

4. Identify the error in this repository code snippet:

class ProductRepository {
  constructor() {
    this.products = [];
  }
  add(product) {
    this.products.push(product);
  }
  getAll() {
    return products;
  }
}

medium

A. Missing return statement in getAll method

B. Using undefined variable 'products' instead of 'this.products'

C. Constructor does not initialize products array

D. add method does not push product correctly

Solution

1. Step 1: Check variable usage in getAll method

   The method returns products but this variable is not defined in the method scope.

2. Step 2: Correct usage of instance variable

   It should return this.products to access the class property.

3. Final Answer:

   Using undefined variable 'products' instead of 'this.products' -> Option B

4. Quick Check:

   Use this.products to access class property [OK]

Hint: Use 'this.' to access class properties inside methods [OK]

Common Mistakes:

• Forgetting 'this.' prefix for class properties
• Assuming variables are global inside class methods
• Ignoring constructor initialization

5. You want to extend a base repository to add a custom method findByEmail(email) for users. Which approach correctly implements this in Express?

hard

A. const UserRepository = Object.create(BaseRepository);
UserRepository.findByEmail = function(email) {
return this.data.find(u => u.email === email);
};

B. function UserRepository() {
this.findByEmail = (email) => this.data.find(u => u.email === email);
}
UserRepository.prototype = BaseRepository.prototype;

C. class UserRepository extends BaseRepository {
findByEmail(email) {
return this.data.find(u => u.email === email);
}
}

D. class UserRepository {
findByEmail(email) {
return BaseRepository.data.find(u => u.email === email);
}
}

Solution

1. Step 1: Understand class inheritance in ES6

   Extending a base class uses extends keyword and super() if constructor is needed.

2. Step 2: Check method implementation accessing instance data

   class UserRepository extends BaseRepository { findByEmail(email) { return this.data.find(u => u.email === email); } } correctly extends BaseRepository and uses this.data to find user by email.

3. Final Answer:

   class UserRepository extends BaseRepository { findByEmail(email) { return this.data.find(u => u.email === email); } } -> Option C

4. Quick Check:

   Extend base class and add method using this.data [OK]

Hint: Use 'extends' to inherit and add custom methods in subclass [OK]

Common Mistakes:

• Not using 'extends' for inheritance
• Accessing base class data incorrectly
• Overwriting prototype without proper inheritance