Концепція провайдерів у NestJS

Короткий зміст

• Що таке Provider у контексті NestJS
• Декоратор @Injectable(): позначення класу як провайдера
• Реєстрація провайдерів у масиві providers модуля
• Провайдери як основа для ін'єкції залежностей
• Типи провайдерів: сервіси, репозиторії, фабрики, хелпери
• Автоматичне створення екземплярів через DI-контейнер
• Singleton-патерн за замовчуванням (один екземпляр на застосунок)
• Час життя провайдера: створення при ініціалізації модуля
• Відмінність провайдера від контролера
• Коли створювати власні провайдери

Архітектурний контекст: від контролерів до провайдерів

У попередніх лекціях ми розглянули контролери — основний компонент NestJS для обробки HTTP-запитів. Контролери приймають вхідні запити, маршрутизують їх до відповідних методів-обробників (handlers) та формують відповіді. Проте фундаментальний принцип чистої архітектури застосунків полягає у розділенні відповідальностей (Separation of Concerns): контролери мають обмежуватися лише маршрутизацією та обробкою HTTP-специфічних деталей, тоді як уся бізнес-логіка, робота з даними та складні обчислення виносяться в окремі компоненти.

Саме для цього NestJS впроваджує концепцію провайдерів (providers) — архітектурних блоків, які інкапсулюють логіку застосунку та можуть бути ін'єктовані у контролери або інші провайдери через механізм ін'єкції залежностей (Dependency Injection, DI). Провайдери є серцем системи управління залежностями в NestJS та дозволяють створювати модульні, тестовні та легко масштабовані застосунки.

Що таке Provider у контексті NestJS

Provider у NestJS — це клас, який позначений спеціальним декоратором @Injectable() та може бути зареєстрований в системі ін'єкції залежностей фреймворку. Провайдери є основним механізмом для організації повторно використовуваної логіки застосунку: сервіси (services), репозиторії (repositories), фабрики (factories), допоміжні класи (helpers), утиліти та інші компоненти.

Фундаментальна ідея провайдерів полягає в тому, що залежності між класами встановлюються не вручну через new, а декларативно через конструктори. Коли контролеру потрібен сервіс для роботи з даними користувачів, він не створює екземпляр цього сервісу самостійно, а просто оголошує його у своєму конструкторі. NestJS автоматично розв'язує (resolve) цю залежність: знаходить відповідний провайдер, створює його екземпляр (якщо потрібно) та передає його у контролер. Цей процес називається ін'єкцією залежностей і є однією з ключових переваг фреймворку.

Розглянемо простий приклад. Припустімо, у нас є контролер UsersController, який має обробляти HTTP-запити для роботи з користувачами. Замість того, щоб писати всю логіку всередині методів контролера, ми створюємо окремий провайдер UsersService, який інкапсулює бізнес-логіку: пошук користувачів у базі даних, валідацію email, хешування паролів тощо.

import { Injectable } from '@nestjs/common';

@Injectable()
export class UsersService {
  private users = [
    { id: 1, name: 'Іван Петренко', email: 'ivan@example.com' },
    { id: 2, name: 'Марія Коваль', email: 'maria@example.com' }
  ];

  findAll() {
    return this.users;
  }

  findOne(id: number) {
    return this.users.find(user => user.id === id);
  }
}

У цьому прикладі клас UsersService позначений декоратором @Injectable(), що дозволяє NestJS розпізнати його як провайдер. Тепер ми можемо ін'єктувати цей сервіс у контролер:

import { Controller, Get, Param } from '@nestjs/common';
import { UsersService } from './users.service';

@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Get()
  findAll() {
    return this.usersService.findAll();
  }

  @Get(':id')
  findOne(@Param('id') id: string) {
    return this.usersService.findOne(+id);
  }
}

Зверніть увагу на конструктор контролера: параметр private readonly usersService: UsersService одночасно виконує три дії завдяки можливостям TypeScript та NestJS:

1. Оголошує залежність від UsersService
2. Автоматично створює приватну властивість usersService у класі
3. Сигналізує DI-контейнеру про необхідність ін'єкції екземпляру UsersService

