DEV Community: Zayniddin Atabaev

Node.js uchun ORM tanlaymiz!

Zayniddin Atabaev — Sat, 26 Apr 2025 11:49:17 +0000

Postda o'zim eng asosiylari deb bilgan 5 ta ORM'ni taqqoslamoqchiman: Prisma, TypeORM, Sequalize, Drizzle va Objection.js. Kyselyni ham qo'shmoqchi edim, lekin u shunchaki query builder bo'lgani uchun uni qo'shmaslikka qaror qildim, lekin u ham yaxshi tool. Quyida turli kategoriyalar bo'yicha o'z fikrlarim bilan bo'lishaman.

Querying

Prisma - ✅✅ a'lo darajada! O'zi client library generate qilib beradi va shuni metodlarini ishlatasiz. Query builder yo'q ☹️
TypeORM - ✅ yaxshi, o'zini model metodlarini ishlatasiz. Query builder bor lekin unchalik ham zo'r deb bo'lmaydi, shaxsan meni asabimni o'ynaydi
Sequelize - ✅ yaxshi, o'zini model metodlarini ishlatasiz. Query builder yo'q ☹️
Drizzle - ✅✅ a'lo darajada! Query builder ham bo'r! (batteries included dermidi😄)
Objection.js - ✅ yaxshi, chunki u Knex.js!

Type Safety

Prisma - ✅✅ a'lo darajada!
TypeORM - ✅ yaxshi va asosan o'zizga bog'liq :)
Sequelize - ❌ by default support yo'q, bir amallasa bo'ladi
Drizzle - ✅✅ a'lo darajada!
Objection.js - ⚠️ bor, lekin zo'r emas ☹️

Schema definition

Prisma - o'zini .prisma faylida yozasiz. Declarative va sodda
TypeORM - TypeScript decoratorlar bilan entitiy classlar yaratasiz, umuman olganda yaxshi
Sequelize - object qilib yozasiz, shunchaki norm
Drizzle - function'lar ko'rinishida yozasiz, menga yoqadi!
Objection.js - class qilib yozasiz, JSON schema bilan input validation qo'shsa bo'ladi, lekin juda unchalik declarative emas

Migration support

Prisma - ✅✅ a'lo darajada! prisma cli tool orqali migratsiya yaratish va yuritish mumkin, yoki dev env uchun shunchaki database bilan sync qilsa bo'ladi, migratsiya querylarni generate qilishi yaxshi
TypeORM - ⚠️ o'rtacha, cli tool bor lekin unchalik aniq migration querylar generate qilib bermaydi va asosan buggy
Sequelize - ✅ yaxshi, chidasa bo'ladi
Drizzle - ✅✅ Prisma!
Objection.js - ⚠️ Knex orqali qilishgan va migration querylarni o'zingiz yozib chiqishingiz kerak ☹️

Performance

Stupid performance testdan olgan natijalarim (Insertion time of 100k users):

Prisma: 2:12.528 (m:ss.mmm)
TypeORM: 3:24.115 (m:ss.mmm)
Sequelize: 2:05.304 (m:ss.mmm)
Drizzle: 👑 1:41.666 (m:ss.mmm)
Objection.js: 1:53.682 (m:ss.mmm)

Community & Ecosystem

Prisma - ✅✅ a'lo darajada!
TypeORM - ✅ yaxshi, lekin maintenance negadir uncha yaxshimasday oxirgi vaqtlarda ☹️
Sequelize - ✅ yaxshi, lekin asosan qariyabdi va asta sekinlik bilan undan voz kechishyabdi ☹️
Drizzle - ✅ tez o'syabdi, lekin baribir nisbatan yosh
Objection.js - ⚠️ unchalik emas to'g'risi, norm

Developer experience, a.k.a. DX (or my own experience🙂)

Prisma - ✅✅ a'lo darajada!
TypeORM - ✅ yaxshi, lekin yana aytaman, ko'p asab buzadi ☹️
Sequelize - ⚠️ unchalik zo'r emas to'g'risi, shunga o'zi undan kechishyabdi deb o'ylayman
Drizzle - ✅✅ a'lo darajada!
Objection.js - ✅ amallasa bo'ladi :)

