Route Handler, Server Action yoki alohida backend: server kodi qayerga yoziladi

Qisqacha: Next.js'da server kodi uch joyda yashashi mumkin. Server Action — faqat o'z sahifangizdagi forma va tugmalar uchun (mutatsiya). Route Handler (route.ts) — barqaror manzilli ochiq eshik: RSS, webhook, boshqa dastur so'raydigan JSON. Alohida backend (Express, NestJS) — mijoz ko'p bo'lsa (sayt, mobil ilova, bot), ish uzoq davom etsa yoki doimiy ulanish kerak bo'lsa. Savol bitta: "bu kodni kim chaqiradi?"

Bu darsda

• Server Action, Route Handler va alohida backend farqini "kim chaqiradi?" savoli bilan ajrata olasiz.
• BFF (Backend for Frontend) naqshini tushuntirasiz: Next nega "frontend uchun backend", lekin to'liq backend emas.
• portfolio dagi uchta server joyi nega aynan shunday tanlanganini kanonning haqiqiy javoblari bilan ko'rasiz.
• Mobil ilova, Telegram bot va to'lov webhook'i qayerga yozilishini qaror jadvali bilan hal qila olasiz.
• Qarorni kod qilib yozasiz — kichik joyniTanla() funksiyasi.

Oldin bilishingiz kerak: Route Handlers, Server Actions I, Server Actions xavfsizligi, Cache Components II: revalidatsiya.

1. Nega bu kerak?

Oxirgi to'rt darsda portfolio ga ikki xil server kodi qo'shildi. Aloqa formasi — Server Action xabarYubor. Blog lentasi — Route Handler /blog/rss.xml. Undan oldin, keshni yangilash uchun — yana Route Handler POST /api/qayta-yangila.

Endi Aziz yangi g'oyalar o'ylab topdi:

• loyiha kartasiga «Yoqdi» tugmasi;
• Telegram bot: yangi blog posti chiqsa, kanalga xabar yuborsin;
• kelajakda vazifalar uchun mobil ilova.

Har biri uchun savol bir xil: kod qayerga yoziladi? Server Action'gami, route.ts gami yoki umuman Next'dan tashqariga?

Noto'g'ri tanlov darhol bilinmaydi. U oylar o'tib chiqadi: mobil ilova Server Action'ni chaqira olmay qoladi, yoki Next ichidagi "kichik API" asta-sekin butun backend'ga aylanib, har deploy'da hamma narsa birga to'xtaydi.

Hayotiy o'xshatish: oshxona. Zal ofitsianti (Server Action) faqat shu zaldagi mehmonlarga xizmat qiladi. Oshxonaning ko'cha tomonidagi deraza (Route Handler) — har kim kelib, aniq menyudan so'raydi: yetkazib beruvchi, qo'shni do'kon, kurer. Markaziy oshxona sexi (alohida backend) esa bir nechta filialni boqadi — u bitta zalning ichida turmaydi.

2. Uch joy: kim chaqiradi?

2.1 Server Action — ichki eshik

Server Action — "use server" bilan belgilangan funksiya. Uni sizning o'z UI'ingiz chaqiradi: <form action={xabarYubor}> yoki tugma bosilganda. Brauzer uni oddiy funksiyadek ko'radi, Next esa orqada POST so'rov yuboradi.

Bu so'rovning "manzili" — URL emas, action ID (amal identifikatori). Kanondagi forma JS'siz yuborilganda brauzer shunday yashirin maydonlarni jo'natdi (natijalar/23-forma.txt):

