🐱 DataLoader и проблема N+1

Когда ты делаешь запрос на список сущностей, а для каждой из них внутри цикла идёт ещё один запрос — поздравляю, ты поймал N+1 проблему

Например:

const users = await db.query('SELECT * FROM users');
for (const user of users) {
user.posts = await db.query('SELECT * FROM posts WHERE user_id = $1', [user.id]);
}

Результат — один запрос на юзеров и N запросов на посты. На 100 юзеров это уже 101 запрос.
Больно для БД 😱😱😱

⚙️ Решения:
1) JOIN — часто помогает, если нужно просто склеить данные
2) IN-запрос — SELECT * FROM posts WHERE user_id IN (...)
3) DataLoader — если у тебя GraphQL или сложные вложенные запросы

🧠 Как работает DataLoader
DataLoader — это умный батчер и кэшер от Facebook

Он не делает магии, а просто:
1) Копит ключи (например, userId), по которым нужно загрузить данные
2) Выполняет один общий запрос, вроде:

SELECT * FROM posts WHERE user_id IN (1,2,3,...)

3) Раскладывает результат обратно по пользователям

Почитать подробнее можно тут

🚀 Пост Guru Node.js: @DemetraIT

😐 Уровни изоляции транзакций и аномалии

Когда несколько транзакций работают одновременно, они могут мешать друг другу и создавать странные эффекты — аномалии.
Чтобы держать порядок, базы данных вводят уровни изоляции — насколько сильно транзакции изолированы друг от друга.

⸻

⚠️ Типичные аномалии

— Dirty Read (грязное чтение) — читаешь данные, которые ещё не закоммичены.
Если транзакция откатится — ты прочитал “призрак”.

— Non-repeatable Read (неповторяемое чтение) — читаешь одну и ту же строку дважды, а результат разный, потому что другая транзакция изменила её между запросами.

— Phantom Read (фантомное чтение) — при повторном запросе появляются новые строки, подходящие под условие, которых раньше не было.

⸻

🔒 Уровни изоляции
1) READ UNCOMMITTED — можно читать даже незакоммиченные данные. Самый быстрый и самый опасный.

2) READ COMMITTED — читаешь только закоммиченные данные.
Нет грязных чтений, но возможны неповторяемые и фантомные.
(По умолчанию в PostgreSQL)

3) REPEATABLE READ — при повторном чтении данные не меняются.
Нет грязных и неповторяемых чтений, но фантомы возможны.

4) SERIALIZABLE — максимальная изоляция, всё выглядит как последовательное выполнение. Полностью без аномалий, но возможны откаты при конфликтах

💡 Чем выше уровень изоляции — тем меньше аномалий, но ниже производительность

🚀 Пост Guru Node.js: @DemetraIT

😳 Почему Query Builder лучше, чем ORM

ORM — звучит красиво: пишешь классы, аннотации, а база сама как-то живёт. Но на практике — это как ездить закрытыми глазами на машине на автопилоте

🐗 1. Query Builder делает ровно то, что ты просишь

Query Builder — это тонкая обёртка над SQL.
Ты чётко контролируешь какой запрос пойдёт в базу, какие JOIN’ы выполняются и какие поля читаются.
Он не “угадывает”, что ты хотел сделать — он просто выполняет твой запрос

С Query Builder:

await db('users')
.select('id', 'email')
.where('is_active', true);

SQL под капотом — предсказуемый:

SELECT id, email FROM users WHERE is_active = true;

А ORM может внезапно решить “загрузить” связи, добавить лишние поля или сделать 3 подзапроса вместо одного.
Ты думаешь, что сделал findOne, а реально — отправил 5 SQL-запросов

🍆 2. Работа с данными — это высокие риски

База данных — сердце системы.
Если ты не понимаешь, какой SQL реально выполняется, ты не контролируешь производительность и целостность данных

ORM часто скрывает логику за “удобным” API, но любая сложная операция превращается в дебри.
Query Builder же заставляет мыслить на уровне SQL, а не на уровне магии “entities” и “relations”


🙂 3. Меньше магии — меньше проблем

TypeORM, Sequelize, Prisma — все они в какой-то момент начинают диктовать свои правила.
Тебе нужно не просто “сделать запрос”, а ещё угадать, как ORM это интерпретирует
• Миграции — можно и нужно писать руками. Так надёжнее
• Сущности (Entity) в TypeORM — часто мешают, особенно когда структура БД не совпадает 1:1 с моделями кода
• При изменениях в схеме ORM может внезапно удалить или пересоздать таблицу, если ты где-то забыл флаг


😱 4. Иногда ORM тоже нормик

ORM удобно, пока проект маленький и нужно собрать быструю гипотезу на коленке


🚀 Пост Guru Node.js: @DemetraIT

🥰 useValue и useFactory в Nest.js — и при чём тут SOLID

Что это вообще такое
1) useValue — подставляет готовый объект/примитив по токену. Удобно для конфигов и моков
2) useFactory — создаёт значение через фабрику (функцию). Может быть async, можно внедрять зависимости, менять логику по окружению

Оба — это способы объявить провайдеры без привязки к конкретному классу

useValue — конфиг и моки

export const CONFIG = Symbol('CONFIG');

@Module({
providers: [
{ provide: CONFIG, useValue: { apiBase: 'https://api.dev', timeout: 3000 } },
],
exports: [CONFIG],
})
export class ConfigModule {}

Тест с моками:

useFactory — фабрика с зависимостями и режимами

export const PAYMENT_GATEWAY = Symbol('PAYMENT_GATEWAY');

@Module({
providers: [
{
provide: PAYMENT_GATEWAY,
useFactory: (cfg: ConfigService) => {
const isProd = cfg.get('NODE_ENV') === 'production';
return isProd
? new StripeGateway(cfg.get('STRIPE_KEY'))
: new FakeGateway(); // быстрая локальная разработка
},
inject: [ConfigService],
},
],
exports: [PAYMENT_GATEWAY],
})
export class PaymentModule {}

💀Причём тут SOLID, буква D (Dependency Inversion)

Принцип инверсии зависимостей: высокоуровневые модули не зависят от низкоуровневых; оба зависят от абстракций
— В Nest абстракция = инъекционный токен (строка/символ), а не интерфейс TypeScript (он стирается в runtime)
— useValue/useFactory позволяют под этот токен подложить любую реализацию без изменения кода потребителей

😱 Итог
useValue/useFactory — это практические инструменты для реализации D из SOLID в Nest.js: вы зависите от абстракций (токенов) и свободно подменяете реализации. Так код становится тестируемее, модули — слабосвязанными, а конфигурация — гибкой. Используйте useValue для констант и моков, useFactory — для динамики и асинхронной инициализации

🚀 Пост Guru Node.js: @DemetraIT