Xulosa

Prisma yoki Drizzle ishlating. The end!

Transaction against concurrency

Zayniddin Atabaev — Fri, 14 Jun 2024 19:13:11 +0000

Keling kichik app yasab ko'ramiz. Aytaylik user registratsiya qilmoqchimiz, stack uchun Express.js + PostgreSQL:

const express = require("express");
const pg = require("pg").Pool;

const app = express();
app.use(express.json());
const dbClient = new pg({ host: "localhost", user: "root", password: "1234", database: "test" });

async function checkEmailExist(email) {
  const users = await dbClient.query(
    `SELECT id
    FROM users
    WHERE email = $1
    LIMIT 1`,
    [email]
  );
  return users.rowCount > 0;
}

async function registerUser(email) {
  return await dbClient.query(
    `INSERT INTO users (email)
     VALUES ($1)
     RETURNING id`,
    [email]
  );
}

app.post("/register", async (req, res) => {
  // get email from request body
  const { email } = req.body;

  // check if email is not taken
  const emailExist = await checkEmailExist(email);
  if (emailExist) return res.status(400).json({ error: "Email already exist" });

  // register new user
  await registerUser(email);

  return res.status(201).json({ data: "User registered successfully!" });
});

async function main() {
  try {
    await dbClient.connect();
    app.listen(3000, () => console.log("OLD server is running on port 3000"));
  } catch (error) {
    console.error(error);
  }
}

main();

Boshlanishiga hammasi yaxshi. App lauch bo'ldi va minglab foydalanuvchilar ro'yhatdan o'tdi. Keyin database'ga bir qarab ko'rsangiz ba'zi email'lar duplicate bo'lgan. WTH!

Shu joyida concurrency esga tushadi va bugni reproduce qilishga urinib ko'rasiz(pastdagi script). Ya'ni faraz qilaylik, checkEmailExist funksiyasi ishlashi uchun biror N vaqt oladi va shu vaqt oralig'idagi boshqa /register endpointga kelgan requestlar ham execute bo'ladi. Concurrency! Va qarabsizki sizda duplikatlar bor:

const axios = require("axios");

async function register() {
  return await axios.post("http://localhost:3000/register", {
    email: "johndoe@gmail.com",
  });
}

(async () => {
  for (let i = 0; i < 5; i++) {
    register()
      .then((res) => console.log(res.data))
      .catch((err) => console.error(err.response?.data));
  }
})(); // Surprise! We have 5 johndoe@gmail.com's in db

Qanday yechim qilamiz? Transactions! Bizga wrapper funksiya kerak bo'ladi:

async function $transaction(f) {
  try {
    // start db transaction
    await dbClient.query("BEGIN");
    await dbClient.query("SET TRANSACTION ISOLATION LEVEL SERIALIZABLE");

    // execute main function
    const result = await f();

    // commit db transaction
    await dbClient.query("COMMIT");

    return result;
  } catch (error) {
    await dbClient.query("ROLLBACK");
    throw error;
  }
}

checkEmailExist va registerUser funksiyalari o'zgarmaydi, rout handlerni azgina o'zgartiramiz:

app.post("/register", async (req, res) => {
  // get email from request body
  const { email } = req.body;

  try {
    await $transaction(async () => {
      // check if email is not taken
      const emailExist = await checkEmailExist(email);
      if (emailExist) {
        throw "Email already exist";
      }

      // register new user
      await registerUser(email);
    });

    return res.json({ data: "User registered successfully!" });
  } catch (error) {
    console.error(error);
    return res.json({ error });
  }
});

Va qarabsizki muammo hal!

Qanday test qilaman? checkEmailExist funksiyani sekin ishlashini simulate qilamiz, masalan quyidagini qo'shib qo'yamiz:

// simulate delay
await new Promise((resolve) => setTimeout(resolve, 1000));

Loyiha kodlari | Telegram kanal

"12 faktorli" dastur

Zayniddin Atabaev — Fri, 27 Oct 2023 14:23:16 +0000