Коли NestJS ініціалізує контролер, він розпізнає тип параметра конструктора (UsersService), знаходить відповідний зареєстрований провайдер у модулі та автоматично передає його екземпляр у конструктор. Це і є суть ін'єкції залежностей: залежності надаються ззовні, а не створюються всередині класу.

Декоратор @Injectable(): позначення класу як провайдера

Декоратор @Injectable() є ключовим маркером, який перетворює звичайний TypeScript-клас на провайдер, що може управлятися системою ін'єкції залежностей NestJS. Цей декоратор інформує фреймворк про те, що клас може мати власні залежності, які повинні бути автоматично розв'язані при створенні його екземпляру.

На рівні метапрограмування @Injectable() прикріплює до класу спеціальні метадані, які NestJS використовує під час побудови графу залежностей (dependency graph). Коли фреймворк аналізує модуль, він зчитує всі класи, позначені @Injectable(), та реєструє їх у внутрішньому DI-контейнері, створюючи мапу доступних провайдерів.

import { Injectable } from '@nestjs/common';

@Injectable()
export class EmailService {
  sendEmail(to: string, subject: string, body: string): void {
    console.log(`Відправка email до ${to}: ${subject}`);
    // Логіка відправки email через SMTP-сервер
  }
}

У цьому прикладі клас EmailService позначено декоратором @Injectable(), що дозволяє використовувати його як залежність в інших провайдерах або контролерах. Наприклад, якщо нам потрібно відправляти email після реєстрації користувача, ми можемо ін'єктувати EmailService у UsersService:

import { Injectable } from '@nestjs/common';
import { EmailService } from './email.service';

@Injectable()
export class UsersService {
  constructor(private readonly emailService: EmailService) {}

  async createUser(name: string, email: string) {
    // Логіка створення користувача в базі даних
    const user = { id: Date.now(), name, email };

    // Відправка привітального email
    this.emailService.sendEmail(
      email,
      'Ласкаво просимо!',
      `Вітаємо, ${name}! Ваш обліковий запис створено.`
    );

    return user;
  }
}

Тут UsersService також позначений декоратором @Injectable(), оскільки він сам має залежність (EmailService). NestJS автоматично розв'язує ланцюг залежностей: спочатку створює екземпляр EmailService, потім передає його у конструктор UsersService, а вже готовий UsersService ін'єктує у контролер.

Реєстрація провайдерів у масиві providers модуля

Наявність декоратора @Injectable() — це лише перший крок. Щоб NestJS дійсно розпізнав клас як провайдер та міг його використовувати, необхідно зареєструвати цей клас у модулі через масив providers у декораторі @Module().

Модуль (module) у NestJS — це логічний контейнер, який групує пов'язані між собою контролери та провайдери. Кожен модуль описується через декоратор @Module(), який приймає об'єкт конфігурації з кількома масивами: controllers, providers, imports, exports. Саме у масиві providers ми перелічуємо всі провайдери, які належать до цього модуля.

import { Module } from '@nestjs/common';
import { UsersController } from './users.controller';
import { UsersService } from './users.service';
import { EmailService } from './email.service';

@Module({
  controllers: [UsersController],
  providers: [UsersService, EmailService]
})
export class UsersModule {}

У цьому прикладі модуль UsersModule реєструє два провайдери: UsersService та EmailService. Після реєстрації NestJS додає ці класи до свого внутрішнього DI-контейнера, що дозволяє використовувати їх як залежності у контролерах або інших провайдерах цього модуля.

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF

package "UsersModule" #F1F5F9 {
  rectangle "providers: [\n  UsersService,\n  EmailService\n]" as Providers #DBEAFE
}

rectangle "DI Container (IoC)" as Container #DCFCE7

rectangle "UsersController" as Controller #FEF3C7
rectangle "UsersService" as Service #E0E7FF
rectangle "EmailService" as Email #E0E7FF

Providers --> Container : Реєстрація\nпровайдерів
Container --> Service : Створення\nекземпляру
Container --> Email : Створення\nекземпляру
Container --> Controller : Ін'єкція\nUsersService
Service --> Email : Ін'єкція\nEmailService

note right of Container #FEF3C7
  DI-контейнер автоматично:
  1. Аналізує залежності
  2. Створює екземпляри
  3. Впроваджує у споживачів
end note

@enduml

