😳 Почему 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

⏱️ CRON при репликации сервиса: когда он внезапно запускается дважды

Когда у тебя один инстанс сервиса — cron-задачи живут спокойной жизнью: раз в минуту/час/день отработали — и всё
Но как только появляется горизонтальное масштабирование, начинается цирк: один и тот же cron внезапно запускается на всех репликах

Результат — задвоение задач, дубль-отправки в очередь, лишние запросы в БД, гонки, broken idempotency.
Разбираемся, как это контролировать

🙃 Способы синхронизации CRON между репликами

1) Distributed lock (рекомендуется)

Ты заранее пытаешься взять “маркер лидерства”
Кто взял — тот и выполняет cron. Остальные ждут

Варианты реализации:
— Redis + Redlock
Стандарт: быстрая блокировка с TTL → если под умер, блокировка сама освободится

— PostgreSQL advisory locks
SELECT pg_try_advisory_lock(12345)
Если вернул true, ты — лидер

— PostgreSQL row-level / table-level locks
Простой механизм: лочишь строку “task_name = cleanup_daily”


2) Leader election (лидер выбирается автоматически)

Идея: из всех реплик выбирается одна основная, она и запускает cron.

Варианты:
— Kubernetes leader election через Lease API
Удобно для Cron внутри подов

— Consul / Etcd лидер-электоры
Более enterprise-решение.

3) Cron вынести наружу (лучший вариант для сложных систем)

Перенести все периодические задачи в:
— Kubernetes CronJob
Самый распространённый вариант.
— Airflow / Temporal / BullMQ Scheduler
Если задач много и они взаимосвязаны.
— Dedicated scheduler service

Минус: иногда оверхед для небольших проектов

4) Idempotency + мягкая синхронизация

Если не можешь/не хочешь бороться с параллельностью —
просто проектируешь cron так, чтобы дубликат не ломал логику

Подходы:
— В БД держать processed_at, а cron проверяет “ещё не обработано?”.
— Все действия писать через UPSERT / ON CONFLICT DO NOTHING.
— Слать команды в очередь, где есть idempotency-key.


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

😎 Транзакции в микросервисах: Saga vs 2PC

Когда система разбита на десятки сервисов — классические транзакции через BEGIN/COMMIT уже физически не сработают. Нужны механизмы, которые обеспечат целостность данных между разными сервисами, каждый из которых живёт в своей базе и своём технологическом стеке.

Используют два подхода: Saga и 2PC. Разберём, как они устроены, где применять и какие подводные камни есть у каждого

🌀 Saga Pattern

Saga — это цепочка локальных транзакций, каждая из которых коммитится сразу. Если одна из операций падает — запускаются компенсирующие действия, откатывающие уже выполненные шаги.

Как работает
1. Сервис A создаёт заказ
2. Сервис B списывает деньги
3. Сервис C резервирует товар
4. Сервис D создаёт доставку

Если на шаге 3 ошибка — запускаются компенсации:

— отменить доставку
— снять резерв товара
— вернуть деньги
— отменить заказ

Все шаги асинхронные, с ретраями и идемпотентностью.

Два подхода Saga
1) Orchestration
Есть “дирижёр” (Orchestrator), который знает порядок шагов
Чаще всего — отдельный сервис или компонент (советую почитать про Temporal)

2) Choreography
Сервисы сами реагируют на события друг друга

🔗 Two-Phase Commit (2PC)

2PC — классический дистрибутивный commit: все участники говорят “готов”, после чего координатор говорит “фиксируем”

Как работает
1) Phase 1: Prepare
Координатор опрашивает сервисы:
“Готовы закоммитить транзакцию?”

2) Phase 2: Commit
Если все ответили OK → отправляется COMMIT
Если хотя бы один ответил NO → ROLLBACK

Проблемы 2PC

— блокировки: участники держат транзакции в состоянии prepare
— долгая блокировка ресурсов → падение производительности
— сеть надежна и транзакции будут падать

По факту, 2PC в микросервисах почти не используют — слишком дорог и хрупок

🐗 Вывод юзаем сагу

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

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