Loyihani deploy qilish

Frontend/statik saytni deploy qilish

Backend serverni VPS'ga qo'yishni ko'rdik. Frontend — ya'ni React, Vue, Angular yoki oddiy statik sayt — ancha soddaroq deploy qilinadi. Chunki natija oxir-oqibat shunchaki statik fayllar (HTML, CSS, JS) bo'ladi, va ularni maxsus statik hosting platformalari deyarli bepul, juda oson joylashtiradi. Ushbu darsda build jarayonini, mashhur platformalarni va SPA'ga xos sozlamalarni o'rganamiz.

Bu darsdagi buyruqlar (npm run build kabi) lokalxostda ham, platforma serverida ham ishlaydi. Platforma sozlamalari esa statik config fayllar orqali beriladi — ular ham tushunib o'qish uchun keltirilgan.

Build jarayoni nima?

Zamonaviy frontend loyihalari brauzer to'g'ridan-to'g'ri tushunmaydigan narsalar bilan yoziladi: JSX (React), .vue fayllar, TypeScript, SCSS, ES modullar. Build — bu shu manba kodni brauzer tushunadigan oddiy HTML, CSS va JavaScript'ga aylantirish jarayoni.

Build vositasi (Vite, webpack, esbuild va boshqalar) kodni qayta ishlaydi, birlashtiradi (bundle), kichraytiradi (minify) va tayyor natijani odatda dist/ yoki build/ papkasiga joylaydi:

# Frontend loyihasini build qilish:
$ npm run build

# Natija dist/ papkasida hosil bo'ladi:
dist/
  index.html
  assets/
    index-a1b2c3.js
    index-d4e5f6.css

Ana shu dist/ papkasidagi fayllar — deploy qilinadigan yakuniy natija. Bu fayllar hech qanday Node.js talab qilmaydi; ularni istalgan oddiy veb-server (Nginx, GitHub Pages) yoki statik hosting uzata oladi.

npm run build aslida package.jsondagi scripts.build buyrug'ini ishga tushiradi. Aynan qaysi vosita ishlashini shu yerda ko'rasiz — masalan, "build": "vite build".

Statik hosting nima?

Statik hosting — bu HTML/CSS/JS fayllarni internetga chiqarish uchun maxsus sozlangan xizmat. Ular server boshqaruvini talab qilmaydi: siz faqat fayllarni (yoki Git repozitoriyani) berasiz, platforma qolganini o'zi bajaradi — global keshlash (CDN), HTTPS, avtomatik build.

Uchta eng mashhur bepul (yoki bepul rejasi bor) platforma: Netlify, Vercel va GitHub Pages. Ularning umumiy ishlash printsipi bir xil: Git repozitoriyaga ulanasiz, platforma har push'da avtomatik build qilib, natijani chiqaradi.

Netlify

Netlify — statik saytlar uchun eng mashhur platformalardan biri. GitHub repozitoriyangizni ulaysiz, build buyrug'i va chiqish papkasini ko'rsatasiz — tamom. Har git push'da avtomatik qayta deploy bo'ladi.

Sozlamalarni panel orqali ham, loyiha ildizidagi netlify.toml fayli orqali ham berish mumkin:

# netlify.toml
[build]
  command = "npm run build"
  publish = "dist"

[[redirects]]
  from = "/*"
  to = "/index.html"
  status = 200

Bu yerda command — build buyrug'i, publish — chiqish papkasi. Pastdagi redirects qismi SPA marshrutlash uchun kerak — buni quyida batafsil ko'ramiz.

Netlify sizga tekin subdomen beradi (masalan, mening-loyiham.netlify.app). O'z domeningizni ham panel orqali bir necha bosishda ulash mumkin, HTTPS esa avtomatik yoqiladi — sertifikat bilan ovora bo'lmaysiz.

Vercel

