Node.js & NestJS

01Event loop-ը պարզ բառերով

Պատկերացրեք մի մատուցողի, որը մենակ սպասարկում է բազմաթիվ սեղաններ։ Նա ընդունում է պատվերը, փոխանցում խոհանոց և անմիջապես անցնում հաջորդ սեղանին՝ կանգնած սպասելու փոխարեն։ Երբ ուտեստը պատրաստ է, խոհանոցը կանչում է նրան։ Node-ն աշխատում է նույն կերպ։ Ձեր JavaScript-ն աշխատում է մեկ հիմնական թրեդի վրա։ Երբ ֆայլ եք կարդում, հարցում եք անում բազային կամ կանչում եք API, Node-ն աշխատանքը փոխանցում է օպերացիոն համակարգին կամ փոքր thread pool-ին (libuv) և շարունակում է կատարել այլ կոդ։ Երբ արդյունքը պատրաստ է, callback-ը կամ resolve եղած Promise-ը դրվում է հերթի մեջ, և event loop-ը կատարում է այն։ Սա non-blocking I/O է։ Թակարդը սա է․ եթե ձեր սեփական կոդը ծանր CPU աշխատանք է անում, օրինակ՝ նկարների չափափոխում կամ հսկայական JSON-ի parse, մատուցողը խրվում է խոհանոցում, և մնացած բոլոր հարցումները սպասում են։

• Փուլեր՝ timers, pending callbacks, poll (I/O), check (setImmediate), close callbacks։
• Microtask-ները (Promise callback-ներ, queueMicrotask) կատարվում են յուրաքանչյուր քայլի միջև՝ հաջորդ macrotask-ից առաջ։
• Կանոն՝ երբեք մի՛ արգելափակեք loop-ը․ CPU աշխատանքը տեղափոխեք worker thread-եր կամ հերթ։

02Երբ է Node-ը տեղին, և տարբերակները 2026-ի վերջին

Node-ը հիանալի ընտրություն է API-ների համար, որոնք հիմնականում սպասում են բազաներին և այլ ծառայություններին, realtime ֆունկցիաների համար՝ բազմաթիվ բաց կապերով, BFF-երի (backend-for-frontend շերտեր), webhook-ների, CLI-ների և գործիքների համար։ Այն ավելի թույլ ընտրություն է CPU-ով ծանր հաշվարկների համար, որտեղ Go-ն, Rust-ը կամ առանձին worker ծառայությունն ավելի լավ են աշխատում։ Պրոդակշնի համար օգտագործեք LTS թողարկում․ 2026-ի նոյեմբերի դրությամբ Node 24-ը maintenance LTS-ում է մինչև 2028-ի ապրիլ, Node 22-ի աջակցությունն ավարտվում է 2027-ի ապրիլին, իսկ Node 26-ը նոր է մտել LTS։ Ժամանակակից Node-ն ունի ներկառուցված fetch, test runner (node:test), watch ռեժիմ և պարզ դեպքերի համար TypeScript տիպերի native հեռացում (type stripping), այնպես որ ավելի քիչ լրացուցիչ փաթեթներ են պետք, քան մի քանի տարի առաջ։

03Express vs NestJS

Express-ը մինիմալ է՝ router և middleware, ուրիշ ոչինչ։ Դա կատարյալ է փոքր ծառայության համար, բայց մեծ կոդային բազայում յուրաքանչյուր թիմ հորինում է իր սեփական կառուցվածքը։ NestJS-ը տալիս է այդ կառուցվածքը։ Մոդուլը խմբավորում է մեկ դոմեյն (պատվերներ, մենյու, լոյալություն) իր controller-ներով և provider-ներով։ Dependency injection-ը նշանակում է, որ կլասը իր կոնստրուկտորում հայտարարում է, թե ինչ է իրեն պետք, և Nest-ը կառուցում է այն, ինչի շնորհիվ թեստերում իրական ծառայությունը fake-ով փոխարինելը դառնում է չափազանց հեշտ։ Յուրաքանչյուր հարցման շուրջ Nest-ն աշխատեցնում է ֆիքսված pipeline․ middleware, հետո guard-եր (կարո՞ղ է այս օգտատերը սա կանչել), հետո interceptor-ներ (լոգավորում, ժամանակաչափում, պատասխանի ձևափոխում), հետո pipe-եր (մուտքի վալիդացիա և ձևափոխում), հետո ձեր handler-ը, հետո exception filter-ներ, որոնք սխալները վերածում են մաքուր HTTP պատասխանների։ NestJS-ը լռելյայն աշխատում է Express-ի վրա, իսկ ավելի մեծ թողունակության համար՝ Fastify-ի վրա։