Коли NestJS запускає застосунок, він проходить через усі зареєстровані модулі та будує граф залежностей (dependency graph) — структуру, що визначає порядок створення екземплярів провайдерів на основі їх взаємозалежностей. Якщо UsersService залежить від EmailService, DI-контейнер спочатку створить екземпляр EmailService, а потім передасть його у конструктор UsersService.

Провайдери як основа для ін'єкції залежностей

Як уже згадувалося, провайдери тісно пов'язані з патерном Dependency Injection (ін'єкція залежностей). Цей патерн є одним із фундаментальних принципів SOLID — набору правил проєктування об'єктно-орієнтованих систем, спрямованих на створення гнучкого, тестовного та підтримуваного коду.

Суть ін'єкції залежностей полягає в інверсії контролю (Inversion of Control, IoC): замість того, щоб клас самостійно створював потрібні йому об'єкти через оператор new, він оголошує свої залежності як параметри конструктора, а зовнішня система (DI-контейнер) відповідає за їх надання. Це дозволяє:

1. Зменшити зв'язаність (coupling) між класами: контролер не знає, як саме створюється UsersService, він просто отримує готовий екземпляр
2. Полегшити тестування: під час unit-тестування ми можемо передати фіктивний (mock) об'єкт замість реального сервісу
3. Підвищити гнучкість: легко замінити реалізацію сервісу без зміни коду контролера
4. Уникнути дублювання коду: один екземпляр провайдера може бути використаний у кількох місцях

Розглянемо порівняння двох підходів: без ін'єкції залежностей та з ін'єкцією залежностей.

import { Controller, Get } from '@nestjs/common';
import { UsersService } from './users.service';

@Controller('users')
export class UsersController {
  private readonly usersService: UsersService;

  constructor() {
    // Контролер самостійно створює екземпляр сервісу
    this.usersService = new UsersService();
  }

  @Get()
  findAll() {
    return this.usersService.findAll();
  }
}

import { Controller, Get } from '@nestjs/common';
import { UsersService } from './users.service';

@Controller('users')
export class UsersController {
  // Залежність надається ззовні через конструктор
  constructor(private readonly usersService: UsersService) {}

  @Get()
  findAll() {
    return this.usersService.findAll();
  }
}

У першому варіанті (без DI) контролер жорстко прив'язаний до конкретної реалізації UsersService. Якщо згодом ми захочемо використати іншу реалізацію (наприклад, для тестування), доведеться змінювати код контролера. У другому варіанті (з DI) контролер лише оголошує, що йому потрібен UsersService, а DI-контейнер вирішує, яку саме реалізацію надати. Це дозволяє легко підмінювати сервіси для тестування або зміни логіки без торкання коду контролера.

Типи провайдерів: сервіси, репозиторії, фабрики, хелпери

Провайдери у NestJS можуть виконувати різноманітні ролі залежно від архітектури застосунку. Розглянемо найпоширеніші типи провайдерів та їх призначення:

Сервіси (Services)

Сервіси — це найбільш універсальний тип провайдерів, який інкапсулює бізнес-логіку застосунку. Сервіси відповідають за виконання операцій, що виходять за межі простої маршрутизації HTTP-запитів: валідація даних, виклики зовнішніх API, обробка файлів, відправка email, робота з черговими повідомленнями тощо.

Приклад сервісу для роботи з товарами в інтернет-магазині:

import { Injectable } from '@nestjs/common';

@Injectable()
export class ProductsService {
  private products = [
    { id: 1, name: 'Ноутбук Dell', price: 25000 },
    { id: 2, name: 'Мишка Logitech', price: 800 }
  ];

  findAll() {
    return this.products;
  }

  findById(id: number) {
    return this.products.find(p => p.id === id);
  }

  calculateTotalPrice(productIds: number[]): number {
    return productIds
      .map(id => this.findById(id))
      .filter(p => p !== undefined)
      .reduce((sum, p) => sum + p.price, 0);
  }
}

Репозиторії (Repositories)

Репозиторії — це провайдери, що відповідають за комунікацію з джерелами даних: реляційними базами даних (PostgreSQL, MySQL), NoSQL-базами (MongoDB), кешем (Redis), файловими системами тощо. Репозиторії інкапсулюють SQL-запити або ORM-виклики, забезпечуючи абстракцію над рівнем доступу до даних (Data Access Layer).