Vercel — Netlify'ga juda o'xshash, ayniqsa Next.js loyihalari uchun optimallashgan platforma (Next.js'ni aynan Vercel yaratgan). Ish printsipi bir xil: GitHub'ni ulaysiz, u avtomatik freymvorkni aniqlaydi va build sozlamalarini o'zi taxmin qiladi.

Ko'p hollarda hech qanday config kerak emas — Vercel Vite, Create React App, Next.js kabi loyihalarni avtomatik taniydi. Kerak bo'lsa, vercel.json faylida sozlaysiz:

# vercel.json (SPA marshrutlash uchun)
{
  "rewrites": [
    { "source": "/(.*)", "destination": "/index.html" }
  ]
}
Netlify va Vercel'ning kuchli tomoni — oldindan ko'rish (preview) deploylari. Har bir Pull Request uchun alohida vaqtinchalik URL yaratiladi, shunda o'zgarishni birlashtirishdan oldin haqiqiy holatda ko'rib olish mumkin. Bu jamoada ishlashda juda qulay.

GitHub Pages

GitHub Pages — GitHub'ning bepul statik hosting xizmati. To'g'ridan-to'g'ri repozitoriyadan sayt chiqaradi. Oddiy statik saytlar, hujjatlar va portfolio uchun ideal. Odatda GitHub Actions bilan birga ishlatiladi — u avtomatik build qilib, natijani Pages'ga chiqaradi:

# .github/workflows/deploy.yml
name: Deploy to GitHub Pages

on:
  push:
    branches: [main]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run build
      - uses: actions/deploy-pages@v4
        with:
          path: dist
GitHub Pages'da sayt ko'pincha ildizda emas, balki /repo-nomi/ pastki yo'lida ochiladi (masalan, foydalanuvchi.github.io/loyiha/). Shu sababli build vositasida base yo'lni sozlash kerak, aks holda CSS/JS fayllari topilmaydi. Vite'da bu base: '/loyiha/' orqali beriladi.
// vite.config.js — GitHub Pages uchun base yo'l
export default {
  base: '/loyiha/',
};

SPA marshrutlash muammosi

SPA (Single Page Application — bir sahifali ilova) — React, Vue kabi loyihalarda odatiy holat. Bunda sayt aslida bitta index.html faylidan iborat, marshrutlash (routing) esa brauzerda JavaScript orqali bajariladi. Foydalanuvchi /haqida yoki /mahsulotlar sahifasiga o'tganda, brauzer serverga bormaydi — JS'ning o'zi to'g'ri komponentni ko'rsatadi.

Muammo shu yerda paydo bo'ladi: agar foydalanuvchi to'g'ridan-to'g'ri mening-saytim.uz/haqida manzilini ochsa yoki sahifani yangilasa (refresh), brauzer serverdan /haqida faylini so'raydi. Lekin bunday fayl yo'q — faqat index.html bor. Natijada server 404 qaytaradi.

Yechim: serverni shunday sozlash kerakki, u mavjud bo'lmagan har qanday yo'l uchun index.htmlni qaytarsin. Keyin brauzerdagi JS marshrutlash to'g'ri sahifani ko'rsatadi. Har platformada bu boshqacha yoziladi:

Agar SPA'ni o'z Nginx serveringizda joylashtirsangiz, config quyidagicha bo'ladi:

# Nginx'da SPA marshrutlash
server {
    listen 80;
    server_name mening-saytim.uz;
    root /var/www/mening-sayt/dist;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }
}
try_files $uri $uri/ /index.html; — kalit qator. U shunday ishlaydi: avval so'ralgan faylni ($uri) qidiradi, topilmasa papkani, u ham bo'lmasa index.htmlni qaytaradi. Shu tufayli har qanday yo'l ishlaydi va SPA marshrutlash buzilmaydi.

Frontend muhit o'zgaruvchilari

Frontend'da ham muhit o'zgaruvchilari kerak bo'ladi — masalan, API manzili. Lekin bu yerda muhim farq bor: build vaqtida o'zgaruvchilar kodga "qotib" qoladi va oxir-oqibat brauzerga yuklanadi. Ya'ni ular maxfiy emas — har kim ko'rishi mumkin.

Vite'da muhit o'zgaruvchilari VITE_ prefiksi bilan boshlanishi shart, aks holda ular kodga qo'shilmaydi. Ular .env fayliga yoziladi va import.meta.env orqali o'qiladi:

# .env (Vite loyihasida)
VITE_API_URL=https://api.mening-saytim.uz
VITE_APP_NAME=Mening Ilovam
// Kodda o'qish:
const apiUrl = import.meta.env.VITE_API_URL;
fetch(apiUrl + '/users')
  .then(r => r.json())
  .then(data => console.log(data));
Frontend muhit o'zgaruvchilariga hech qachon maxfiy ma'lumot (ma'lumotlar bazasi paroli, maxfiy API kaliti) yozmang! Ular build natijasida brauzer koduga kiradi va istalgan foydalanuvchi ularni ko'ra oladi. Maxfiy narsalar faqat backendda qoladi.
Netlify va Vercel panellarida muhit o'zgaruvchilarini alohida kiritish mumkin (Settings → Environment Variables). Bu .env faylini Git'ga qo'shmasdan, build vaqtida qiymatlarni yetkazishning toza yo'li.

Backend qayerda qoladi?

Statik hosting faqat frontend'ni chiqaradi — u Node.js serverni ishlata olmaydi. Odatda zamonaviy loyiha ikkiga bo'linadi:

Frontend backend'ga fetch orqali murojaat qiladi, manzil esa yuqorida ko'rgan VITE_API_URL muhit o'zgaruvchisidan olinadi. Shu tarzda ikki qism mustaqil deploy qilinadi va bir-biriga bog'lanadi.

Bunday ikki domenli tuzilishda CORS (Cross-Origin Resource Sharing) muammosiga duch kelishingiz mumkin — backend frontend domeniga ruxsat berishi kerak. Bu backend tomonida (masalan, Express'da cors middleware bilan) hal qilinadi.

Xulosa