Nuxt, Next.js, Rust: nega stekni almashtiramiz va qachon kerak emas
To‘rt yilda asosiy frontend freymvorkimiz bir marta almashdi, o‘zimizning Damka mahsulotimizni esa uch marta qayta yozdik. Chetdan bu modaning ortidan quvishga o‘xshaydi. Ichkaridan har bir qarorning sababi bor edi va ularning hammasini ham takrorlamagan bo‘lardim.
Azamat AbduyaminovAsoschi, yetakchi muhandis
Har yarim yilda jamoadan kimdir yangi freymvork olib keladi va unda hammasi tezroq bo‘lishini aytadi. Ba’zan u haq. Ko‘pincha yo‘q. Stek bo‘yicha qarorlarni aslida qanday qabul qilganimiz va qayerda halol xato qilganimiz haqida aytib bermoqchiman.
Qisqasi: mijozlar saytlarida stek kamdan-kam va faqat jiddiy sabab bilan almashadi. Tajribani esa o‘z mahsulotlarimizda qilamiz, u yerda xato uchun o‘zimiz to‘laymiz.
2023–2024: deyarli hammasi Nuxt 3’da
Studiya katta loyihalarni ola boshlaganida biz Django + Nuxt 3 bog‘lamasini tanladik. Unda Mening Yurtim (MY5), Legal Alliance, PlanBaby, UZBCONTENT, Japanese Garden, IBN Express va telekanallar lendinglari qilingan.
Nega Vue va Nuxt? Vue’dagi shablonlar deyarli HTML kabi o‘qiladi va jamoaga yangi kelgan odamga kirishish osonroq. SSR qutidan ishlaydi, telekanallar va yuridik firmalar uchun esa qidiruv trafigi muhim. Django mijozlar bir kunda o‘zlashtiradigan tayyor admin panel berardi.
Hozir ham bu o‘sha vaqt uchun to‘g‘ri qaror bo‘lgan deb hisoblayman. MY5’ni 2023-yildan beri qo‘llab-quvvatlaymiz, u yerda 140 dan ortiq commit bor va sayt o‘sha stekda bemalol ishlayapti.
To‘g‘ri, hammasi ham silliq bo‘lmagan. Nuxt 3’ning barqaror versiyasi 2022-yil oxirida chiqdi va dastlabki oylarda biz o‘rganib qolgan modullarning bir qismi hali unga moslab qayta yozilmagan edi. Nimanidir qo‘lda qilishga, nimanidir kutishga to‘g‘ri keldi. Bu erta kirishning narxi edi va menimcha, biz uni ongli ravishda to‘ladik.
Raqamlar saytdagi loyihalar bo‘yicha hisoblangan. Botlar va mobil ilovalar bunga kirmaydi.
2025: nega Next.js’ga o‘tdik
O‘tish bir kunda bo‘lmadi. Uchta sabab bor edi va ularning hech biri “Next.js Nuxt’dan yaxshiroq” degani emas.
Odamlar. Toshkentda React-dasturchilar Vue-dasturchilardan sezilarli darajada ko‘p. Buni hh.uz’dagi yoki vakansiyalar Telegram-kanallaridagi istalgan qidiruvda ko‘rish mumkin.
Kutubxonalar. Ko‘p tillilik (next-intl), formalar, analitika uchun kutubxonalar React uchun oldinroq chiqadi. Enlawyer’da bizga uchta til, structured data, har bir lokal uchun sitemap kerak edi va React uchun bularning hammasi tayyor edi.
AI-assistentlar. G‘alati eshitiladi, lekin bu real omil. Assistentlar React va Next.js uchun kodni Nuxt’ga qaraganda ancha ishonchliroq yozadi, chunki ko‘proq misollarda o‘qitilgan. Kichik studiya uchun bu haftasiga bir necha soat degani.
Keyin Next.js’da Enlawyer, Excellent Print, Mezon Ta’lim va Xina Soliha qilindi. Oxirgi ikkitasi allaqachon Next.js 16’da.
O‘tish tekin bo‘lmadi. React’dagi App Router va server komponentlari biz Nuxt’da o‘rganib qolgan narsadan boshqacha tuzilgan va Next.js’dagi birinchi loyihalar odatdagidan sekinroq ketdi. Server va mijoz kodi orasidagi chegara qayerdaligini tushunmagunimizcha, bir narsani bir necha marta qayta qildik. Bundan tashqari, endi studiyada bir vaqtning o‘zida ikkita frontend stek bor: Vue’dagi eski saytlarni hech kim bekor qilmagan va ularni ham qo‘llab-quvvatlay olish kerak.
Damka: ikki yilda uchta versiya
Bu yerda eng ko‘p xato qildim va bu normal, chunki Damka.uz — o‘zimizning mahsulot, rus shashkasi o‘ynash platformasi.
2024-yildagi birinchi versiya Django va Nuxt’da edi: o‘yin, xonalar, hammasi oddiy so‘rovlar orqali. Ishlardi, lekin ikki kishi o‘rtasidagi jonli o‘yin uchun bu kam.
Ikkinchi versiya Django Channels va WebSocket’larga o‘tdi, frontda Nuxt 4. Alfa-beta kesish bilan negamax algoritmidagi AI-raqib, ELO reytingi, raqib tanlash, tomoshabin rejimi paydo bo‘ldi. Shu yerda Python’ga tirandik: yurishlarni qidirish sof protsessor yuklamasi va bot qancha chuqur hisoblasa, o‘yinchi shuncha uzoq kutadi.
Uchinchi versiya — pozitsiyani neyrotarmoq bilan baholaydigan Rust’dagi (actix-web, WebSocket) o‘yin dvijogi. Frontend React’da, admin panel Next.js’da, yana guruh chatining o‘zida o‘ynash va IDF qoidalari bo‘yicha turnirlar o‘tkazish mumkin bo‘lgan Telegram-bot.
Arzidimi? Dvijok uchun ha. Lekin narxini past baholadim. Har bir qayta yozish — foydalanuvchilar bitta ham yangi funksiya olmagan oylar. Agar boshidanoq dvijokni veb qismdan ajratganimda, butun mahsulotni emas, faqat uni qayta yozishga to‘g‘ri kelardi.
Shajara: Django o‘rniga Fastify
Shajara — bir nechta qarindosh bir vaqtda bitta daraxtni tahrirlaydigan oila shajarasi uchun startapimiz. Bu real-time va uni Django Channels’da ham qilgan bo‘lardik, lekin Fastify 5, Drizzle ORM va PostgreSQL’ni tanladik, frontda React 19 va Vite, sinxronizatsiya Socket.IO orqali.
Asosiy sabab: bitta til. TypeScript tiplari bazadan komponentgacha boradi va daraxt tuguni tuzilmasi o‘zgarganda production emas, build buziladi. Daraxtning o‘zi d3 orqali chiziladi, kirish Google orqali, interfeys o‘zbek, rus va ingliz tillarida. Ma’lumotlari murakkab va ichma-ich bo‘lgan mahsulot uchun bu freymvorkning har qanday tezligidan ko‘ra ko‘proq vaqt tejadi.
Mijozlar loyihalarida hozircha bunday qilmagan bo‘lardim. Admin paneli bilan Django asosiy backendimiz bo‘lib qolmoqda. Fastify — aniq vazifa uchun vosita.
Zerikarli texnologiyalar qoidasi
Quyida ichki tamoyilimiz. Uni Damka’ni ikkinchi marta qayta yozganimizdan keyin shakllantirdim.
“Mijoz loyihasi tajriba joyi emas. Yangi texnologiya avval o‘zimizning mahsulotimizdan o‘tadi va faqat u bilan yarim yil kutilmagan holatlarsiz yashasak, mijozlar uchun ishga kiradi.”
Amalda bu shuni anglatadi: Rust faqat Damka’da yashaydi. Fastify faqat Shajara’da. Korporativ sayt buyurtma qilgan mijoz o‘nlab loyihada sinalgan Django va Next.js’ni oladi.
Bir marta ham o‘zgarmagan narsalar
Yuqoridagilarga qarab, biz texnologiyalarni har yili almashtiramiz deb o‘ylash oson. Lekin to‘rt yil ichida stekning katta qismi umuman o‘zgarmadi. Baza bor barcha loyihalarda PostgreSQL. Kesh va navbatlar uchun Redis. Fon vazifalari uchun Celery: xabar tarqatish, hisobotlar, rasmlarni qayta ishlash. Deploy uchun Docker va GitLab CI. Hammasining oldida nginx.
Botlar ham o‘sha aiogram’da yashaydi. aiogram 2’dagi eski loyihalarni uchinchi versiyaga faqat kodni baribir boshqa sabab bilan ochganimizda o‘tkazamiz. Arizalarni qabul qilayotgan va hech kim shikoyat qilmayotgan ishlab turgan botni kutubxonaning yangi versiyasi uchun qayta yozishdan ma’no yo‘q.
Aynan shu o‘zgarmas qism qolganlari bilan tajriba qilish imkonini beradi. Baza, deploy va monitoring hamma joyda bir xil bo‘lsa, frontend freymvorkini almashtirish butun loyihani emas, bitta qatlamni almashtirish demakdir.
Stekni almashtirishdan oldin
Agar jamoani boshqarsangiz yoki pudratchi tanlayotgan bo‘lsangiz, mana har safar o‘zimga beradigan savollar. Ko‘pchiligiga javob “yo‘q” bo‘lsa, stekni o‘z holicha qoldiraman.
- Joriy stek hal qilmaydigan aniq muammo bor (“noqulay” emas, aynan hal qilmaydi)
- Yangi stek uchun Toshkentda oqilona pulga odam topa olamiz
- Yangi stekni avval mijoznikida emas, o‘z loyihamizda sinaymiz
- O‘tishga necha hafta ketishini va shu vaqt ichida foydalanuvchilar nima olishini hisobladik
- Eski loyihalar qayta yozilmasdan ishlashda davom etadi
- Uch yildan keyin buni qo‘llab-quvvatlaydigan odam bo‘ladi
Qisqasi, nimani boshqacha qilgan bo‘lardim: Damka dvijogini birinchi versiyadanoq vebdan ajratib, ikkinchisiga vaqt sarflamagan bo‘lardim. Nuxt’dan Next.js’ga o‘tishni esa aynan shunday, asta-sekin va eskisini qayta yozmasdan takrorlagan bo‘lardim.