Ushbu maqolada dasturiy ta'minotni muvofaqiyatli ishlab chiqish uchun ishlatiladigan metodologiyalardan biri bilan tanishamiz.

Diskleymer: This is the Uzbek translation of https://12factor.net. Tarjimasi chiqmagan inglizcha so'zlar oxiriga "*" belgisi qo'yilgan

"12 faktor" - bu dasturiy ta'monot ishlab chiqish metodologiyasi bo'lib, u bizga quyidagi qulayliklarni beradi:

Dasturni ishga tushirish uchun deklarativ ko'rsatmalar - bu loyihaga yangi qo'shiluvchilar uchun jarayonni tez va oson qiladi;
Dasturni operatsion tizimi bilan kam aloqadorligi - bu dasturni istalgan muhitda ishlashini ta'minlaydi
Bulutli platformalarda joylashtirish uchun mos - bu serverlar va tizim adminstratorlariga bo'lgan ehtiyojni bartaraf etadi;
dev va prod orasidagi farqni kamaytirish - bu yangi fichalarni tezkorlik bilan qo'shishga imkon beradi;
Kam harakat va harajat bilan dasturni kengaytirishga yordam beradi.

SaaS (software-as-a-service), ya'ni xizmat ko'rinishidagi dasturiy ta'minot ishlab chiqaruvchi injiner yoki shunaqa dasturlarni deploy* qiluvchi devops dasturchi ushbu metodologiyani bilishi maqsadga muvofiq.

12 faktor quyidagilardan iborat:

Kod bazasi
Dependency'lar*
Konfiguratsiya
Yordamchi xizmatlar
Build, release, run*
Protses
Port orqali bog'lash
Bir vaqtda ishga tushirish (concurrency)
Ishga tushirish/tugatish
dev va prod yaqinligi
Loglar
Admin protseslar

1. Kodbaza

"12 faktorli" dastur albatta versiya nazorati orqali ishlab chiqiladi. Bunda kodlarni repoda saqlaymiz. Repo - bu kodlarimizni vaqt davomida o'zgarishini yozib boruvchi ma'mumotlar bazasi. Misol uchun Git. Kodbaza va dastur orasidagi bog'liqliklarni quyidagicha ko'rish mumkin:

Agar kodbaza ko'p bo'lsa, unda biz dastur emas distributed system qilayapmiz. Undagi har bir element alohida dastur va ularni har birini "12 faktor" asosida ishlab chiqamiz;
Agar ko'plab dasturlar bir xil kodbazadan foydalanayotgan bo'lsa bu "12 faktorni" buzilishiga olib keladi. Bunday holatda kodlarni kutubxona ko'rinishida dependency manager* orqali ishlatish kerak bo'ladi. Misol uchun npm.

Bitta dasturda bitta kodbaza bo'ladi, lekin uni bemalol hohlagancha deploy* qilsa bo'ladi. Deploy - bu dasturni biror mashinada ishga tushirish hisoblanadi. Masalan, React.js'da qilingan vebsaytni Vercel'da deploy qilish mumkin. Bundan tashqari turli mashinalarda dasturning turli versiyalari deploy qilinishi mumkin.

2. Dependency'lar

Dependencylar - bu dasturdagi bir-biriga bog'liq komponentlar majmui. Bu komponentlarni bevosita e'lon qilib qo'yish va izolyatsiya qilish zarur. Ko'p holatlarda dependency'larni e'lon qilish uchun har til/texnologiyaning o'zini package* sistemasi bo'ladi. Misol uchun Node.js da npm. Bunda package.json faylda barcha dependency'lar ro'yhati kiritiladi. Bu bizga loyihani ishga tushirish uchun kerakli dependency'larni osonlik bilan o'rnatish imkonini beradi.