yashirin maydonlar (JS'siz forma uchun): $ACTION_REF_1, $ACTION_1:0, $ACTION_1:1, $ACTION_KEY

Bu nomlarni siz yozmaysiz va ular barqaror emas. Next hujjati aytadi: ID'lar shifrlangan, oldindan aytib bo'lmaydigan, va build'dan build'ga qayta hisoblanadi. Ya'ni Server Action — faqat shu ilova ichidagi "suhbat". Uni tashqaridan, masalan mobil ilovadan, ishonchli chaqirib bo'lmaydi.

Yana bir detal hujjatdan: Server Action'lar navbat bilan bajariladi. Bitta sahifadan ketma-ket uchta action chaqirilsa, ular parallel emas, birin-ketin ishlaydi. Shuning uchun action — mutatsiya (ma'lumotni o'zgartirish) uchun. Ma'lumot o'qish uchun emas: o'qishni Server Component o'zi qiladi (Serverda ma'lumot olish).

2.2 Route Handler — ko'cha tomondagi deraza

Route Handler (route.ts) — barqaror URL va istalgan HTTP metodi. Uni kim xohlasa chaqiradi: brauzer, curl, RSS o'quvchi dastur, GitHub webhook'i, mobil ilova. Javob turi ham erkin: XML, JSON, rasm, matn.

Kanondagi ikkala handler'ning haqiqiy javoblari:

status 200 | application/rss+xml; charset=utf-8 | s-maxage=2592000, stale-while-revalidate=28944000 | 1434 belgi
POST: 405

Bu — /blog/rss.xml (natijalar/24-rss.txt): GET bor, keshlanadi, POST yo'q — 405 (Method Not Allowed, "bu metod ruxsat etilmagan").

POST sirsiz: 401 {"xato":"ruxsat yo'q"}
POST noto'g'ri sir: 401 {"xato":"ruxsat yo'q"}
POST to'g'ri sir: 200 {"yangilandi":"github","vaqt":"2026-10-20T20:01:47.302Z"}
GET /api/qayta-yangila: 405

Bu — /api/qayta-yangila (natijalar/19-qayta-yangila.txt). Uni sayt UI'i emas, tashqi chaqiruvchi (cron yoki webhook) chaqiradi. Shuning uchun u Server Action bo'la olmaydi: tashqi dastur action ID'ni bilmaydi va bila olmaydi. Unga aniq manzil va sir (x-siri sarlavhasi) kerak.

2.3 Alohida backend — markaziy sex

Alohida backend — Next'dan tashqaridagi o'z server dasturi: Express, NestJS yoki boshqa. U o'z portida ishlaydi, o'z bazasiga ulanadi, o'z deploy sikliga ega. Uni bir nechta mijoz chaqiradi: Next sayti, mobil ilova, Telegram bot.

Kursda backend'ni 24-qismdan (Node.js chuqur) boshlab quramiz: Express — 25-qismda, NestJS — 30-qismda. Hozir uni ko'rish shart emas — faqat "Next'dan tashqarida ham server bo'ladi" degan fikr yetarli.

Tekshirib ko'ring: Nega /api/qayta-yangila ni Server Action qilib yozib bo'lmaydi? U ham POST, ham server kodi-ku.

3. Bitta rasmda

Uchala joyni chaqiruvchilari bilan bir joyga qo'yamiz:

flowchart LR
  F["Sayt formasi"] -->|Server Action| N["Next.js"]
  R["RSS o'quvchi"] -->|"GET /blog/rss.xml"| N
  C["Cron / webhook"] -->|"POST /api/..."| N
  M["Mobil ilova"] -->|REST| B["Alohida backend"]
  T["Telegram bot"] -->|REST| B
  N -->|"fetch (serverda)"| B

O'qish tartibi: chapda — kim chaqiradi, o'ngda — kim javob beradi. Sayt formasi va RSS — Next'ning o'z ishi. Mobil ilova va bot esa to'g'ridan backend'ga boradi. Next ham kerak bo'lsa backend'dan ma'lumot oladi — lekin serverda, brauzer buni ko'rmaydi.

4. BFF — frontend uchun backend

4.1 Atama

BFF (Backend for Frontend, "frontend uchun backend") — bitta frontend'ga moslab qurilgan yupqa server qatlami. U haqiqiy ma'lumot manbalaridan (asosiy backend, tashqi API) oladi, frontend'ga qulay shaklga keltiradi va sirlarni o'zida saqlaydi.