Приклад репозиторію для роботи з користувачами через TypeORM:

import { Injectable } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { User } from './user.entity';

@Injectable()
export class UsersRepository {
  constructor(
    @InjectRepository(User)
    private readonly repository: Repository<User>
  ) {}

  async findAll(): Promise<User[]> {
    return this.repository.find();
  }

  async findByEmail(email: string): Promise<User | null> {
    return this.repository.findOne({ where: { email } });
  }

  async create(userData: Partial<User>): Promise<User> {
    const user = this.repository.create(userData);
    return this.repository.save(user);
  }
}

Фабрики (Factories)

Фабрики — це провайдери, що використовуються для динамічного створення об'єктів або конфігурацій на основі умов виконання. Вони особливо корисні, коли створення об'єкта вимагає складної логіки або асинхронних операцій.

Приклад фабрики для створення клієнта HTTP-запитів з різними налаштуваннями:

import { Injectable } from '@nestjs/common';
import axios, { AxiosInstance } from 'axios';

@Injectable()
export class HttpClientFactory {
  createClient(baseURL: string, timeout: number = 5000): AxiosInstance {
    return axios.create({
      baseURL,
      timeout,
      headers: {
        'User-Agent': 'NestJS-Application/1.0'
      }
    });
  }

  createAuthenticatedClient(baseURL: string, token: string): AxiosInstance {
    return axios.create({
      baseURL,
      headers: {
        'Authorization': `Bearer ${token}`
      }
    });
  }
}

Хелпери та утиліти (Helpers/Utils)

Хелпери — це провайдери, які надають допоміжні функції загального призначення: форматування дат, парсинг рядків, генерація унікальних ідентифікаторів, шифрування паролів тощо. Вони не містять бізнес-логіки, але забезпечують багаторазово використовувані інструменти для інших провайдерів.

Приклад хелпера для роботи з паролями:

import { Injectable } from '@nestjs/common';
import * as bcrypt from 'bcrypt';

@Injectable()
export class PasswordHelper {
  private readonly saltRounds = 10;

  async hash(plainPassword: string): Promise<string> {
    return bcrypt.hash(plainPassword, this.saltRounds);
  }

  async compare(plainPassword: string, hashedPassword: string): Promise<boolean> {
    return bcrypt.compare(plainPassword, hashedPassword);
  }
}

Автоматичне створення екземплярів через DI-контейнер

Одна з найбільших переваг системи провайдерів NestJS — це автоматизація процесу створення екземплярів класів та управління їх життєвим циклом. Розробнику не потрібно вручну створювати об'єкти через new або відстежувати, коли їх видаляти — цим займається DI-контейнер.

Коли застосунок запускається, NestJS виконує наступні кроки:

1. Аналіз модулів: фреймворк сканує всі зареєстровані модулі через декоратор @Module()
2. Побудова графу залежностей: визначається, які провайдери від яких залежать на основі параметрів конструкторів
3. Розв'язання залежностей: DI-контейнер обчислює правильний порядок ініціалізації провайдерів (від залежностей до споживачів)
4. Створення екземплярів: провайдери створюються у визначеному порядку, кожна залежність передається у конструктор класу
5. Кешування екземплярів: за замовчуванням екземпляри провайдерів зберігаються як singleton (один екземпляр на весь застосунок)

Розглянемо приклад із ланцюгом залежностей:

// email.service.ts
@Injectable()
export class EmailService {
  sendEmail(to: string, subject: string): void {
    console.log(`Email відправлено до ${to}`);
  }
}

// logger.service.ts
@Injectable()
export class LoggerService {
  log(message: string): void {
    console.log(`[LOG] ${new Date().toISOString()} - ${message}`);
  }
}

// users.service.ts
@Injectable()
export class UsersService {
  constructor(
    private readonly emailService: EmailService,
    private readonly logger: LoggerService
  ) {}

  createUser(name: string, email: string) {
    this.logger.log(`Створення користувача: ${name}`);
    const user = { id: Date.now(), name, email };
    this.emailService.sendEmail(email, 'Вітаємо!');
    return user;
  }
}