Bundan tashqari dasturimizning dependency'lari faqat dasturning o'zidan boshqarilishi zarur. Masalan, sizning komputeringizda curl o'rnatilgan va siz dasturda uni ishlatdingiz, lekin uni deklaratsiya qilmadingiz. Endi biror hamkasbingiz dasturni ishlatishda muammoga duch keldi, chunki unda curl yo'q. Yana ham muhimi, har bir dependency deklaratsiyasi o'zi bilan birga versiyasini ham bildirishi kerak. Chunki masalan npm i express bizga hozir 4.18.2 versiyani beradi va dastur shu versiya bilan ishlaydi. Lekin biror vaqtdan keyin bu buyruq boshqa versiyani olib kelishi mumkin va bu dastur notog'ri ishlashiga sabab bo'ladi.

3. Konfiguratsiya

Dastur konfigurtasiyasi (qisqa qilib konfig) turli xil deploy'larda turlicha bo'lishi mumkin, masalan staging, production, dev. Konfig o'z ichiga quyidagilarni oladi:

Ma'lumotlar bazasi, Redis yoki boshqa shunga o'xshash yordamchi xizmatlar uchun maxfiy kalitlar;
Tashqi xizmatlar uchun maxfiy kalitlar, misol uchun Amazon S3 yoki Telegram Bot tokeni;
Dasturni deploy qilish uchun turli argumentlar, misol uchun host va port.

Ba'zi dasturlarda bunaqa ma'lumotlar kodni ichida bo'ladi (hardcode), bu esa "12 faktorni" qo'pol buzish hisoblanadi! Bunday ma'lumotlar environment (dastur ishga tushuvchi muhit) da saqlanishi zarur. Yoki bo'lmasa alohida konfig faylda saqlash kerak, misol uchun .env yoku config.yml. Bu fayllar Git'ga yuborilmaydi, ya'ni har bir deploy uchun alohida yoziladi. Muhimi kodga aralashmaydi.

4. Yordamchi xizmatlar

Yordamchi xizmat - bu dastur o'z faoliyati davomida internet orqali bog'lanib, biror amaliyotni bajaruvchi yoki ma'lumot oluvchi tashqi resurs hisoblanadi. Misol qilib ma'lumotlar bazasi (MySQL, MongoDB), message/queue* tizimlar (RabbitMQ), SMTP xizmatlar (mailing* uchun) yoki kesh tizimlari (Redis, Memcached) kabilarni ko'rsatish mumkin.

Bu xizmatlarni odatda dasturni deploy qilgan devops mutaxasislani o'zlari sozlashadi. Lokal deploy qilishdan tashqari 3-tomon servislaridan ham foydalaniladi, masalan SMTP yoki xatira uchun API*lar.

"12 faktor"li dasturlar lokal va 3-tomon xizmatlarini birdek ishlata olishi kerak, ya'ni masalan databaza lokal deploy qilingan bo'lsa ham, 3-tomon servisi orqali olingan bo'lsa ham birdek ishlay olishi kerak. Bunda o'sha resursni konfiglarida dastur bog'lanishi uchun URL yoki shunga o'shash parametrlar bo'ladi.

5. Build, release, run

Kodimiz deploy qilish uchun 3 ta bosqichdan o'tadi:

Build, bunda kod ishlashi uchun barcha dependency'lar o'rnatiladi va ishga tushirsa bo'ladigan formatda keltiriladi (executable yoki script);
Release, bunda builddagi dastur olinadi va konfiglar bilan ta'minlanadi. Natijada dasturimiz ishga tushirishga tayyor bo'ladi.
Run yani ishlatish, bunda dastur kerakli muhitda ishga tushiriladi.

"12 faktorli" dasturlarda bu 3 ta bosqich albatta alohida ajratilishi kerak. Ya'ni masalan runtime da kodga o'zgartirish kiritib bo'lmasligi kerak.
Bundan tashqari har bir release uchun noyob id yoki teg qo'yish kelgusida rollback* qilish imkonini beradi. Rollback - bu biror xatolik tufayli dasturni avvalgi versiyasiga qaytarish hisoblanadi. Masalan, dasturni Docker image* qilib build qilish mumkin va unga teg beramiz. DockerHub'dagi image'larni teglari bilan ko'rgan bo'lishingiz kerak. Caprover orqali Docker image'larni deploy qilish mumkin va unda rollback funksiyasi ham bor.