O'xshatish: restoran ofitsianti. Mehmon oshpaz bilan to'g'ridan gaplashmaydi, omborga ham kirmaydi. Ofitsiant buyurtmani oshxona tiliga o'giradi, tayyor taomni chiroyli qilib olib keladi. Lekin ofitsiant ovqat pishirmaydi — u oshxonaning o'rnini bosmaydi.

Next.js hujjatida alohida qo'llanma bor — "Backend for Frontend". Unda muhim ogohlantirish yozilgan (tarjima):

"Next.js'ning backend imkoniyatlari to'liq backend o'rnini bosmaydi. Ular API qatlami bo'lib xizmat qiladi: ochiq, istalgan HTTP so'rovini qabul qiladi, istalgan turdagi javob qaytaradi."

4.2 portfolio da BFF qayerda?

Siz uni allaqachon qurgansiz. "use cache" darsidagi githubProfil() — GitHub API'dan profilni serverda oladi va keshlaydi. Brauzer GitHub'ga umuman bormaydi:

GitHub API kalitsiz ishlaydi, shuning uchun kanonda token yo'q. Lekin ertaga kalit kerak bo'lsa (yoki to'lov tizimi, yoki AI xizmati), u faqat serverda yashaydi — BFF'ning asosiy foydasi shu.

4.3 Server Component Route Handler'ni chaqirmasin

Yangi boshlovchilarning keng tarqalgan xatosi: sahifa (Server Component) o'z saytining /api/... manzilidan fetch qiladi. Next hujjati bunga aniq javob beradi (tarjima):

"Server Component'larda ma'lumotni to'g'ridan manbadan oling, Route Handler orqali emas."

Ikki sabab. Birinchisi: build vaqtida server yo'q — statik sahifa o'z API'sini chaqira olmaydi va build yiqiladi. Ikkinchisi: so'rov paytida ham bu ortiqcha HTTP aylanma yo'l. Sahifa va handler bitta serverda — oddiy funksiya chaqiruvi yetarli.

// ❌ o'z API'sini HTTP orqali
const res = await fetch(`${SAYT_URL}/api/postlar`);
const postlar = await res.json();

// ✅ to'g'ridan manbadan (DAL)
const royxat = await postlar();

portfolio da sahifalar ma'lumotni @/malumot/dal dan oladi (Data Access Layer), Route Handler'lar esa faqat tashqi chaqiruvchilar uchun.

Tekshirib ko'ring: BFF va alohida backend bitta loyihada birga yashay oladimi?

5. Kanondagi to'rtta qaror

portfolio da kod qayerga yozilgani tasodif emas. Kanon har birini sababi bilan belgiladi:

To'rtinchi qator hali kodda yo'q — u kelajak qarori. vazifalar ilovasi hozir localStorage da yashaydi (22-qism). Uning haqiqiy serveri — vazifalar-api — 25-qismdan boshlab alohida quriladi. Nega Next ichida emas? Chunki uni uch mijoz chaqiradi: React ilova, kelajakdagi mobil ilova va Telegram bot. Uchalasi ham bitta qoidalar to'plamiga (kim qaysi vazifani ko'ra oladi, qanday tekshiriladi) tayanishi kerak.

Maslahat: Aloqa formasi uchun Route Handler ham yozsa bo'lardi (POST /api/aloqa + client'da fetch). Lekin u holda forma JS'siz ishlamaydi va FormData ni o'zingiz yig'asiz. Server Action ikkalasini bepul beradi — kanon Server Actions I da shu sababdan uni tanladi.

6. Alohida backend qachon kerak

6.1 Beshta belgi

Next'dagi Route Handler ko'p narsani qila oladi. Lekin quyidagi belgilardan biri paydo bo'lsa, alohida backend haqida o'ylash vaqti keldi:

Ikkinchi va uchinchi qatorning manbasi — Next hujjatining o'zi. Ba'zi xostinglar Route Handler'ni serverless funksiya (har so'rovda qisqa ishga tushadigan alohida kod bo'lagi) qilib joylaydi. Hujjat ogohlantiradi (tarjima):

• "Uzoq ishlaydigan handler'lar vaqt tugashi sababli to'xtatilishi mumkin."
• "WebSocket ishlamaydi: ulanish vaqt tugaganda yoki javob yuborilgach yopiladi."
• "Route Handler'lar so'rovlar orasida ma'lumot bo'lisha olmaydi."

portfolio ga ham bu tegishli. Kanondagi tezlik cheklovi (tezlikCheklovi, Server Actions xavfsizligi) hisobni server xotirasida saqlaydi. Bitta next start jarayonida bu ishlaydi. Serverless'da esa har funksiya o'z xotirasi bilan — hisob bo'linib ketadi. Buni deploy darsida (Vercel) yana eslaymiz.

6.2 Next + NestJS — eng ko'p uchraydigan juftlik

Real loyihalarda ko'pincha shunday:

• Next — sayt: sahifalar, SEO, formalar, BFF (kalitlar serverda).
• NestJS — API: ma'lumotlar bazasi, auth, to'lov, navbatlar; mobil ilova ham shu yerga boradi.
• Next serverda NestJS'dan fetch qiladi; brauzer NestJS manzilini bilishi shart ham emas.

Bu juftlikning narxi ham bor: ikkita dastur, ikkita deploy, ular orasidagi kontrakt (qaysi endpoint nima qaytaradi). Kichik shaxsiy sayt uchun bu ortiqcha — portfolio ga alohida backend kerak emas.

7. Qarorni kod qilib yozamiz

Qaror savollari tartib bilan beriladi. Avval eng "og'ir" belgilar (ular javobni darhol hal qiladi), keyin yengilroqlari. Kichik funksiya bilan:

function joyniTanla(v) {
  if (v.mijozlar > 1) return "alohida backend";
  if (v.uzoq || v.doimiyUlanish) return "alohida backend";
  if (v.tashqiChaqiruvchi) return "Route Handler";
  if (v.ozUIdan && v.mutatsiya) return "Server Action";
  return "Server Component";
}

const vazifalar = [
  { nom: "aloqa formasi", ozUIdan: true, mutatsiya: true },
  { nom: "RSS lenta", tashqiChaqiruvchi: true },
  { nom: "to'lov webhook'i", tashqiChaqiruvchi: true },
  { nom: "blog ro'yxati", ozUIdan: true },
  { nom: "vazifalar API", mijozlar: 3 },
  { nom: "jonli chat", doimiyUlanish: true },
];

for (const v of vazifalar) {
  console.log(`${v.nom}: ${joyniTanla(v)}`);
}

Konsolda:

aloqa formasi: Server Action
RSS lenta: Route Handler
to'lov webhook'i: Route Handler
blog ro'yxati: Server Component
vazifalar API: alohida backend
jonli chat: alohida backend

Qatorma-qator:

E'tibor bering: «blog ro'yxati» — Server Action ham, Route Handler ham emas. Ma'lumotni o'qish uchun alohida eshik kerak emas: Server Component uni render paytida o'zi oladi. Shartlar tartibi ham muhim: to'lov webhook'i ham ma'lumotni o'zgartiradi (buyurtmani "to'landi" qiladi), lekin uni sizning UI'ingiz emas, to'lov tizimi chaqiradi — shuning uchun tashqiChaqiruvchi sharti oldinroq turadi.

Tekshirib ko'ring: «Yoqdi» tugmasi (loyiha kartasida, bosilganda hisob +1) — qaysi joy? joyniTanla ga qanday obyekt berasiz?

8. Hujumchi nigohi

Uchala joy ham — internetdagi ochiq eshik. Hujumchi ularni qanday ko'radi:

• Server Action — "yashirin funksiya" emas. Server Actions xavfsizligi darsida ko'rganingizdek, uni UI'siz ham curl bilan chaqirish mumkin. Kanon tekshiruvi: noto'g'ri ma'lumot UI'siz yuborilganda ham server validatsiyasi ushladi (VALIDATSIYA XATO), begona Origin — 500. Har action ichida tekshiruv — majburiy.
• Route Handler — ochiqligi uning maqsadi. Shuning uchun /api/qayta-yangila sirni timingSafeEqual bilan solishtiradi, sir berilmagan bo'lsa marshrut 404 qaytaradi (bor-yo'qligini ham aytmaydi). To'lov webhook'larida esa imzo tekshiriladi — buni kiruvchi webhook'lar darsida chuqur o'rganamiz.
• BFF — himoya qatlami. Kalit faqat serverda; brauzer faqat sizning saytingizga gapiradi. Agar sahifa kodida NEXT_PUBLIC_ prefiksli kalit paydo bo'lsa, u brauzerga ketadi — bu Env o'zgaruvchilar darsining asosiy tuzog'i.

Umumiy qoida: joy tanlash xavfsizlikni hal qilmaydi. U faqat kim chaqira olishini belgilaydi. Tekshiruv har uchala joyda ham sizning zimmangizda.

9. Ko'p uchraydigan xatolar

10. Mashqlar

Mashqlar kurs/mashqlar/23/25-qaror/ da. Jonli yechimlarni «Ishga tushir» bilan sinang.

1-mashq (oson): kim chaqiradi?

• Sayt formasidan kelgan xabar —
• Click to'lov tizimining "to'lov o'tdi" xabari —
• Bir nechta mijoz (sayt, mobil, bot) uchun umumiy API —
• Sahifada blog postlari ro'yxatini ko'rsatish —