1@Controller('orders')
2@UseGuards(JwtAuthGuard, RolesGuard)
3export class OrdersController {
4  constructor(private readonly orders: OrdersService) {}
5 
6  @Post()
7  @Roles('cashier', 'manager')
8  create(@CurrentUser() user: AuthUser, @Body() dto: CreateOrderDto) {
9    return this.orders.create(user.companyId, dto);
10  }
11}
12 
13// main.ts
14app.useGlobalPipes(new ValidationPipe({ whitelist: true, transform: true }));

04Prisma-ն որպես տվյալների շերտ

Prisma-ն թույլ է տալիս աղյուսակները նկարագրել schema ֆայլում և գեներացնում է լիովին տիպավորված client․ եթե սյունը nullable է, TypeScript-ը դա գիտի։ Միգրացիաները գեներացվում են schema-ի փոփոխություններից prisma migrate dev-ով և պրոդակշնում կիրառվում են prisma migrate deploy-ով։ Օգտագործեք select կամ include՝ միայն անհրաժեշտը բերելու համար, $transaction՝ բազմաքայլ գրառումների համար, և client extension-ներ՝ ընդհանուր կանոններ ավելացնելու համար, օրինակ՝ ստիպել, որ յուրաքանչյուր հարցում պարունակի tenant id։ Prisma 7-ից սկսած կապի կարգավորումները գտնվում են prisma.config.ts-ում, իսկ client-ը ստեղծվում է driver adapter-ով (օրինակ՝ @prisma/adapter-pg), այնպես որ հին պրոեկտը տեղափոխելուց առաջ ստուգեք upgrade guide-ը։ Հիշեք, որ Prisma-ն կախարդանք չէ․ դանդաղ հարցումների համար ստուգեք գեներացված SQL-ը և schema-ում ինդեքսներ ավելացրեք։

1const orders = await prisma.order.findMany({
2  where: { companyId, status: 'PAID', createdAt: { gte: since } },
3  select: {
4    id: true,
5    total: true,
6    customer: { select: { id: true, name: true } },
7  },
8  orderBy: { createdAt: 'desc' },
9  take: 50,
10});

05Worker thread-եր, child process-ներ և Electron

Երբ Node-ում պետք է CPU աշխատանք անել, տեղափոխեք այն հիմնական թրեդից դուրս։ Worker thread-երը (node:worker_threads) JavaScript-ն աշխատեցնում են զուգահեռ թրեդերում՝ իրենց սեփական event loop-ով, և հաղորդակցվում են հաղորդագրություններով․ օգտագործեք pool գրադարան՝ յուրաքանչյուր հարցման համար նոր թրեդ ստեղծելու փոխարեն։ Երկար կամ կրկնվող (retry) աշխատանքի համար սովորաբար ավելի լավ է հերթը՝ առանձին worker process-ներով (BullMQ), որովհետև այն դիմանում է վերագործարկումներին։ Node API-ն հորիզոնական մասշտաբեք՝ աշխատեցնելով մի քանի process (pm2 cluster ռեժիմ, կոնտեյներներ) load balancer-ի հետևում։ Electron-ը Node գումարած Chromium է մեկ desktop հավելվածում․ main process-ն ունի Node հասանելիություն, renderer պատուհանները ցույց են տալիս ձեր React UI-ը, իսկ preload script-ը նրանց միջև բացում է փոքր, անվտանգ API։ Renderer-ներում contextIsolation-ը պահեք միացված, իսկ nodeIntegration-ը՝ անջատված։

06Խորհուրդներ պրոդակշնի համար

Ամբողջ մուտքային տվյալները վալիդացրեք եզրին՝ DTO-ներով (class-validator) կամ zod-ով։ Սխալները մշակեք exception filter-ներով և երբեք թույլ մի՛ տվեք, որ reject եղած Promise-ը մնա չմշակված։ Լոգավորեք կառուցվածքային JSON-ով՝ request id-ով։ Իրականացրեք graceful shutdown․ SIGTERM ստանալիս դադարեցրեք նոր տրաֆիկի ընդունումը, ավարտեք ընթացիկ հարցումները, փակեք բազայի և Redis-ի կապերը։ Ավելացրեք health check-եր load balancer-ի համար։ Յուրաքանչյուր դուրս գնացող HTTP կանչի վրա timeout դրեք։ Կախվածությունները պահեք քիչ և ստուգված, Node-ի տարբերակը ֆիքսեք .nvmrc-ում կամ engines-ում, և Docker image-ներում build արեք մաքուր JavaScript-ի՝ պրոդակշնում TypeScript-ը dev գործիքով աշխատեցնելու փոխարեն։