// users.controller.ts
@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Post()
  create(@Body() createUserDto: { name: string; email: string }) {
    return this.usersService.createUser(createUserDto.name, createUserDto.email);
  }
}

// users.module.ts
@Module({
  controllers: [UsersController],
  providers: [UsersService, EmailService, LoggerService]
})
export class UsersModule {}

У цьому прикладі UsersController залежить від UsersService, який у свою чергу залежить від EmailService та LoggerService. DI-контейнер автоматично визначає порядок створення:

1. Створюється EmailService (немає залежностей)
2. Створюється LoggerService (немає залежностей)
3. Створюється UsersService (отримує EmailService та LoggerService)
4. Створюється UsersController (отримує UsersService)

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
autonumber

participant "NestJS Bootstrap" as Bootstrap #DBEAFE
participant "DI Container" as Container #DCFCE7
participant "EmailService" as Email #E0E7FF
participant "LoggerService" as Logger #E0E7FF
participant "UsersService" as Users #E0E7FF
participant "UsersController" as Controller #FEF3C7

Bootstrap -> Container : Аналіз модуля UsersModule
note over Container #FEF3C7
  Виявлено залежності:
  - EmailService: немає залежностей
  - LoggerService: немає залежностей
  - UsersService: залежить від Email, Logger
  - UsersController: залежить від UsersService
end note

Container -> Email : new EmailService()
activate Email
Email --> Container : екземпляр EmailService
deactivate Email

Container -> Logger : new LoggerService()
activate Logger
Logger --> Container : екземпляр LoggerService
deactivate Logger

Container -> Users : new UsersService(email, logger)
activate Users
Users --> Container : екземпляр UsersService
deactivate Users

Container -> Controller : new UsersController(users)
activate Controller
Controller --> Container : екземпляр UsersController
deactivate Controller

Bootstrap -> Bootstrap : Застосунок готовий до обробки запитів

@enduml

Singleton-патерн за замовчуванням: один екземпляр на застосунок

Важливою особливістю провайдерів у NestJS є те, що за замовчуванням вони створюються як singleton (одинак) — патерн проєктування, при якому для кожного класу існує лише один екземпляр, який використовується у всіх місцях застосунку. Це означає, що якщо UsersService ін'єктується у три різні контролери, всі три контролери отримають той самий екземпляр UsersService, а не три окремі копії.

Singleton-патерн має кілька важливих наслідків:

1. Економія пам'яті: замість створення десятків копій одного класу в пам'яті зберігається лише один екземпляр
2. Спільний стан: якщо провайдер зберігає будь-який стан (наприклад, кеш або лічильник), цей стан буде спільним для всіх споживачів провайдера
3. Швидкість ініціалізації: екземпляри створюються лише один раз під час запуску застосунку, а не при кожному запиті

Розглянемо приклад із провайдером, що підтримує внутрішній стан:

import { Injectable } from '@nestjs/common';

@Injectable()
export class CounterService {
  private count = 0;

  increment(): number {
    return ++this.count;
  }

  getCount(): number {
    return this.count;
  }
}

Оскільки CounterService є singleton, всі виклики методу increment() з різних місць застосунку працюватимуть з одним і тим самим лічильником. Якщо перший контролер викликає increment() і отримує значення 1, другий контролер при виклику отримає значення 2, оскільки обидва працюють з одним екземпляром сервісу.

У деяких випадках може знадобитися створювати новий екземпляр провайдера для кожного HTTP-запиту. Для цього NestJS надає механізм scopes (області видимості), який дозволяє контролювати життєвий цикл провайдерів. Проте в більшості сценаріїв singleton-патерн є оптимальним рішенням з точки зору продуктивності та використання ресурсів.

Час життя провайдера: створення при ініціалізації модуля

Життєвий цикл провайдерів у NestJS чітко визначений та передбачуваний. За замовчуванням всі провайдери створюються під час ініціалізації застосунку, а не при першому використанні. Це означає, що коли ви запускаєте сервер NestJS, фреймворк одразу аналізує всі модулі, створює екземпляри всіх зареєстрованих провайдерів у правильному порядку та зберігає їх у DI-контейнері.

Процес ініціалізації провайдерів відбувається у такій послідовності:

Важливим наслідком цієї архітектури є те, що помилки у конфігурації провайдерів (відсутність реєстрації, циклічні залежності, невідповідність типів) виявляються одразу під час запуску застосунку, а не у момент надходження першого запиту. Це дозволяє уникнути ситуацій, коли застосунок здається працюючим, але падає при першому зверненні до певного ендпоінту.

У цьому прикладі виводу консолі чітко видно етапи ініціалізації: спочатку завантажуються залежності AppModule, потім UsersModule, після чого відбувається реєстрація маршрутів контролерів. Якби у UsersModule була помилка у реєстрації провайдерів, застосунок не запустився б і повідомив би про проблему на етапі ініціалізації.

Відмінність провайдера від контролера

Студенти часто плутають провайдери та контролери, оскільки обидва є класами, що декоруються та реєструються у модулях. Проте між ними існують фундаментальні відмінності за призначенням, відповідальностями та способом взаємодії із зовнішнім світом.

Розглянемо порівняльний приклад, що демонструє розподіл відповідальностей між контролером та провайдером:

import { Controller, Get, Post, Body, Param, HttpStatus, HttpException } from '@nestjs/common';
import { UsersService } from './users.service';

@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Get()
  findAll() {
    // Контролер лише делегує виклик до сервісу
    return this.usersService.findAll();
  }

  @Get(':id')
  findOne(@Param('id') id: string) {
    const user = this.usersService.findById(+id);
    
    if (!user) {
      // Контролер обробляє HTTP-специфічну логіку
      throw new HttpException('Користувача не знайдено', HttpStatus.NOT_FOUND);
    }
    
    return user;
  }

  @Post()
  create(@Body() createUserDto: { name: string; email: string }) {
    // Контролер валідує формат запиту та делегує створення
    return this.usersService.create(createUserDto);
  }
}

import { Injectable } from '@nestjs/common';

@Injectable()
export class UsersService {
  private users = [
    { id: 1, name: 'Іван', email: 'ivan@example.com' }
  ];

  findAll() {
    // Сервіс містить логіку доступу до даних
    return this.users;
  }

  findById(id: number) {
    // Сервіс виконує пошук за критерієм
    return this.users.find(u => u.id === id);
  }

  create(userData: { name: string; email: string }) {
    // Сервіс містить бізнес-логіку створення
    const newUser = {
      id: this.users.length + 1,
      ...userData
    };
    
    // Валідація бізнес-правил
    if (this.users.some(u => u.email === userData.email)) {
      throw new Error('Користувач з таким email вже існує');
    }
    
    this.users.push(newUser);
    return newUser;
  }
}

У цьому прикладі контролер займається лише HTTP-специфічними аспектами: обробкою параметрів запиту (@Param, @Body), формуванням HTTP-відповідей та генерацією HTTP-винятків (HttpException). Вся бізнес-логіка — пошук користувачів, валідація унікальності email, створення нових записів — знаходиться у сервісі.

Така архітектура надає кілька переваг:

1. Повторне використання логіки: UsersService може використовуватися не тільки в HTTP-контролерах, але й у WebSocket-гейтвеях, CLI-командах, фонових завданнях (background jobs)
2. Простота тестування: сервіс можна тестувати ізольовано без HTTP-сервера
3. Незалежність від протоколу: якщо ви змінюєте HTTP на gRPC, контролери зміняться, але сервіси залишаться незмінними
4. Чистота коду: кожен компонент має чітко визначену відповідальність

Коли створювати власні провайдери

Розуміння того, коли саме слід створювати власні провайдери, є важливою частиною проєктування чистої архітектури NestJS-застосунків. Не вся логіка потребує винесення у провайдери — іноді простіше залишити код безпосередньо у методі контролера. Розглянемо критерії прийняття цього рішення.

Створюйте провайдер, якщо логіка:

1. Повторюється у кількох місцях

Якщо один і той самий код з'являється у різних контролерах або методах, це сигнал до створення провайдера. Дублювання коду (code duplication) порушує принцип DRY (Don't Repeat Yourself) та ускладнює підтримку.

// ❌ Погано: дублювання логіки хешування паролів у кількох контролерах
@Controller('auth')
export class AuthController {
  @Post('register')
  async register(@Body() dto: RegisterDto) {
    const salt = await bcrypt.genSalt(10);
    const hashedPassword = await bcrypt.hash(dto.password, salt);
    // ...
  }
}