2-mashq (o'rta): Telegram bot va 10 000 xat

joyniTanla ga ikki vazifa qo'shing: «Telegram bot buyruqlari» (bot Telegram serveridan webhook orqali keladi, tashqiChaqiruvchi: true) va «obunachilarga 10 000 xat» (uzoq: true). Natijani chiqaring va nega bot uchun javob "Route Handler" chiqqanini bir gap bilan izohlang. Massivga element qo'shish — push yoki yangi massiv yozish.

function joyniTanla(v) {
  if (v.mijozlar > 1) return "alohida backend";
  if (v.uzoq || v.doimiyUlanish) return "alohida backend";
  if (v.tashqiChaqiruvchi) return "Route Handler";
  if (v.ozUIdan && v.mutatsiya) return "Server Action";
  return "Server Component";
}

const yangilar = [
  { nom: "Telegram bot buyruqlari", tashqiChaqiruvchi: true },
  { nom: "obunachilarga 10 000 xat", uzoq: true },
];

for (const v of yangilar) {
  console.log(`${v.nom}: ${joyniTanla(v)}`);
}

Telegram bot buyruqlari: Route Handler
obunachilarga 10 000 xat: alohida backend

3-mashq (qiyin): javob bilan sabab

joyniTanla faqat javob qaytaradi. Uni { joy, sabab } obyektini qaytaradigan joyVaSabab ga aylantiring: har shart o'z sababini yozsin (masalan "bir nechta mijoz"). Keyin chiqishni nom → joy (sabab) ko'rinishida chiqaring. Obyekt qaytarish — return va erta qaytish darsidagi return ning odatiy ishi.

function joyVaSabab(v) {
  if (v.mijozlar > 1) {
    return { joy: "alohida backend", sabab: "bir nechta mijoz" };
  }
  if (v.uzoq || v.doimiyUlanish) {
    return { joy: "alohida backend", sabab: "so'rovga sig'maydi" };
  }
  if (v.tashqiChaqiruvchi) {
    return { joy: "Route Handler", sabab: "barqaror URL kerak" };
  }
  if (v.ozUIdan && v.mutatsiya) {
    return { joy: "Server Action", sabab: "o'z formasi" };
  }
  return { joy: "Server Component", sabab: "faqat o'qish" };
}

const vazifalar = [
  { nom: "aloqa formasi", ozUIdan: true, mutatsiya: true },
  { nom: "keshni yangilash", tashqiChaqiruvchi: true },
  { nom: "vazifalar API", mijozlar: 3 },
  { nom: "loyihalar ro'yxati", ozUIdan: true },
];

for (const v of vazifalar) {
  const { joy, sabab } = joyVaSabab(v);
  console.log(`${v.nom} → ${joy} (${sabab})`);
}

aloqa formasi → Server Action (o'z formasi)
keshni yangilash → Route Handler (barqaror URL kerak)
vazifalar API → alohida backend (bir nechta mijoz)
loyihalar ro'yxati → Server Component (faqat o'qish)

4-mashq: Portfolio qadami — qaror jadvali

Kanonda bu dars uchun yangi holat yo'q: kod o'zgarmaydi, faqat qaror. O'z portfolio ingizni oching va README'ga "Server kodi qayerda" bo'limini yozing: mavjud uchta joy (xabarYubor, /blog/rss.xml, /api/qayta-yangila) va o'zingiz rejalashtirgan ikkita yangi g'oya (masalan «Yoqdi» tugmasi, yangiliklarga obuna). Har biriga: joy va bir gaplik sabab.

11. Real ishda

• Startaplarning ko'pi Next bilan boshlaydi va dastlab hamma narsani Route Handler va Server Action'da yozadi. Mobil ilova yoki ikkinchi mijoz paydo bo'lganda backend ajratiladi — bu odatiy o'sish yo'li.
• O'zbekistondagi to'lov tizimlari (Click, Payme) natijani webhook bilan yuboradi — bu har doim Route Handler yoki backend endpoint'i, hech qachon Server Action emas. Haqiqiy to'lovni 29-qismda ulaymiz.
• Intervyu savoli: "Server Action va Route Handler farqi nima, qachon qaysi biri?" Kuchli javob — "kim chaqiradi?" bilan boshlanadi va action ID, navbat, keshlanish farqlarini aytadi.
• BFF atamasi katta kompaniyalarda keng tarqalgan: har mijoz (veb, iOS, Android) uchun o'z yupqa BFF qatlami, orqada esa umumiy servislar.

Xulosa

• Asosiy savol — "kodni kim chaqiradi?": o'z UI'ingiz, tashqi dastur yoki bir nechta mijoz.
• Server Action — o'z formangiz va tugmalaringiz uchun mutatsiya; ID'si shifrlangan va build'da o'zgaradi, action'lar navbat bilan ishlaydi.
• Route Handler — barqaror URL: RSS, webhook, cron, tashqi JSON; Server Component uni chaqirmaydi.
• Next — BFF: kalitlarni serverda saqlaydi, lekin to'liq backend o'rnini bosmaydi (hujjat so'zi).
• Ko'p mijoz, uzoq ish, doimiy ulanish, fon vazifalari — alohida backend (Express, NestJS) belgilari.

Keyingi dars: proxy.ts (sobiq middleware) — so'rov sahifaga yetmasdan ishlaydigan kod: noma'lum loyiha manzili birinchi so'rovdayoq 404 qaytaradigan bo'ladi.

Manbalar

• Next.js hujjati (16.4.0 bilan keladi, node_modules/next/dist/docs/): "How to use Next.js as a backend for your frontend" (BFF, Caveats), "Data Security" (Secure action IDs), "Route Handlers" — nextjs.org/docs/app/guides/backend-for-frontend (2026-10-21 da o'qildi)
• Kanon natijalari: natijalar/23-forma.txt, natijalar/24-rss.txt, natijalar/19-qayta-yangila.txt; qaror jadvali — kanon qarori (holatsiz dars, 2026-10-21)