• app.enableShutdownHooks() NestJS-ում, որպեսզի onModuleDestroy hook-երը կատարվեն։
• Հետևեք event-loop lag-ին որպես մետրիկայի․ աճող lag-ը նշանակում է, որ ինչ-որ բան արգելափակում է loop-ը։

07Արգելափակված event loop-ի և libuv thread pool-ի չափում

Չեք կարող ուղղել այն blocking-ը, որը չեք տեսնում։ Node-ը node:perf_hooks-ում ունի monitorEventLoopDelay․ այն չափում է, թե loop-ը որքան ուշ է գործարկում իր timer-ները, և աճող p99-ը նշանակում է, որ ինչ-որ synchronous կոդ զբաղեցնում է thread-ը։ Export արեք այն որպես metric՝ request-ի latency-ի կողքին։ Մեղավորին գտնելու համար load-ի տակ CPU profile գրանցեք node --cpu-prof-ով և .cpuprofile ֆայլը բացեք Chrome DevTools-ում․ ամենալայն գծերը ձեր տաք function-ներն են, հաճախ՝ JSON.parse հսկա payload-ների վրա, synchronous crypto կամ catastrophic backtracking ունեցող regex։ Երկրորդ, ավելի լուռ bottleneck-ը libuv-ի thread pool-ն է, որը default-ով ունի ընդամենը 4 thread։ File system կանչերը, dns.lookup-ը, zlib-ը, pbkdf2-ն ու scrypt-ը և շատ native hashing մոդուլներ կիսում են այն, ուստի 50 միաժամանակյա password hash-եր հերթ են կանգնում իրար հետևից։ Գործարկման ժամանակ UV_THREADPOOL_SIZE-ը բարձրացնելն օգնում է, բայց իրական լուծումը ծանր աշխատանքը worker pool տեղափոխելն է։

1import { monitorEventLoopDelay } from 'node:perf_hooks';
2 
3const loop = monitorEventLoopDelay({ resolution: 20 });
4loop.enable();
5 
6setInterval(() => {
7  const p99ms = loop.percentile(99) / 1e6; // nanoseconds to milliseconds
8  metrics.gauge('event_loop_delay_p99_ms', p99ms);
9  if (p99ms > 200) logger.warn({ p99ms }, 'event loop is blocked');
10  loop.reset();
11}, 10_000).unref();

08Request-ի context AsyncLocalStorage-ով

PHP-ում յուրաքանչյուր request իր սեփական process-ն է, ուստի «ընթացիկ user»-ը հեշտ է։ Node-ում հազարավոր request-ներ խառնվում են մեկ thread-ի վրա, ուստի global փոփոխականը դրանք կխառներ։ node:async_hooks-ի AsyncLocalStorage-ը լուծում է սա․ դուք context եք սկսում request-ի սկզբում, և դրանից կանչված յուրաքանչյուր function, await-ների, timer-ների և Promise chain-երի միջով, կարող է կարդալ նույն store-ը։ Այն իդեալական է յուրաքանչյուր log տողում request id-ի, Prisma extension-ի համար tenant id-ի կամ դուրս գնացող կանչերի trace id-ի համար։ NestJS-ում nestjs-cls package-ը կոկիկ փաթաթում է այն։ Երկու կանոն․ store-ը փոքր և հնարավորինս immutable պահեք և այն միշտ սկսեք middleware-ում, ոչ թե guard-ում, որպեսզի ներքևում ամեն ինչ ժառանգի այն։ Request-ից դուրս սկսված աշխատանքին, օրինակ՝ queue worker-ին, պետք է յուրաքանչյուր job-ի համար իր run() կանչը։

