16.3-bob: Capstone #3 — Real-time ilova (chat/notifications)

16-QISM — Katta Yakuniy Loyihalar · 3-mavzu

1. Kirish va motivatsiya

Hozirgacha qurgan ilovalarimiz asosan so'rov-javob modelida edi: foydalanuvchi so'rov yuboradi (sahifani ochadi, tugma bosadi), server javob beradi. Lekin zamonaviy ilovalarning ko'pi real-time (jonli): chat (xabar darrov ko'rinadi — yangilamasdan), bildirishnoma (yangi hodisa — darrov push), jonli yangilanishlar (Google Docs — boshqalar yozganini ko'rish, jonli narx, sport hisobi). Bularda server foydalanuvchiga o'zi ma'lumot yuboradi (so'rov kutmasdan — "push") — bu so'rov-javob (foydalanuvchi so'raganda) modelidan tubdan farq qiladi. Bu capstone — real-time ilovani (chat + bildirishnoma) qurishni o'rgatadi.

Real-time ning kaliti — WebSocket (doimiy, ikki tomonlama ulanish — server va client doimo bog'langan — har biri istalgan paytda ma'lumot yuboradi). Bu 5.13-bobda (Socket.io) ko'rgan texnologiyaning amaliyoti. Real-time ilova qurish — interaktiv, jonli tajriba beradi (foydalanuvchi yoqtiradi — darrov, jonli), lekin o'z muammolari bilan keladi (ulanish boshqaruvi — kim onlayn, miqyos — millionlab ulanish, ishonchlilik — uzilgan xabar). Bu capstone real-time'ning asoslari va muammolarini ko'rsatadi.