6. Protses

Dastur bitta muhitda bir yoki bir nechta protses bo'lib ishlaydi. Oddiy holatda bu bitta executable* fayl yoki skript bo'ladi.

"12 faktorli" dasturda state* bo'lmaydi, ya'ni hech qanday data saqlamaydi. Agar data saqlash kerak bo'lsa yordamchi xizmatlardan foydalanadi, masalan databaza.
Vaqtinchalik saqlash uchun ma'lumotlarni faylsistemada saqlab turish mumkin. Masalan bitta .jpg faylni internetdan yuklab olib, uni ustida amal bajarib, S3'ga yuklab, foydalanuvchiga URLni yuborib, keyin faylni o'chirib yuborish. Bunda fayl kelajakda saqlanib qolishi uchun zarurat yo'q.

Ba'zida web serverda "user session" yoki Telegram Bot'dagi session*ni saqlab qo'yamiz. Bu in-memory saqlash bo'lib, "12 faktor"ni buzish hisoblanadi.

7. Port orqali bog'lash

Web dasturlar ko'p holatlarda vebserver ichida alohida "konteyner" bo'lib ishlaydi. Bu dasturni portable*, ya'ni qulay qiladi. Bunda dastur tashqi serverning biror parametriga bog'liq bo'lmasligi kerak. Aksincha uni ixtiyoriy port orqali ishlatishning iloji bo'lishi kerak. Masalan, siz Node.js'da server qildingiz va "srazi" uni 3 ta instance*da ishlatmoqchisiz. Ularni 3001, 3002 va 3003 portlarda ishga tushirasiz va serverdagi 80 portga kelgan so'rovlarni ushbu instance'larga bo'lib berasiz. Buni hozirgi kundagi odatiy implementatsiya sifatida ko'rishimiz mumkin.

Bundan tashqari yordamchi xizmatlarni ham port orqali bog'lash mumkin. Bunda URL orqali asosiy dastur yordamchi dasturga so'rov yuboradi.

8. Concurrency

"12 faktorli" dasturlarni concurrency* orqali scale-out* qilish mumkin va bu horizontal scaling. Concurrency deganda bir yoki bir nercha vazifani bir vaqtda bajarilishi tushuniladi. "Scaling" esa dasturni kengaytirish, uni katta miqdordagi bosimni ko'tara olishini ta'minlashni bildiradi.

Protseslar asosiy o'yin qatnashchilari bo'lib, uning turlariga qarab o'z dasturimizni loyihalashtiramiz. Turlari deganda thread* (potok), protses yoki worker kabilarni tushunishimiz mumkin. Misol uchun, HTTP so'rovni protses bilan handle* qilsak, ko'p vaqt oladigan vazifalarni worker bilan amalga oshiramiz.
Bundan tashqari queue* tizimini implementatsiya qilib ham dasturni responsiveness*ini oshirish mumkin. Queue - bu vazifalarni navbatga qo'shib qo'yib, FIFO tartibida bajarishdir.

9. Disposability

Dastur tez ishga tushishi va zararsiz to'xtashi kerak. Bu bizga tezroq deploy qilish va konfiglarni o'zgartirish imkonini beradi. Protses SIGTERM (signal terminate) olganda graceful shutdown qilishi kerak. Graceful shutdown - bu dastur vazifa olishni to'xtatib, bajarayotgan vazifalarni tugatib, tashqi resurslar bilan aloqani uzib talofatlarsiz to'xtashidir. Dastur qachon va qanday signal qabul qiladi? Signalni komputerdagi servis menejer beradi, misol uchun systemd yoki deylik Docker.

Worker protses uchun graceful shutdown qilish birmuncha qiyin. Bunda worker uchun topshiriq qaytadan queue'ga qaytarilishi kerak va keyin worker(lar) vazifasini to'xtatishi mumkin bo'ladi. Bu huddi databazadagi transaksiyaga o'xshaydi, agar muammo bo'lsa terminate qilish kerak. Bundan tashqari dasturning faqat master protsesi signalni qabul qiladi, bu degani boshqa slave fork*larni graceful shutdown qilish kerak bo'ladi. Ko'proq o'qish uchun "Crash-only design"ni o'qishingiz mumkin.