1import { AsyncLocalStorage } from 'node:async_hooks';
2import { randomUUID } from 'node:crypto';
3 
4type Ctx = { requestId: string; companyId?: string };
5export const requestContext = new AsyncLocalStorage<Ctx>();
6 
7// main.ts (Express adapter)
8app.use((req, _res, next) => {
9  const requestId = req.headers['x-request-id']?.toString() ?? randomUUID();
10  requestContext.run({ requestId }, next);
11});
12 
13// Anywhere deeper, even after several awaits
14logger.info({ requestId: requestContext.getStore()?.requestId }, 'order created');

09NestJS-ի injection scope-երը և դրանց թաքնված արժեքը

Default-ով NestJS-ի յուրաքանչյուր provider singleton է՝ ստեղծվում է մեկ անգամ startup-ի ժամանակ և կիսվում, ինչը արագ է և սովորաբար ճիշտ։ Scope.REQUEST-ը յուրաքանչյուր request-ի համար նոր instance է ստեղծում, որպեսզի կարողանա inject անել request օբյեկտը։ Խնդիրն այն է, որ request scope-ը բարձրանում է վերև․ ցանկացած controller կամ provider, որը կախված է request-scoped provider-ից, նույնպես դառնում է request-scoped, ուստի մեկ անմեղ injection կարող է ստիպել ամբողջ dependency tree-ն վերակառուցվել յուրաքանչյուր կանչի ժամանակ՝ ավելացնելով latency և garbage collection-ի ճնշում։ Նախընտրեք singleton-ներ, որոնք context-ը ստանում են որպես method-ի argument կամ կարդում են այն AsyncLocalStorage-ից։ Եթե իսկապես պետք են tenant-ի համար առանձին instance-ներ, օրինակ՝ առանձին connection յուրաքանչյուր tenant-ի համար, NestJS-ն առաջարկում է durable provider-ներ ContextIdStrategy-ով, որը մեկ sub-tree է պահում յուրաքանչյուր tenant-ի, ոչ թե յուրաքանչյուր request-ի համար։ forRootAsync-ով և ConfigService-ով dynamic module-ները startup-ի ժամանակ կոնֆիգուրացվող singleton-ներ կառուցելու մաքուր ճանապարհն են։

10Հիշողություն, stream-ներ և database connection-ներ

Node-ի heap-ը սահմանափակ է, ուստի 500 MB export-ը array-ի մեջ բեռնելը process-ը կործանում է «JavaScript heap out of memory»-ով։ Stream-ները տվյալները մշակում են փոքր կտորներով, և stream.pipeline-ը դրանք միացնում է backpressure-ով․ եթե նպատակակետը դանդաղ է, աղբյուրը դադար է տալիս՝ ամեն ինչ buffer անելու փոխարեն։ Async generator-ները readable աղբյուրներ են, ուստի կարող եք database-ով էջ առ էջ անցնել և CSV տողերն ուղղակի գրել։ Արտահոսքերի համար process-ը սկսեք --heapsnapshot-signal=SIGUSR2-ով, մի քանի րոպե ընդմիջումով երկու snapshot վերցրեք և DevTools-ում համեմատեք, թե ինչն է աճել․ տիպիկ մեղավորներն են անսահմանափակ in-memory cache-երը, երբեք չհեռացված listener-ները և մեծ օբյեկտներ պահող closure-ները։ Connection-ները մյուս սահմանափակ ռեսուրսն են։ Յուրաքանչյուր process պետք է ստեղծի մեկ Prisma client․ Prisma 7-ի driver adapter-ների դեպքում pool-ի չափը սահմանվում է driver-ի վրա, օրինակ՝ pg Pool-ի max-ով։ Pool-ի չափը բազմապատկեք process-ների քանակով և ընդհանուրը պահեք database-ի սահմանից ցածր կամ առջևում դրեք PgBouncer։

1import { pipeline } from 'node:stream/promises';
2import { createGzip } from 'node:zlib';
3import { createWriteStream } from 'node:fs';
4 
5async function* ordersAsCsv(companyId: string) {
6  yield 'id,total,created_at\n';
7  let cursor: string | undefined;
8  do {
9    const page = await prisma.order.findMany({
10      where: { companyId }, take: 1000, orderBy: { id: 'asc' },
11      ...(cursor && { cursor: { id: cursor }, skip: 1 }),
12    });
13    for (const o of page) yield o.id + ',' + o.total + ',' + o.createdAt.toISOString() + '\n';
14    cursor = page.at(-1)?.id;
15  } while (cursor);
16}
17 
18await pipeline(ordersAsCsv(companyId), createGzip(), createWriteStream('/tmp/orders.csv.gz'));