SPA

SPA — foydalanuvchi dastur ichida harakatlanganda har bir sahifa uchun serverdan to‘liq yangi HTML hujjat yuklamasdan ishlaydigan web application arxitekturasi. To‘liq nomi Single-Page Application.

SPA dastlab bitta asosiy document va JavaScript bundle yuklaydi. Keyingi navigatsiya, data olish va interfeys yangilanishi client tomonda bajariladi.

Boshlang‘ich yuklanish

Browser odatda:

1. HTML shell oladi;
2. CSS va JavaScript yuklaydi;
3. application ishga tushadi;
4. kerakli API data olinadi;
5. UI render qilinadi.

Bundle katta bo‘lsa birinchi interaktiv holat kechikishi mumkin.

Code splitting bu hajmni bo‘lishga yordam beradi.

Client-side routing

SPA route o‘zgarishini JavaScript router boshqaradi.

Masalan:

/dashboard
/profile
/orders/15

Browser yangi document olmaydi.

Router URLga mos componentni render qiladi.

History API back va forward tugmalarini qo‘llab-quvvatlaydi.

Server fallback

User /orders/15 URLni to‘g‘ridan-to‘g‘ri ochsa server shu route uchun SPA shellni qaytarishi kerak.

Aks holda server file topolmay 404 beradi.

Static asset, API va frontend route’lar alohida ajratiladi.

API

SPA backend bilan API orqali aloqa qiladi.

Formatlar:

• JSON;
• GraphQL response;
• gRPC-Webga oid format;
• boshqa serializatsiya.

Authentication cookie yoki token orqali ishlashi mumkin.

CORS va CSRF modeli architecture’ga bog‘liq.

Component

Interfeys componentlarga bo‘linadi.

Component:

• state;
• property;
• event;
• lifecycle;
• template yoki render logic

ga ega bo‘lishi mumkin.

Framework virtual DOM, reactive signal yoki boshqa render modelidan foydalanadi.

State

SPA’da ko‘p UI state clientda saqlanadi:

• current user;
• filter;
• route;
• form;
• cache;
• modal;
• server data.

Local va global state aralashib ketmasligi kerak.

Server state uchun query cache va invalidation alohida muammo.

Navigatsiya tezligi

Dastlabki bundle yuklangach route o‘zgarishi tez bo‘lishi mumkin.

Faqat yangi data va kerakli code chunk olinadi.

To‘liq document reload bo‘lmagani sabab scroll, animation va state yumshoq boshqariladi.

Deep link

Har muhim view barqaror URLga ega bo‘lishi kerak.

Bu:

• bookmark;
• share;
• browser history;
• analytics;
• support;
• SEO

uchun zarur.

Faqat modal state ichida yashiringan route foydalanuvchiga qayta ochish imkonini bermasligi mumkin.

SEO

Client-only renderda crawler JavaScriptni bajarishi kerak.

Barcha crawler bir xil capability va vaqtga ega emas.

Muhim public sahifalar uchun SSR, SSG yoki prerender ishlatilishi mumkin.

Meta tag va canonical URL route bo‘yicha yangilanadi.

Performance

SPA performance muammolari:

• katta JavaScript;
• uzoq hydration yoki startup;
• main thread bandligi;
• ko‘p API request;
• memory leak;
• client rendering;
• cache xatosi.

Lazy loading, tree shaking va route-based chunk ishlatiladi.

Error handling

API yoki chunk yuklanmasa application to‘liq oq ekran bo‘lib qolmasligi kerak.

Error boundary, retry, offline xabar va recovery UI ishlatiladi.

Yangi deploymentdan keyin eski HTML yangi yo‘qolgan chunkga murojaat qilishi mumkin.

Authentication

SPA authentication state clientda ko‘rinadi, ammo authorization serverda tekshiriladi.

Frontend admin route’ni yashirishi mumkin, lekin API har request uchun permissionni baholaydi.

Sensitive tokenni localStorage’da saqlash XSS threat modelini kuchaytirishi mumkin.

XSS

SPA katta JavaScript va dynamic content ishlatgani sabab XSS muhim xavf.

Himoya:

• default escaping;
• ishonchsiz HTMLni sanitize qilish;
• CSP;
• dependency nazorati;
• innerHTMLga ehtiyotkor munosabat.

XSS attackerga user sessionida API chaqirish imkonini berishi mumkin.

Offline

Service Worker va local cache bilan SPA ayrim funksiyalarni offline qo‘llab-quvvatlashi mumkin.

Bu PWA xususiyatiga yaqin.

Offline data sync conflict va freshness masalasini keltiradi.

SPA va MPA

SPA navigatsiyani clientda bajaradi.

MPA har route uchun serverdan yangi document oladi.

SPA murakkab interaktiv dasturlar uchun qulay.

MPA content-heavy va server-centric sahifalarda sodda bo‘lishi mumkin.

SPA va SSR

SPA client-side routingga ega bo‘lsa ham dastlabki HTML serverda render qilinishi mumkin.

Bunday hybrid architecture SSRdan keyin hydration orqali SPA sifatida davom etadi.

SPA faqat CSR degani emas.

Monitoring

Client error, route timing, API latency va bundle load kuzatiladi.

Server logning o‘zi client crash va render xatolarini ko‘rsatmaydi.

Real User Monitoring foydalanuvchi qurilmasidagi natijani o‘lchaydi.

Version almashinuvi

Yangi deployment vaqtida user eski HTML va JavaScript bilan ochiq tabni uzoq saqlashi mumkin. Keyin lazy chunk yoki API yangi versiyaga mos kelmasligi ehtimoli bor. Assetlar content hash bilan immutable saqlanadi, API backward compatibility va chunk load error uchun reload mexanizmi yaratiladi.

Server state va client state

Serverdan kelgan data client UI state’idan ajratiladi. Modal ochiqligi local state, order holati esa server state hisoblanadi. Server data cache qilinsa stale vaqt, background refetch va mutationdan keyingi invalidation aniq boshqariladi.

Scroll va focus

Client route o‘zgarganda browser to‘liq document navigatsiyasidagi behaviorni avtomatik bajarmaydi. Router scroll restoration, page title va asosiy headingga focus berishni boshqaradi. Bu keyboard va screen reader foydalanuvchilari uchun muhim.

Bog‘liq tushunchalar

Single-Page Application, Client-side routing, History API, CSR, SSR, API, Component, State management, Code splitting, Progressive Web App