10. `dev` va `prod` yaqinligi

dev va prod orasidagi farq biz uchun minusga ishlaydi. Yomon alomatlar:

devdan prodga chiqish uchun dasturchi ko'p vaqt sarflaydi;
Injiner kod yozadi, devops uni deploy qiladi;
dev va proddagi ishlatilgan texnologiyalar farq qiladi.

Agar bu alomatlar sizning ish joyingizda bo'lsa, ishlar chatoq. Chunki bular unumdorlikni tushirib yuboradi va dasturni ishlab chiqish jarayonini sekinlashtitadi.

Biz daploy muhitidagi yordamchi resurslar uchun abstraktsiyalar yozamiz, lekin bu resurslar farq qilgani uchun bizga ko'zlanganidek yordam bermaydi. Shunda ham abstraktsiyalar muhim, chunki ular boshqa yordamchi xizmatga o'tganimizda ko'plab bosh og'riqlarimizni kamaytiradi.

11. Loglar

Loglar bizga dasturni harakterini ko'rsatib beradi. Loglarga qarab dastur o'tmishda va hozir qanday ishlayotganini ko'ra olamiz. Loglar vebserverlarda asosan faylga yoziladi, lekin bu shunchaki logni saqlash formati xolos.

Loglar shunchaki .logfile deb nomlanuvchi fayl emas, ular aslida ma'lumotlar oqimi (stream*). Stream dasturdan real vaqt davomida kelib turadi va biz uni monitor qila olamiz. Dastur loglarni saqlab qo'yish haqida qayg'urmasligi kerak, shunchaki ularni stream qilib stdoutga berib tursa bo'lgani. Local deployda dasturchi loglarni terminal orqali real vaqtda ko'rib turadi, prod'da esa stdoutdagi loglar tashqaridan olib turiladi va uzoq muddatga saqlab qo'yiladi. Bu yerdan esa kelajakda analiz, hodisalarni vaqt bo'yicha o'zgarishi va shunga o'xshash ma'lumotlar hosil qilinadi.

12. Admin protseslar

Ba'zida asosiy dastur ishlab turgan protsesdan boshqa, bir martalik vazifani bajarish uchun protses ochishga to'g'ri keladi. Masalan, databazaga migratsiyalarni qo'llash, REPL ishga tushirish yoki biror skript faylni yurgizish. Bunda bir martalik admin protseslar asosiy uzoq muddat ishlaydigan protsesniki bilan bir xil muhitda ishlashi kerak. Bundan tashqari, admin protses kod bilan birga bo'lishi kerak va yangilanishi, chunki sinxronlik bilan muammo chiqishi mumkin.
"12 faktor" metogologiyasi har doim REPL uchun supporti bor tillar/texnologiyalarni avzal ko'radi, chunki ularda admin protseslarni ishga tushirish oson kechadi.

Xulosa

Umuman olganda, "12 faktor" dasturiy ta'minotni ishlab chiqish, deploy qilish, monitoring va kengaytirish uchun muhim ko'rsatmalar to'plami bo'lib, muvofaqiyatli dasturlar uchun dasturulamal sifatida e'tirof qilsa bo'ladi.

Asosiy manba: https://12factor.net

DEV Community: Zayniddin Atabaev

Node.js uchun ORM tanlaymiz!

Querying

Type Safety

Schema definition

Migration support

Performance

Community & Ecosystem

Developer experience, a.k.a. DX (or my own experience🙂)

Xulosa

Transaction against concurrency

"12 faktorli" dastur

1. Kodbaza

2. Dependency'lar

3. Konfiguratsiya

4. Yordamchi xizmatlar

5. Build, release, run

6. Protses

7. Port orqali bog'lash

8. Concurrency

9. Disposability

10. dev va prod yaqinligi

11. Loglar

12. Admin protseslar

Xulosa

10. `dev` va `prod` yaqinligi