Bu bob quyidagilarni qamrab oladi: real-time nima (so'rov-javob vs real-time), WebSocket (qanday ishlaydi — 5.13), loyiha g'oyasi (chat ilova — Slack/Discord/messenger kabi), arxitektura (WebSocket server, xonalar, ma'lumot modeli), bildirishnoma (in-app + push + email), bosqichma-bosqich qo'llanma, va real-time muammolari (ulanish, miqyos, offline, xavfsizlik). "Real-time ilova (chat + bildirishnoma)" capstone'ini to'liq ochib beramiz — loyiha g'oyasi, texnologiya tanlovi, funksiyalar ro'yxati, arxitektura, bosqichlar va "tayyor" mezonlari. Yechim kodi ataylab berilmagan — kodni siz o'zingiz yozasiz (talab + hint bor, tayyor yechim yo'q).

O'xshatish: So'rov-javob vs real-time — bu xat yozish vs telefon qo'ng'irog'i. So'rov-javob (HTTP) — bu xat (siz xat yozasiz — so'rov, javob kutasiz — javob xat; har gal yangi xat — yangi so'rov): rasmiy, ishonchli, lekin kechikishli (xat borib-keladi — yangilanishni bilish uchun qayta so'raysiz). Real-time (WebSocket) — bu telefon qo'ng'irog'i (liniya doimo ochiq — ikki tomon istalgan paytda gapiradi — bir-birini darrov eshitadi): jonli, darrov (boshqa odam gapirsa — darrov eshitasiz — so'ramasdan). Chat — telefon kabi (xabar darrov — yangilamasdan); bildirishnoma — kimdir sizga qo'ng'iroq qilgandek (yangi hodisa — darrov). Real-time — "telefon liniyasi" (doimo ochiq — server darrov ma'lumot yuboradi), so'rov-javob — "xat" (har gal yangi so'rov). Zamonaviy ilova — ko'pincha ikkalasi (asosiy — HTTP, jonli qismlar — WebSocket).

Nega muhim?

• Zamonaviy ilova — real-time keng (chat, bildirishnoma, jonli yangilanishlar — foydalanuvchi kutadi).
• WebSocket — 5.13 (Socket.io) amaliyoti — jonli, interaktiv tajriba.
• Interaktivlik — real-time — eng jonli UX (darrov — yangilamasdan).
• Yangi muammolar — ulanish boshqaruvi, miqyos (so'rov-javobdan farqli).

2. Real-time nima va WebSocket

2.1. So'rov-javob vs real-time

  SO'ROV-JAVOB vs REAL-TIME (aloqa modeli):

  SO'ROV-JAVOB (HTTP — an'anaviy):
  Client ──so'rov──► Server
  Client ◄──javob── Server
   faqat CLIENT boshlaydi (so'rov); server o'zi yubora olmaydi
   yangilanishni bilish: qayta so'rash (polling — sekin, isrof)

  REAL-TIME (WebSocket — jonli):
  Client ◄════════► Server  (doimiy, ikki tomonlama ulanish)
   IKKALASI istalgan paytda yuboradi (server PUSH qiladi)
   yangi hodisa  server darrov client'ga (so'rovsiz)

  ESKI REAL-TIME USULLARI (WebSocket'dan oldin):
   Polling (har N sekund so'rash — sekin, isrof)
   Long polling (so'rovni ochiq tut — yaxshiroq, lekin cheklangan)
   SSE (Server-Sent Events — faqat serverclient, bir tomonlama)
   WebSocket — eng yaxshi (ikki tomonlama, doimiy)

   So'rov-javob (HTTP) — client boshlaydi; real-time (WebSocket) — server ham push qiladi
   WebSocket — doimiy, ikki tomonlama (chat, bildirishnoma — jonli)

So'rov-javob vs real-time — ikki aloqa modeli. So'rov-javob (HTTP — an'anaviy — 0.4): Client so'rov yuboradi Server javob beradi — faqat client boshlaydi (so'rov), server o'zi yubora olmaydi (client so'ramasa — jim); yangilanishni bilish uchun client qayta so'raydi (polling — sekin, isrof — har 5 soniyada "yangilik bormi?"). Real-time (WebSocket — jonli): Client Server doimiy, ikki tomonlama ulanish (bir marta o'rnatiladi, ochiq qoladi) — ikkalasi istalgan paytda ma'lumot yuboradi (server push qiladi — client so'ramasa ham); yangi hodisa server darrov client'ga (so'rovsiz — chat xabari, bildirishnoma). Eski real-time usullari (WebSocket'dan oldin — endi WebSocket afzal): polling (har N soniya so'rash — sekin, isrof — ko'p bo'sh so'rov), long polling (so'rovni ochiq tut, javob bo'lguncha — yaxshiroq, lekin cheklangan), SSE (Server-Sent Events — faqat serverclient — bir tomonlama — bildirishnoma uchun OK, chat uchun emas), WebSocket (eng yaxshi — ikki tomonlama, doimiy — chat, jonli). Ikki nuqta: (1) so'rov-javob (HTTP) — client boshlaydi (so'rov-javob — server o'zi yubora olmaydi); real-time (WebSocket) — server ham push qiladi (ikki tomonlama); (2) WebSocket — doimiy, ikki tomonlama (chat, bildirishnoma — jonli — darrov). Asosiy farq — kim ma'lumot yuborishni boshlaydi: HTTP — faqat client (so'rov); WebSocket — ikkalasi (server push — yangi hodisani darrov). Bu real-time'ning kaliti (server foydalanuvchiga o'zi ma'lumot yuboradi — chat xabari, bildirishnoma — so'ramasdan). HTTP — ko'p narsaga yetadi (sahifa, CRUD — foydalanuvchi so'raydi); WebSocket — real-time kerak bo'lganda (chat, jonli — server push). Zamonaviy ilova — ikkalasi (asosiy HTTP — 13-QISM; jonli qismlar WebSocket — bu bob). WebSocket — eng yaxshi real-time (ikki tomonlama, doimiy — 5.13 Socket.io).

2.2. WebSocket va Socket.io (5.13)

  WEBSOCKET — doimiy, ikki tomonlama ulanish (real-time poydevori):

  WEBSOCKET ISHLASHI:
  1. Handshake (HTTP  WebSocket "upgrade" — ulanish o'rnatiladi)
  2. Ochiq ulanish (doimiy — ikkala tomon yuboradi)
  3. Xabarlar (ikki tomonlama — istalgan paytda)
  4. Yopilish (ulanish uzilganda)

  SOCKET.IO (5.13 — WebSocket ustida — qulay):
   WebSocket + qo'shimcha (auto-reconnect, xonalar, fallback)
   server: io.on("connection", socket => { socket.on("message", ...) })
   client: socket.emit("message", data); socket.on("message", cb)

  ASOSIY TUSHUNCHALAR:
   emit (yuborish) / on (tinglash)
   ROOM (xona — guruh — bir xonaga yuborish — chat guruhi)
   namespace (mantiqiy ajratish — /chat, /notifications)
   broadcast (boshqalarga — o'zidan tashqari)

   WebSocket — doimiy ulanish (handshake  ochiq  xabarlar); Socket.io — qulay ustki qatlam
   Socket.io — emit/on, room (guruh), namespace, broadcast (5.13)

WebSocket va Socket.io (5.13) — real-time poydevori. WebSocket — doimiy, ikki tomonlama ulanish (real-time'ning asosi). WebSocket ishlashi: (1) handshake (HTTP so'rov WebSocket "upgrade" — ulanish HTTP'dan WebSocket'ga "ko'tariladi" — bir marta); (2) ochiq ulanish (doimiy — ikki tomon ma'lumot yuboradi — yopilmaguncha); (3) xabarlar (ikki tomonlama — istalgan paytda — server yoki client); (4) yopilish (ulanish uzilganda — foydalanuvchi sahifani yopdi yoki tarmoq uzildi). Socket.io (5.13 — WebSocket ustida — qulay kutubxona): WebSocket + qo'shimcha imkoniyatlar (auto-reconnect — uzilsa qayta ulanadi, xonalar — guruh, fallback — WebSocket ishlamasa polling'ga). Server: io.on("connection", socket => { socket.on("message", ...) }); client: socket.emit("message", data) (yuborish), socket.on("message", cb) (tinglash). Asosiy tushunchalar: emit (yuborish) / on (tinglash) — ikki asosiy amal; room (xona — guruh — bir xonaga yuborish — chat guruhi/kanal — faqat o'sha xonadagilar oladi); namespace (mantiqiy ajratish — /chat, /notifications — turli real-time funksiya); broadcast (boshqalarga — o'zidan tashqari — masalan "Ali yozyapti" — Ali'dan boshqaga). Ikki nuqta: (1) WebSocket — doimiy ulanish (handshake ochiq xabarlar yopilish); Socket.io — qulay ustki qatlam (auto-reconnect, xonalar, fallback — 5.13); (2) Socket.io — emit/on (yuborish/tinglash), room (guruh), namespace (ajratish), broadcast (boshqalarga). Socket.io 5.13-bob — real-time'ning amaliy vositasi (WebSocket murakkabligini yashiradi — auto-reconnect, xonalar — qulay). emit/on — asosiy naqsh (event yuborish/tinglash — event-driven — har xabar bir event). Room (xona) — chat uchun kalit (har chat guruhi — bir xona — xabar faqat o'sha xonadagilarga — izolyatsiya). Namespace — turli real-time funksiya (chat, bildirishnoma — alohida). Broadcast — "yozyapti" indikatori, jonli yangilanishlar (o'zidan tashqari hammaga). Bu — real-time'ning texnik asosi (5.13 Socket.io — bu capstone'ning poydevori). WebSocket (doimiy ulanish) + Socket.io (qulay) — chat, bildirishnoma, jonli ilova.

3. Loyiha g'oyasi va arxitektura

  CHAT ILOVA (Slack/Discord kabi) — talablar va arxitektura:

  TALABLAR:
   1:1 va guruh chat (xona)
   real-time xabar (darrov — WebSocket)
   online holati (kim onlayn — "presence")
   "yozyapti" indikatori (typing)
   o'qildi belgisi; xabar tarixi (saqlash)
   bildirishnoma (yangi xabar — push)

  ARXITEKTURA:
  ┌─────────────────────────────────────────────────────┐
  │ Client (React) — chat UI + Socket.io client          │
  ├─────────────────────────────────────────────────────┤
  │ WebSocket Server (Socket.io — 5.13)                  │
  │    ulanish, xonalar, emit/on, presence              │
  ├─────────────────────────────────────────────────────┤
  │ HTTP API (xabar tarixi, auth — 13.6)                 │
  ├─────────────────────────────────────────────────────┤
  │ DB (xabar saqlash — PostgreSQL/MongoDB — 6)          │
  │ Redis (presence, pub/sub — ko'p server — 5.21)       │
  └─────────────────────────────────────────────────────┘

  XABAR OQIMI:
  Ali xabar yozadi  Socket.io emit  server  xonaga broadcast 
    boshqa a'zolar darrov oladi + DB'ga saqlanadi

   Chat — real-time (Socket.io) + HTTP (tarix/auth) + DB (saqlash) + Redis (presence/miqyos)
   Xona (room) — chat guruhi; xabar  xonaga broadcast (darrov) + DB (saqlash)

Loyiha g'oyasi va arxitektura — chat ilova (Slack/Discord kabi). Talablar: 1:1 va guruh chat (xona — room), real-time xabar (darrov — WebSocket), online holati (presence — kim onlayn — yashil nuqta), "yozyapti" indikatori (typing — broadcast), o'qildi belgisi, xabar tarixi (saqlash — DB), bildirishnoma (yangi xabar — push). Arxitektura: (1) Client (React — 11-QISM — chat UI + Socket.io client — 2.2); (2) WebSocket Server (Socket.io — 5.13 — ulanish, xonalar, emit/on, presence); (3) HTTP API (xabar tarixi, auth — 13.6 — chat tarixi HTTP orqali, real-time emas — o'tgan xabarlar; auth — kim); (4) DB (xabar saqlash — PostgreSQL/MongoDB — 6-QISM — tarix); (5) Redis (presence — kim onlayn, pub/sub — ko'p server uchun — 5.21). Xabar oqimi: Ali xabar yozadi Socket.io emit server xonaga broadcast (boshqa a'zolar darrov oladi — WebSocket push) + DB'ga saqlanadi (tarix). Ikki nuqta: (1) chat — real-time (Socket.io — jonli xabar) + HTTP (tarix/auth — o'tgan xabarlar, login) + DB (saqlash) + Redis (presence/miqyos); (2) xona (room) — chat guruhi; xabar xonaga broadcast (darrov — faqat o'sha guruh) + DB (saqlash — tarix). Bu — chat'ning arxitekturasi (real-time + HTTP + DB + Redis — har biri vazifa). Real-time (Socket.io) — jonli qism (xabar darrov, presence, typing); HTTP 13.6-bob — an'anaviy qism (tarix yuklash, auth — 2.1 — HTTP yetadi); DB — xabar saqlash (tarix — keyin ko'rish); Redis — presence (kim onlayn — tez) va pub/sub (ko'p server — 3.6 ko'prik — bir serverdagi xabar boshqa serverdagi foydalanuvchiga). Xona (room) — chat'ning asosi (har guruh — xona — xabar faqat o'sha xonaga broadcast — izolyatsiya — to'g'ri odamlarga). Xabar oqimi (emit server broadcast + DB) — chat'ning yuragi (jonli yuborish + saqlash). Bu g'oya — chat (Slack/Discord), lekin bildirishnoma, jonli dashboard, collaborative editing ham (bir xil real-time asos — WebSocket, room, broadcast). Sizning g'oyangiz boshqa bo'lishi mumkin (jonli auksion, collaborative whiteboard, jonli support chat — bir xil real-time asos).

3.1. Texnologiya tanlovi (WebSocket vs SSE vs long-polling; Socket.io vs native ws)

  REAL-TIME TRANSPORT TANLOVI — nima uchun WebSocket:

  LONG-POLLING:  client so'rov ochadi, server javob bo'lguncha ushlab turadi
    + oddiy, hamma joyda ishlaydi   − sekin, ko'p qayta ulanish, bir tomonlama his
  SSE (Server-Sent Events): server  client (bir tomonlama) oqim
    + oddiy, auto-reconnect bor      − faqat serverclient (chat uchun yetmaydi)
     BILDIRISHNOMA uchun mos (faqat server push kerak bo'lsa)
  WEBSOCKET: to'liq ikki tomonlama, doimiy
    + eng jonli, ikki tomonlama      − proksi/miqyos e'tibor talab qiladi
     CHAT uchun to'g'ri tanlov (typing, o'qildi — ikki tomonlama)

  KUTUBXONA — Socket.io vs native "ws":
   native ws — yengil, standart WebSocket, lekin xonalar/reconnect/fallback O'ZINGIZ
   Socket.io — auto-reconnect + xonalar + Redis adapter + fallback TAYYOR
   NestJS Gateway (@WebSocketGateway) — Socket.io yoki ws adapter tanlanadi

   Chat — WebSocket (ikki tomonlama); bildirishnoma — SSE ham yetadi
   Socket.io — tayyor xonalar/reconnect/miqyos; native ws — nazorat, lekin qo'lda

Texnologiya tanlovi — real-time transport va kutubxonani ongli tanlash. Transport: (1) long-polling — client so'rovni ochiq tutadi, server javob bo'lguncha ushlab turadi (oddiy, hamma joyda ishlaydi, lekin sekin — har javobdan keyin qayta ulanish); (2) SSE (Server-Sent Events) — serverclient bir tomonlama oqim (oddiy, auto-reconnect bor, lekin faqat server push — chat uchun yetmaydi, chunki client ham darrov yuborishi kerak) — bildirishnoma uchun mos (faqat server push); (3) WebSocket — to'liq ikki tomonlama, doimiy — chat uchun to'g'ri tanlov (typing, o'qildi belgisi — ikki tomonlama). Kutubxona: native ws — yengil, standart WebSocket, lekin xonalar, reconnect, fallback — hammasi o'zingizda; Socket.io 5.13-bob — auto-reconnect, xonalar, Redis adapter, fallback tayyor. NestJS'da WebSocket Gateway (@WebSocketGateway) — bu ikkisidan birini adapter sifatida ishlatadi. Loyihada tanlovni asoslang: chat + typing + o'qildi kerak bo'lsa — WebSocket (Socket.io); faqat bildirishnoma kerak bo'lsa — SSE ham yetarli (soddaroq). Ikki nuqta: (1) chat — WebSocket (ikki tomonlama), bildirishnoma — SSE ham yetadi (bir tomonlama); (2) Socket.io — tayyor xonalar/reconnect/miqyos, native ws — nazorat, lekin qo'lda mehnat. Bu tanlov — capstone hujjatingizda yozib qo'yiladigan qaror (nima uchun WebSocket, nima uchun Socket.io — trade-off bilan).

3.2. Ma'lumot modeli (message / conversation / participant)

  CHAT MA'LUMOT MODELI (sxema — o'zingiz to'ldirasiz):

  User(id, name, avatar, lastSeenAt, ...)
  Conversation(id, type: "dm"|"group", title?, createdAt)
  Participant(conversationId, userId, role, joinedAt, lastReadMessageId)
  Message(id, conversationId, senderId, body, type: "text"|"image"|"file",
          createdAt, editedAt?, deletedAt?)
  Attachment(id, messageId, url, mime, size)       // media/fayl (8-fayl yuklash)

  MUHIM INDEKSLAR / SO'ROVLAR:
   xabar tarixi: WHERE conversationId=? ORDER BY createdAt DESC LIMIT 30 (pagination)
   o'qilmagan hisob: Message.createdAt > Participant.lastReadMessage vaqti
   o'qildi belgisi: Participant.lastReadMessageId ni yangilash

   Conversation (dm|group) + Participant (kim a'zo, qayergacha o'qigan) + Message
   O'qildi/o'qilmagan — Participant.lastReadMessageId orqali hisoblanadi

Ma'lumot modeli — chat'ning DB sxemasi (6-QISM). Asosiy jadvallar: User (id, ism, avatar, lastSeenAt — presence uchun); Conversation (id, type: dm 1:1 yoki group, title — guruh nomi, yaratilgan vaqt); Participant (conversationId + userId — kim a'zo, role — admin/oddiy, lastReadMessageId — qayergacha o'qigan — o'qildi/o'qilmagan hisobi uchun); Message (id, conversationId, senderId, body, type — matn/rasm/fayl, createdAt, editedAt, deletedAt — soft delete); Attachment (media/fayl — rasm, hujjat — fayl yuklash bilan bog'liq). Muhim so'rovlar: xabar tarixi — WHERE conversationId=? ORDER BY createdAt DESC LIMIT 30 (pagination — 3.3); o'qilmagan hisob — foydalanuvchining lastReadMessageId'sidan keyingi xabarlar soni; o'qildi belgisi — Participant.lastReadMessageId'ni yangilash (real-time broadcast bilan). Ikki nuqta: (1) Conversation (dm yoki group) + Participant (kim a'zo, qayergacha o'qigan) + Message — uch asosiy jadval; (2) o'qildi/o'qilmagan — lastReadMessageId orqali hisoblanadi (alohida jadval kerak emas — bitta ustun yetadi). Bu model — dm va guruhni bir sxemada ushlaydi (dm — ikki a'zoli guruh). Sxemani o'zingiz to'ldirasiz (bu — boshlang'ich skelet, tayyor migratsiya emas).

3.3. Chat funksiyalari batafsil (1:1/guruh, typing, o'qildi, pagination, media)

  CHAT FUNKSIYALARI — talab va real-time hodisasi (event):

  1:1 va GURUH         conversation.type; xona nomi = conversationId
  XABAR yuborish/olish  emit "message:new"  xonaga broadcast + DB
  TYPING indikatori     emit "typing:start"/"typing:stop"  xonaga (DB'siz)
  PRESENCE (online)     connect/disconnect  Redis set + broadcast
  O'QILDI holati        emit "message:read"  lastReadMessageId + broadcast
  XABAR TARIXI          HTTP GET /conversations/:id/messages?cursor=... (pagination)
  MEDIA/FAYL            HTTP upload  URL  "message:new" (type=image/file)

   Faqat XABAR va O'QILDI — DB'ga; TYPING — vaqtinchalik (DB'siz)
   Tarix — HTTP + cursor pagination; yangi xabarlar — WebSocket

Chat funksiyalari batafsil — har funksiya uchun talab va unga mos real-time hodisa. 1:1 va guruh — conversation.type (dm/group) farqlaydi, xona nomi sifatida conversationId ishlatiladi (har suhbat — bir xona). Xabar yuborish/olish — message:new hodisasi xonaga broadcast (a'zolar darrov oladi) + DB'ga saqlash. Typing indikatori — typing:start/typing:stop xonaga broadcast, lekin DB'ga saqlanmaydi (vaqtinchalik holat — bir necha soniya). Presence — connect/disconnect'da Redis'ga yozish + broadcast (kim onlayn). O'qildi holati — message:read lastReadMessageId'ni yangilash + broadcast (jo'natuvchi "o'qildi"ni ko'radi). Xabar tarixi — HTTP GET /conversations/:id/messages?cursor=... bilan cursor pagination (oxirgi 30 ta, yuqoriga scroll — keyingi 30 ta — 11.11 uzun ro'yxat). Media/fayl — avval HTTP upload (fayl yuklash), keyin URL bilan message:new (type=image/file). Ikki nuqta: (1) faqat xabar va o'qildi — DB'ga; typing — vaqtinchalik (DB'siz); (2) tarix — HTTP + cursor pagination, yangi xabarlar — WebSocket (real-time). Bu — chat funksiyalarining to'liq ro'yxati (har biri — alohida hodisa yoki HTTP endpoint — capstone talab ro'yxati).

4. Bildirishnoma (notifications)

  BILDIRISHNOMA — yangi hodisa  foydalanuvchiga darrov (push):

  BILDIRISHNOMA TURLARI:
   IN-APP (ilova ichida — real-time — Socket.io — qo'ng'iroq ikonkasi)
   PUSH (brauzer/mobil — ilova yopiq bo'lsa ham — Web Push API)
   EMAIL (muhim — 5.19 — asinxron)

  IN-APP BILDIRISHNOMA OQIMI (real-time):
  Hodisa (yangi xabar/tayinlash)  server 
    foydalanuvchi onlaynmi?
      HA  Socket.io emit (darrov — real-time)
      YO'Q  DB'ga saqla (keyin ko'radi) + push/email

  PUSH (Web Push — ilova yopiq):
   Service Worker + Push API (brauzer push — ilova ochiq bo'lmasa ham)
   ruxsat so'rash (foydalanuvchi tasdiqlaydi)

  BILDIRISHNOMA DIZAYNI:
   o'qilgan/o'qilmagan holat; guruhlash; sozlamalar (qaysi bildirishnoma)
   DON'T SPAM (ko'p bildirishnoma — foydalanuvchi o'chiradi)

   Bildirishnoma — in-app (real-time) + push (ilova yopiq) + email (muhim)
   Onlayn  Socket.io (darrov); offline  DB + push/email (keyin/tashqari)

Bildirishnoma (notifications) — yangi hodisani foydalanuvchiga darrov yetkazish (push). Bildirishnoma turlari: (1) in-app (ilova ichida — real-time — Socket.io — qo'ng'iroq ikonkasi — foydalanuvchi ilovada bo'lganda darrov ko'radi); (2) push (brauzer/mobil — ilova yopiq bo'lsa ham — Web Push API — masalan WhatsApp telefon push); (3) email (muhim — 5.19 — asinxron — masalan haftalik xulosa). In-app bildirishnoma oqimi (real-time): hodisa (yangi xabar/tayinlash) server foydalanuvchi onlaynmi tekshir: agar ha Socket.io emit (darrov — real-time — ekranda ko'rinadi); agar yo'q DB'ga saqla (keyin kirganda ko'radi) + push/email (tashqaridan xabar). Push (Web Push — ilova yopiq): Service Worker + Push API (brauzer push — ilova ochiq bo'lmasa ham — masalan "yangi xabar" telefonda — ilova yopiq) — foydalanuvchidan ruxsat so'rash (tasdiqlaydi — push'ga rozi). Bildirishnoma dizayni: o'qilgan/o'qilmagan holat (yangi — belgi), guruhlash (10 ta xabar — bir bildirishnoma — "10 yangi xabar"), sozlamalar (qaysi bildirishnoma — foydalanuvchi tanlaydi); don't spam (ko'p bildirishnoma — foydalanuvchi bezor bo'ladi — o'chiradi — kam, muhim). Ikki nuqta: (1) bildirishnoma — in-app (real-time — ilova ichida) + push (ilova yopiq — Web Push) + email (muhim — asinxron); (2) onlayn Socket.io (darrov — real-time); offline DB + push/email (keyin/tashqaridan). Bildirishnoma — real-time'ning yana bir keng holati (chat — 3; bildirishnoma — bu — yangi hodisa push). Onlayn/offline mantiqi muhim (onlayn — darrov Socket.io; offline — DB saqla + push/email — keyin ko'radi yoki tashqaridan). Push (ilova yopiq — Web Push) — eng kuchli (foydalanuvchi ilovada bo'lmasa ham — telefon push — qaytaradi), lekin ruxsat kerak (foydalanuvchi tasdiqlaydi). Don't spam — muhim (ko'p bildirishnoma — bezor — o'chiradi — kam, qiymatli, sozlanadigan). Bildirishnoma — SaaS, chat, har ilovada (16.1 TaskFlow — tayinlash bildirishnoma; chat — yangi xabar). Bu real-time'ning amaliy qo'llanishi (server foydalanuvchiga push — yangi hodisa).

5. Bosqichma-bosqich va muammolar

  REAL-TIME CHAT QURISH (bosqichlar — 5.13, 11, 6 QISM):

  BOSQICH 1 — POYDEVOR:
   Socket.io server 5.13-bob + React client (11) + auth
   oddiy ulanish (connect/disconnect)

  BOSQICH 2 — ASOSIY CHAT:
   xona (room) — guruh; emit/on (xabar yuborish/olish)
   xabar broadcast (xonaga) + DB saqlash (6)

  BOSQICH 3 — TARIX:
   HTTP API (o'tgan xabarlar — DB'dan — 13.6)
   real-time (yangi) + HTTP (eski) birga

  BOSQICH 4 — PRESENCE:
   online holati (Redis — kim onlayn — 5.21)
   "yozyapti" indikatori (broadcast)

  BOSQICH 5 — BILDIRISHNOMA:
   in-app (Socket.io) + push (offline — 4)

  BOSQICH 6 — MIQYOS (muammolar):
   ko'p server (Redis pub/sub — serverlar orasida xabar)
   ulanish boshqaruvi; auth (WebSocket'da)

  REAL-TIME MUAMMOLARI:
   Ulanish ishonchsiz (uzilish  auto-reconnect, xabar yo'qolmasin)
   Miqyos (ko'p ulanish — Redis pub/sub, sticky session)
   Auth (WebSocket — token tekshir — ulanishda)
   Tartib/dublikat (xabar tartibi, takror — idempotency)

   Bosqichlar — poydevor  chat  tarix  presence  bildirishnoma  miqyos
   Muammolar — ulanish (reconnect), miqyos (Redis pub/sub), auth, tartib

Bosqichma-bosqich va muammolar — real-time chat qurish va muammolari. Bosqichlar (5.13, 11, 6 QISM): (1) poydevor — Socket.io server 5.13-bob + React client (11) + auth; oddiy ulanish (connect/disconnect); (2) asosiy chat — xona (room) — guruh; emit/on (xabar yuborish/olish); xabar broadcast (xonaga) + DB saqlash (6); (3) tarix — HTTP API (o'tgan xabarlar — DB'dan — 13.6); real-time (yangi xabarlar) + HTTP (eski tarix) birga (3.2 — chat ochilganda tarix HTTP, keyin yangilar WebSocket); (4) presence — online holati (Redis — kim onlayn — 5.21) + "yozyapti" indikatori (broadcast — 2.2); (5) bildirishnoma — in-app (Socket.io) + push (offline — 4); (6) miqyos (muammolar) — ko'p server (Redis pub/sub — serverlar orasida xabar — 3 — bir serverdagi foydalanuvchi boshqa serverdagiga); ulanish boshqaruvi; auth (WebSocket'da — token). Real-time muammolari: (1) ulanish ishonchsiz (tarmoq uzilishi — auto-reconnect — Socket.io qiladi — 2.2; xabar yo'qolmasin — uzilgan paytdagi xabar — qayta yuborish/saqlash); (2) miqyos (ko'p ulanish — millionlab WebSocket — bir server ko'tara olmaydi — Redis pub/sub — serverlar orasida, sticky session — bir foydalanuvchi bir serverga — load balancer); (3) auth (WebSocket — token tekshir — ulanishda — kim ulanyapti — 14.6); (4) tartib/dublikat (xabar tartibi — to'g'ri ketma-ketlik, takror — bir xabar ikki marta — idempotency — 13.5). Ikki nuqta: (1) bosqichlar — poydevor chat tarix presence bildirishnoma miqyos (tizimli — oddiy ulanishdan miqyosga); (2) muammolar — ulanish (reconnect — uzilsa), miqyos (Redis pub/sub — ko'p server), auth (WebSocket token), tartib/dublikat. Bu — real-time chat qurish rejasi (5.13 Socket.io amaliyoti — bosqichma-bosqich). Real-time muammolari (so'rov-javobdan farqli — yangi muammolar): (1) ulanish ishonchsiz (WebSocket doimiy — uzilishi mumkin — auto-reconnect, xabar yo'qolmaslik — eng keng muammo); (2) miqyos (ko'p doimiy ulanish — bir server cheklangan — Redis pub/sub — ko'p server, sticky session); (3) auth (WebSocket'da — token tekshir — ulanishda — HTTP'dagi kabi — 14.6); (4) tartib/dublikat (xabar tartibi, takror — idempotency). Redis pub/sub — miqyos kaliti (ko'p server — bir serverdagi xabar boshqa serverdagi foydalanuvchiga — Redis orqali — 5.21). Real-time — kuchli (jonli UX), lekin murakkab (ulanish, miqyos, auth — so'rov-javobdan ko'ra). Bu capstone — real-time amaliyoti (5.13 Socket.io real chat — bosqichma-bosqich, muammolar bilan).

6. Real-time miqyos va best practices

  REAL-TIME MIQYOS (ko'p ulanish — qiyin):

  MIQYOS MUAMMOSI:
   bir server ~10K-50K WebSocket ulanish (cheklangan — xotira/CPU)
   millionlab ulanish  ko'p server kerak

  YECHIM:
   REDIS PUB/SUB 5.21-bob: serverlar orasida xabar
    server1'dagi xabar  Redis  server2'dagi foydalanuvchiga
   STICKY SESSION: bir foydalanuvchi bir serverga (load balancer)
   horizontal (server qo'shish) + Redis adapter (Socket.io)

  REAL-TIME BEST PRACTICES:
   Auth (WebSocket ulanishda token tekshir — 14.6)
   Auto-reconnect (Socket.io — uzilsa qayta)
   Xabar saqlash (DB — yo'qolmasin; offline foydalanuvchi)
   Idempotency (takror xabar — bir marta)
   Rate limit (spam — 14.8)
   Presence (Redis — kim onlayn)
   Don't over-use (faqat real-time kerak joyda — HTTP yetsa HTTP)

   Real-time miqyos — Redis pub/sub (serverlar orasida) + sticky session + horizontal
   Best — auth, reconnect, saqlash, idempotency, rate limit (so'rov-javobdan murakkab)

Real-time miqyos va best practices — real-time'ni katta miqyosda va to'g'ri ishlatish. Miqyos muammosi: bir server ~10K-50K WebSocket ulanish ko'tara oladi (cheklangan — har ulanish xotira/CPU — HTTP'dan farqli — HTTP so'rov tugaydi, WebSocket doimiy — ochiq turadi); millionlab ulanish ko'p server kerak. Yechim: (1) Redis pub/sub 5.21-bob: serverlar orasida xabar — server1'dagi foydalanuvchi xabar yozsa, server2'dagi foydalanuvchiga yetishi kerak (har biri har xil serverga ulangan) Redis pub/sub orqali (server1 Redis server2 — 3 — Socket.io Redis adapter); (2) sticky session: bir foydalanuvchi bir serverga (load balancer — 10.7 — bir foydalanuvchining barcha so'rovi bir serverga — WebSocket doimiy — bir serverda qolishi kerak); (3) horizontal (server qo'shish — 15.7: 2.4) + Redis adapter (Socket.io — ko'p server umumiy). Real-time best practices: (1) auth (WebSocket ulanishda token tekshir — 14.6 — kim ulanyapti); (2) auto-reconnect (Socket.io — uzilsa qayta — 2.2); (3) xabar saqlash (DB — yo'qolmasin; offline foydalanuvchi keyin ko'radi — 4); (4) idempotency (takror xabar — bir marta — 13.5 — tarmoq retry); (5) rate limit (spam — 14.8 — ko'p xabar); (6) presence (Redis — kim onlayn — 5.21); (7) don't over-use (faqat real-time kerak joyda — HTTP yetsa HTTP — 2.1 — har narsani WebSocket qilma — chat/jonli real-time, qolgani HTTP). Ikki nuqta: (1) real-time miqyos — Redis pub/sub (serverlar orasida), sticky session, horizontal (ko'p WebSocket — bir server cheklangan); (2) best — auth, reconnect, saqlash, idempotency, rate limit (so'rov-javobdan murakkabroq — yangi muammolar). Miqyos real-time'ning eng katta muammosi (WebSocket doimiy — bir server cheklangan — Redis pub/sub + horizontal). Redis pub/sub 5.21-bob — kaliti (ko'p server — xabar serverlar orasida — Socket.io Redis adapter avtomatlashtiradi). Don't over-use 2.1-bob — muhim (real-time murakkab — faqat kerak joyda — chat, jonli — qolgani HTTP — 13-QISM — sodda; har narsani WebSocket — over-engineering). Real-time — jonli UX (kuchli), lekin murakkab (ulanish, miqyos, auth) — to'g'ri ishlatish (kerak joyda, best practices bilan). Bu — real-time'ning yetuk ishlatilishi (5.13 + miqyos + best practices). Bu capstone — real-time amaliyoti (chat, bildirishnoma) — jonli, interaktiv ilova (portfolio'da ajraladi — texnik chuqurlik — 15.8).

6.1. WebSocket'da autentifikatsiya (handshake JWT)

  WEBSOCKET AUTH — kim ulanyapti (14.6 JWT):

  HTTP'da: har so'rovda Authorization: Bearer <token>
  WEBSOCKET'da: bir marta handshake'da token  keyin ulanish "ishonchli"

  1. Client ulanishda token uzatadi:
       io(url, { auth: { token } })  // Socket.io handshake
  2. Server handshake middleware'da tekshiradi:
       token yaroqli?  socket.data.userId = payload.sub  ruxsat
       yaroqsiz?       ulanishni rad et (disconnect)
  3. Keyingi har emit — socket.data.userId bilan (qayta login yo'q)

   Token — HANDSHAKE'da bir marta (har xabarda emas)
   Yaroqsiz token  ulanish RAD (jim tashlab yuborma — xato qaytar)

WebSocket'da autentifikatsiya — kim ulanayotganini tekshirish (14.6 JWT). HTTP'da har so'rovda Authorization: Bearer <token> yuboriladi; WebSocket'da ulanish doimiy, shuning uchun token bir marta handshake'da tekshiriladi — keyin ulanish "ishonchli" hisoblanadi. Oqim: (1) client ulanishda tokenni uzatadi (io(url, { auth: { token } })); (2) server handshake middleware'da tokenni tekshiradi — yaroqli bo'lsa socket.data.userId'ga foydalanuvchi id'sini yozadi va ruxsat beradi, yaroqsiz bo'lsa ulanishni rad etadi (disconnect); (3) keyingi har emit shu socket.data.userId bilan bog'lanadi (qayta login yo'q). NestJS Gateway'da bu — handleConnection yoki guard orqali. Ikki nuqta: (1) token — handshake'da bir marta (har xabarda emas — ortiqcha ish); (2) yaroqsiz token ulanishni rad et (jim tashlab yubormang — aniq xato qaytaring). Muhim nuanslar: token muddati o'tsa ulanishni uzish (yoki reconnect'da yangi token), va xonaga qo'shilishda avtorizatsiya (foydalanuvchi shu suhbat a'zosimi — Participant tekshiruvi — begona xonaga kira olmasin).

6.2. Frontend real-time (optimistic UI, reconnect, state, virtualizatsiya)

  FRONTEND REAL-TIME (React — 11/12-QISM):

  SOCKET.IO CLIENT: bitta ulanish (kontekst/provider) — butun ilovaga
  STATE: xabarlar ro'yxati (12-QISM state) — "message:new" kelsa qo'shiladi
  OPTIMISTIC UI: xabar darrov ekranga (kutmasdan)  server tasdiqlasa "yetdi",
                 xato bo'lsa "qayta yuborish" belgisi
  RECONNECT: uzilsa  banner ("qayta ulanmoqda"), qayta ulanganda o'tkazib
             yuborilgan xabarlarni HTTP bilan yuklab olish (bo'shliqni to'ldirish)
  VIRTUALIZATSIYA: uzun xabar ro'yxati  faqat ko'rinadigan qism render 11.11-bob
  LAZY TARIX: yuqoriga scroll  eski xabarlar HTTP bilan (pagination — 3.3)

   Optimistic UI — xabar darrov (server javobini kutmasdan)  keyin tasdiq/xato
   Uzun ro'yxat — virtualizatsiya 11.11-bob; tarix — lazy pagination

Frontend real-time — chat UI'ni React'da qurish (11/12-QISM). Socket.io client — bitta ulanish (kontekst/provider orqali butun ilovaga tarqatiladi — har komponent alohida ulanmaydi). State — xabarlar ro'yxati (12-QISM state boshqaruvi); message:new kelganda ro'yxatga qo'shiladi (React qayta render qiladi). Optimistic UI — foydalanuvchi xabar yuborganda darrov ekranga chiqadi (server javobini kutmasdan — jonli his); server tasdiqlasa "yetkazildi" belgisi, xato bo'lsa "qayta yuborish" belgisi. Reconnect — ulanish uzilsa banner ("qayta ulanmoqda"), qayta ulanganda uzilish paytida o'tkazib yuborilgan xabarlarni HTTP bilan yuklab olish (bo'shliqni to'ldirish — faqat WebSocket'ga tayanmang). Virtualizatsiya — uzun xabar ro'yxati (minglab xabar) faqat ko'rinadigan qismini render qiladi (11.11 — DOM'ni yengil tutish). Lazy tarix — yuqoriga scroll qilganda eski xabarlar HTTP pagination bilan yuklanadi 3.3-bob. Ikki nuqta: (1) optimistic UI — xabar darrov (server javobini kutmasdan) keyin tasdiq/xato; (2) uzun ro'yxat — virtualizatsiya 11.11-bob, tarix — lazy pagination. Bu — chat frontend'ining "jonli" his beruvchi qismi (optimistic + reconnect + virtualizatsiya — silliq tajriba).

6.3. Offline, yetkazish kafolati va xavfsizlik

  OFFLINE / YETKAZISH / XAVFSIZLIK:

  OFFLINE NAVBAT: ulanish yo'q paytda yuborilgan xabar  lokal navbat 
                  qayta ulanganda yuboriladi (yo'qolmasin)
  YETKAZISH KAFOLATI: har xabarga clientMessageId (idempotency 13.5) 
                  takror yuborilsa server BIR marta qabul qiladi
  DELIVERY HOLATI: yuborilmoqda  yetdi  o'qildi (uch bosqich)

  XAVFSIZLIK:
   Input sanitize — xabar matni XSS'ga qarshi tozalanadi 14.2-bob
    (foydalanuvchi <script> yuborsa — zararsizlantiriladi)
   Rate limit — bir foydalanuvchi N xabar/soniya (spam/DoS — 14.8)
   Avtorizatsiya — faqat a'zo xonaga yozadi (begona rad)

   Offline — lokal navbat + clientMessageId (idempotency)  yo'qolmasin, dublikatsiz
   XSS — xabar matnini sanitize 14.2-bob; rate limit — spam (14.8)

Offline, yetkazish kafolati va xavfsizlik — chat'ning ishonchli va xavfsiz bo'lishi. Offline navbat — ulanish yo'q paytda yuborilgan xabar lokal navbatga qo'yiladi, qayta ulanganda yuboriladi (yo'qolmasin). Yetkazish kafolati — har xabarga client tomonda clientMessageId beriladi (idempotency — 13.5); tarmoq retry tufayli takror yuborilsa server uni bir marta qabul qiladi (dublikatsiz). Delivery holati — uch bosqich: yuborilmoqda yetkazildi o'qildi (WhatsApp'dagi belgilar kabi). Xavfsizlik: (1) input sanitize — xabar matni XSS'ga qarshi tozalanadi (14.2 — foydalanuvchi <script> yuborsa zararsizlantiriladi, chunki xabar boshqa foydalanuvchilar ekranida ko'rsatiladi — saqlangan XSS xavfi); (2) rate limit — bir foydalanuvchi soniyada N tadan ortiq xabar yubora olmasin (spam/DoS — 14.8); (3) avtorizatsiya — faqat suhbat a'zosi o'sha xonaga yoza oladi (begona rad etiladi — 6.1). Ikki nuqta: (1) offline — lokal navbat + clientMessageId (idempotency) xabar yo'qolmasin va dublikatsiz; (2) XSS — xabar matnini sanitize qilish (14.2 — chat XSS uchun asosiy nishon), rate limit — spam 14.8-bob. Bu — chat'ni "o'yinchoq"dan "ishonchli mahsulot"ga aylantiruvchi qatlam (yo'qolmaslik, dublikatsizlik, XSS/spam himoyasi).

6.4. Deploy va test

  DEPLOY (WebSocket) va TEST:

  DEPLOY:
   Nginx reverse proxy: WebSocket "Upgrade" sarlavhalarini uzatish sozlash 10.2-bob
      proxy_set_header Upgrade $http_upgrade; Connection "upgrade";
   Sticky session — bir foydalanuvchi bir instance'ga (load balancer)
   Ko'p instance  Socket.io Redis adapter (6-miqyos)
   HTTPS/WSS — shifrlangan WebSocket (14 xavfsizlik)

  TEST:
   Unit — xabar mantiqiy funksiyalar (idempotency, o'qildi hisobi)
   Integratsiya — Socket.io client bilan real ulanish, emit/on tekshirish
   Yuk (load) — ko'p bir vaqtli ulanish (miqyos chegarasi)

   Nginx — "Upgrade" sarlavhasini uzatishi shart (aks holda WebSocket ishlamaydi)
   Test — Socket.io client'ni sinovda ishlatib emit/on tekshiring

Deploy va test — real-time ilovani ishga tushirish va sinash. Deploy: (1) Nginx reverse proxy WebSocket "Upgrade" sarlavhalarini uzatadigan qilib sozlanishi shart (Upgrade/Connection: upgrade — 10.2 — aks holda handshake muvaffaqiyatsiz, WebSocket ishlamaydi); (2) sticky session — bir foydalanuvchi bir instance'ga (load balancer — 6-miqyos); (3) ko'p instance bo'lsa — Socket.io Redis adapter (serverlar orasida xabar — 6); (4) HTTPS/WSS — shifrlangan WebSocket (14-QISM — ochiq WebSocket emas). Test: (1) unit — xabar mantiqiy funksiyalari (idempotency, o'qilmagan hisobi); (2) integratsiya — sinovda Socket.io client bilan real ulanish ochib, emit/on orqali oqimni tekshirish; (3) yuk (load) testi — ko'p bir vaqtli ulanish (miqyos chegarasini bilish — 6). Ikki nuqta: (1) Nginx "Upgrade" sarlavhasini uzatishi shart (WebSocket deploy'da eng ko'p uchraydigan xato — buni unutish); (2) test — sinovda Socket.io client'ni ishlatib emit/on oqimini tekshiring (faqat HTTP test yetmaydi). Bu — capstone'ni haqiqiy productionga olib chiquvchi qadam (deploy sozlamasi + test — portfolio'da "ishlaydi" degani).

6.5. Kengaytirish (video/audio qo'ng'iroq — WebRTC)

Chat va bildirishnoma ishlagach, loyihani kengaytirish mumkin: video/audio qo'ng'iroq. Bu — WebRTC (brauzerlar orasida to'g'ridan-to'g'ri, peer-to-peer aloqa — audio/video oqim). WebSocket bu yerda signaling (aloqa o'rnatish — kim kimga qo'ng'iroq qilyapti, ulanish ma'lumotlarini almashish) uchun ishlatiladi, keyin media oqimi to'g'ridan-to'g'ri ikki brauzer orasida boradi (server orqali emas — tez, kam yuk). Bu — alohida katta mavzu (capstone'ning majburiy qismi emas), lekin "keyingi qadam" sifatida ajoyib kengaytma (Discord/Zoom yo'nalishi). Boshlash uchun — bir kanalli 1:1 audio qo'ng'iroqni signaling WebSocket ustida qurib ko'ring.

7. Integratsiya — bu loyiha qaysi QISMlarni birlashtiradi

• Socket.io 5.13-bob: WebSocket, xonalar, emit/on, namespace, broadcast (real-time poydevori).
• React (11/12-QISM): chat UI, real-time state, optimistic UI, virtualizatsiya 11.11-bob.
• DB (6-QISM): xabar/suhbat/a'zo sxemasi, xabar saqlash (tarix — 3.2).
• Redis 5.21-bob: presence, pub/sub (miqyos), Socket.io Redis adapter.
• HTTP API 13.6-bob: tarix (cursor pagination — 3.3), auth, media upload.
• Xavfsizlik (14-QISM): WebSocket auth 14.6-bob, XSS sanitize 14.2-bob, rate limit 14.8-bob.
• DevOps (10-QISM): Nginx WebSocket proxy 10.2-bob, sticky session, horizontal (miqyos).

8. Eng yaxshi amaliyotlar (best practices)

• WebSocket faqat real-time'ga (HTTP yetsa HTTP — 2.1, 6).
• Socket.io (auto-reconnect, xonalar — 2.2).
• Xona (room) (chat guruhi — broadcast — 3).
• Ma'lumot modeli avval (conversation/participant/message — 3.2).
• Xabar saqlash (DB — yo'qolmasin — 4); typing — DB'siz 3.3-bob.
• Auth handshake'da (WebSocket ulanishda JWT bir marta — 6.1, 14.6).
• Optimistic UI + reconnect (jonli his, bo'shliqni HTTP bilan to'ldirish — 6.2).
• Redis pub/sub (ko'p server miqyos — 6).
• Auto-reconnect + offline navbat (uzilsa — 2.2, 6.3).
• Idempotency (clientMessageId — takror xabar bir marta — 6.3).
• XSS sanitize (chat matni — 14.2) + rate limit (spam — 14.8).
• Nginx "Upgrade" (WebSocket deploy — 10.2, 6.4).
• Don't spam (bildirishnoma — kam, muhim — 4).

9. Capstone loyiha: "Real-time Chat Ilova"

Real-time ilovani amalda mustahkamlash.

Maqsad

Real-time chat ilova (Slack/Discord kabi) qur — jonli xabar, presence, bildirishnoma.

Talablar (requirements)

1. Texnologiya tanlovi: WebSocket/SSE/long-polling va Socket.io/native ws tanlovini asoslang 3.1-bob.
2. WebSocket: Socket.io (yoki NestJS Gateway) server + client 5.13-bob.
3. Ma'lumot modeli: message/conversation/participant sxemasi 3.2-bob.
4. Chat: 1:1 va guruh xona, real-time xabar (emit/on — 3.3).
5. Tarix: o'tgan xabarlar, cursor pagination (HTTP + DB — 3.3).
6. Presence + typing: online holati (Redis) va "yozyapti" indikatori (4, 3.3).
7. O'qildi + media: o'qildi belgisi va media/fayl yuborish 3.3-bob.
8. Bildirishnoma: in-app + push (FCM/Web Push) + offline (4).
9. Auth: WebSocket handshake'da JWT token (6.1, 14.6).
10. Reconnect + offline: uzilsa qayta + xabar navbati/idempotency (6.2, 6.3).
11. Miqyos: Redis pub/sub, sticky session, horizontal (6).
12. Xavfsizlik: XSS sanitize 14.2-bob, rate limit 14.8-bob, avtorizatsiya.
13. Deploy + test: Nginx WebSocket proxy 10.2-bob, integratsiya/yuk testi 6.4-bob.

Maslahatlar (hint)

• Socket.io yoki NestJS WebSocket Gateway 5.13-bob.
• Xona = conversationId; xabar xonaga broadcast 3.3-bob.
• Sxemani avval loyihalang: conversation/participant/message 3.2-bob.
• Xabar va o'qildi — DB'ga; typing — vaqtinchalik (DB'siz — 3.3).
• WebSocket auth — handshake'da JWT (6.1, 14.6).
• Optimistic UI + reconnect'da bo'shliqni HTTP bilan to'ldirish 6.2-bob.
• clientMessageId — idempotency (dublikatsiz — 6.3, 13.5).
• Redis pub/sub — ko'p server miqyos (6).

"Tayyor" mezonlari (acceptance criteria)

• Real-time chat (darrov xabar — optimistic UI).
• 1:1 va guruh xona.
• Tarix (HTTP + DB, cursor pagination).
• Presence (online) + typing indikatori.
• O'qildi belgisi + media/fayl yuborish.
• Bildirishnoma (in-app + push, offline).
• WebSocket auth (handshake JWT).
• Reconnect + offline navbat (xabar yo'qolmaydi, dublikatsiz).
• Miqyos (Redis pub/sub) sozlangan.
• XSS sanitize + rate limit.
• Nginx WebSocket deploy sozlamasi.

Bu SIZNING capstone loyihangiz — kodini o'zingiz yozasiz.

Qiyinchilik bo'lsa — mos QISMni qayta ko'rib chiqing (5.13 Socket.io, 11 React, 5.21 Redis, 14 xavfsizlik). Har bosqich uchun ushbu bobdagi arxitektura, funksiyalar ro'yxati va "tayyor" mezonlari yo'l xaritasi vazifasini o'taydi.

10. Xulosa va keyingi bobga ko'prik

Bu bobda real-time ilova capstone'ni rejalashtirdik:

• So'rov-javob vs real-time 2.1-bob; WebSocket/Socket.io 2.2-bob; chat g'oyasi/arxitektura (3); texnologiya tanlovi/ma'lumot modeli/funksiyalar (3.1–3.3); bildirishnoma (4); bosqichlar/muammolar (5); miqyos/best practices (6); WebSocket auth, frontend, offline/xavfsizlik, deploy/test, WebRTC kengaytma (6.1–6.5).

Endi siz real-time ilova qura olasiz: texnologiya tanlovini asoslash, ma'lumot modeli (conversation/participant/message), WebSocket (Socket.io), chat (xona, broadcast, typing, o'qildi, media), presence, bildirishnoma (in-app + push), handshake auth, optimistic UI + reconnect, offline navbat + idempotency, XSS/rate limit, va miqyos (Redis pub/sub) — jonli, interaktiv, ishonchli tajriba. Bu — texnik chuqurlikni ko'rsatadigan portfolio loyihasi.

Keyingi bob — 16.4-bob: Kitob yakuni — bitiruv va keyingi yo'l. 16-QISMni va butun kitobni yakunlaymiz: o'tilgan yo'lning umumiy ko'rinishi (0-16 QISM), siz endi nimani bilasiz va qila olasiz, professional dasturchi sifatida keyingi qadamlar, va doimiy o'sish yo'li. Bu — sizning safaringizning tantanali yakuni va kelajakka ko'prik.

Foydalanilgan rasmiy/ishonchli manbalar

• Socket.io rasmiy hujjati — WebSocket, xonalar (rooms), namespace, broadcast, Redis adapter bilan miqyoslash
• NestJS rasmiy hujjati — WebSocket Gateways, WsAdapter, gateway'da JWT autentifikatsiya
• WebSocket API va WebSocket protokoli (RFC 6455) — handshake, "upgrade", ikki tomonlama ulanish
• Web Push API va Service Workers — push bildirishnoma (ilova yopiq bo'lsa ham), ruxsat so'rash
• Firebase Cloud Messaging (FCM) rasmiy hujjati — push bildirishnoma (mobil va web)
• Redis Pub/Sub va Redis'da presence — serverlar orasida xabar, "kim onlayn"
• "Scaling WebSockets" qo'llanmalari — sticky session, horizontal miqyos, load balancer
• SSE (Server-Sent Events) — bir tomonlama serverclient (bildirishnoma uchun muqobil)
• WebRTC — peer-to-peer real-time (video/audio qo'ng'iroq — kengaytirish uchun eslatma)