@Controller('users')
export class UsersController {
  @Post('change-password')
  async changePassword(@Body() dto: ChangePasswordDto) {
    const salt = await bcrypt.genSalt(10);
    const hashedPassword = await bcrypt.hash(dto.newPassword, salt);
    // ...
  }
}

// ✅ Добре: винесення у провайдер
@Injectable()
export class PasswordService {
  async hash(plainPassword: string): Promise<string> {
    const salt = await bcrypt.genSalt(10);
    return bcrypt.hash(plainPassword, salt);
  }
}

2. Має складну бізнес-логіку

Якщо метод контролера перевищує 10-15 рядків складної логіки (обчислення, перетворення даних, складні умови), це кандидат на винесення у провайдер.

// ❌ Погано: складна логіка безпосередньо у контролері
@Controller('orders')
export class OrdersController {
  @Post('calculate')
  calculate(@Body() dto: OrderDto) {
    let total = 0;
    
    for (const item of dto.items) {
      const basePrice = item.quantity * item.unitPrice;
      let discount = 0;
      
      if (item.quantity >= 10) {
        discount = basePrice * 0.1;
      } else if (item.quantity >= 5) {
        discount = basePrice * 0.05;
      }
      
      const tax = (basePrice - discount) * 0.2;
      total += basePrice - discount + tax;
    }
    
    return { total };
  }
}

// ✅ Добре: логіка у сервісі
@Injectable()
export class OrderCalculationService {
  calculateTotal(items: OrderItem[]): number {
    return items.reduce((total, item) => {
      const subtotal = this.calculateItemSubtotal(item);
      return total + subtotal;
    }, 0);
  }

  private calculateItemSubtotal(item: OrderItem): number {
    const basePrice = item.quantity * item.unitPrice;
    const discount = this.calculateDiscount(basePrice, item.quantity);
    const tax = this.calculateTax(basePrice - discount);
    return basePrice - discount + tax;
  }

  private calculateDiscount(basePrice: number, quantity: number): number {
    if (quantity >= 10) return basePrice * 0.1;
    if (quantity >= 5) return basePrice * 0.05;
    return 0;
  }

  private calculateTax(amount: number): number {
    return amount * 0.2;
  }
}

3. Потребує власних залежностей

Якщо для виконання логіки потрібні інші сервіси (репозиторії, зовнішні API, логери), створіть провайдер для інкапсуляції цих залежностей.

4. Незалежна від HTTP-контексту

Якщо логіка не прив'язана до специфіки HTTP (не потребує доступу до Request, Response, заголовків), вона належить до провайдера, а не контролера.

5. Потребує тестування ізольовано

Якщо ви хочете писати unit-тести для конкретної логіки без піднімання HTTP-сервера, винесіть цю логіку у провайдер.

Не створюйте провайдер, якщо логіка:

• Є простим викликом одного методу сервісу (не потрібна додаткова абстракція)
• Специфічна лише для одного методу одного контролера та ніде більше не використовується
• Є тривіальною (наприклад, просте перетворення формату відповіді)

Практичний приклад: комплексна система провайдерів

Для закріплення матеріалу розглянемо повний приклад модуля управління товарами (products) із кількома провайдерами різних типів.

У цьому прикладі чітко видно розділення відповідальностей:

• ProductsController: маршрутизація HTTP-запитів
• ProductsService: бізнес-логіка управління товарами
• ProductsRepository: доступ до даних (у реальному проєкті — робота з базою даних)
• PriceCalculator: спеціалізовані обчислення цін
• LoggerService: логування подій (спільний для всього застосунку)

Кожен провайдер має чітко визначену відповідальність та може бути легко протестований ізольовано або замінений альтернативною реалізацією.

Резюме

Провайдери є основою архітектури NestJS, що дозволяють створювати модульні, тестовні та легко масштабовані застосунки. Ключові тези, які слід запам'ятати:

У наступній лекції ми детальніше розглянемо сервіси — найбільш поширений тип провайдерів, їх роль в інкапсуляції бізнес-логіки та практичні приклади створення складних сервісів з множинними залежностями.