Yo‘l · 37 maqola
Django/DRF asoslarini bilasiz — endi uni ishonchli, xavfsiz va production'da ishlaydigan qilib qurishni o‘rganasiz. To‘qqiz qadam, hammasi bu saytdagi mavjud maqolalardan tuzilgan: birma-bir, yoki kerakli qadamdan boshlab.
So'rovdan javobgacha: routing, serializatsiya, hujjatlar, fon vazifalar.
Python'da API yozishni boshlaganingizda birinchi to‘xtaladigan savolingiz — qaysi tool'da yozaman. Ikkalasida ham bir xil endpoint yozib, farqini o‘z ko‘zingiz bilan ko‘ramiz va qaysi biri qaysi loyihaga mos kelishini aniqlaymiz.
«Qanday endpoint'lar bor, nima yuboraman, nima keladi?» — frontend jamoasining abadiy savoli. drf-spectacular bilan API hujjati koddan avtomatik yasaladi va kod o'zgarsa hujjat ham o'zi yangilanadi. Netflix-uslub API misolida sozlaymiz.
Ro'yxat endpoint'i bazadagi hamma yozuvni qaytarsa, u vaqt bombasi: bugun 50 ta film, bir yildan keyin 50 ming. django-filter bilan filtrlash, qidiruv, tartiblash va sahifalashni Netflix-uslub API misolida to'liq sozlaymiz.
CORS xatosi deyarli har bir dasturchining jig‘iga tekkan, lekin ko‘pchilik uni noto‘g‘ri tushunadi va StackOverflow'dan «allow all» ni ko‘chirib, o‘ziga eshik ochib qo‘yadi. Same-Origin Policy, preflight so‘rov va Django'da to‘g‘ri sozlashni tartib bilan ko‘ramiz.
API'ingizni boshqa ilovalar ishlatishni boshlagach, unga har qanday o‘zgarish kiritish xavfli bo‘lib qoladi — bitta o‘zgarish yuzlab mijozni buzishi mumkin. Versiyalash shu muammoni yechadi va uni boshidan o‘ylagan ma'qul.
Ro‘yxatdan o‘tish tugmasini bosgan odam email yuborilishini kutib o‘tirmasligi kerak. Celery bilan sekin ishlarni so‘rovdan ajratamiz: navbat, worker va vazifani noldan yig‘ib, o‘zimiz ishga tushiramiz.
Sxema, migratsiya va indeks — kod yozishdan oldingi qaror.
FastAPI loyihasida odatda ikki xil klass yoziladi: bazaga SQLAlchemy modeli, so'rov-javobga Pydantic sxemasi. SQLModel shu ikkalasini bitta klassga jamlaydi. Doctolib loyihasidagi misollar bilan noldan boshlab ko'ramiz.
Modelga yangi maydon qo'shdingiz — bazada esa uni hech kim yaratmaydi. Django'da migrate bor edi, FastAPI dunyosida bu ishni Alembic qiladi. Sozlash, avtomatik migratsiya yaratish va uni ehtiyotkorlik bilan qo'llashni birma-bir ko'ramiz.
Indeks qidiruvni tezlashtiradi, lekin har yozuvni sekinlashtiradi — bu tekin kelmaydi. EXPLAIN bilan sekin so‘rovni o‘z ko‘zingiz bilan ko‘rasiz, indeks qo‘shib farqni o‘lchaysiz va nega har ustunga indeks qo‘yish yomon g‘oya ekanini tushunasiz.
Kod ishlashini emas, ishlashda davom etishini isbotlash.
Kod ishlayaptimi — brauzerda bosib ko'rish bilan tekshirib yurgan bo'lsangiz, bu maqola siz uchun. pytest-django'ni sozlaymiz, birinchi testni yozamiz va «o'zgartirishdan qo'rqmaslik» degan tuyg'u qayerdan kelishini ko'ramiz.
Hamma testlarni bir xil yozish — sekin va mo'rt test to'plamiga olib boradi. Unit test kichik va chaqqon, integration test katta va ishonchli. Bitta misol ustida ikkalasini yozib, farqini va qachon qaysi biri kerakligini aniqlaymiz.
API'ni Postman'da qo'lda bosib tekshirish ham 'brauzerda bosib ko'rish'ning o'zi. DRF'ning APIClient'i bilan endpoint'larni kod orqali tekshiramiz: to'g'ri javoblar, validatsiya xatolari va kirish ruxsatlari — ToDo API misolida.
Oldingi qismda chek yasaydigan dastur yozdik va u ishladi. Endi esa boshqa savol: **u har doim to'g'ri ishlaydimi?** Tekshirib ko'rsak, ba'zi holatlarda chekdagi qatorlarni qo'shganda bir summa chiqadi, pastdagi `JAMI` esa boshqa sonni ko'rsatadi. Bu qismda shu muammo va yana beshta kamchilikni topamiz, tuzatamiz va keyin qaytib chiqmasligi uchun testlar yozamiz.
Kod noutbukdan serverga qanday yetib boradi.
Jamoadagi eng ko‘p eshitiladigan ibora — «menda ishlayapti-ku». Docker Compose butun development muhitini bitta faylga yozadi. Postgres va Redis'ni bir buyruq bilan ko‘taramiz va yo‘l-yo‘lakay uchraydigan tuzoqlarni ko‘ramiz.
Hamma joyda «deploy demak Docker» deb o‘rgatishadi, lekin qo‘lingizda 1GB xotirali arzon VPS bo‘lsa, Docker ortiqcha yuk bo‘lishi mumkin. Shu sayt aynan Docker'siz ishlaydi — to‘liq retseptni boshidan oxirigacha ko‘rsataman.
Server sotib oldingiz, qo'lingizda root parol bor. Loyihani yuklashdan oldin qilinishi shart bo'lgan ishlar bor: alohida foydalanuvchi, SSH kalit, parolni o'chirish, firewall va swap. Shu birinchi soatni bosqichma-bosqich o'tamiz.
Serverni tushunish: ruxsatlar, reverse proxy, xizmat sifatida ishga tushirish.
Yangi serverga parol bilan kirib, bir necha soatdan keyin loglarga qarasangiz, dunyoning har burchagidan kelgan minglab urinishni ko‘rasiz. Nega SSH kalit paroldan xavfsizroq, chmod raqamlari nimani anglatadi va SSH kalitingizni nega ba'zan rad etadi.
Gunicorn 127.0.0.1'da ishlab turibdi, endi uni dunyoga chiqarish kerak. Nginx'ni reverse proxy qilib sozlaymiz: to'g'ri header'lar, statikani tez berish, WebSocket'ni o'tkazish va 502 chiqqanda qayerga qarashni bilish.
Har kuni ko‘ramiz, lekin kamdan-kam o‘ylaymiz: manzil qatoridagi qulf belgisi aslida nimani kafolatlaydi? TLS handshake, sertifikatlar va nega HTTPS shunchaki «shifrlash»dan ko‘ra kengroq narsa ekanini soddalab ko‘ramiz.
Sertifikat sotib olish shart emas — Let's Encrypt bepul beradi, certbot esa nginx'ni o'zi sozlab qo'yadi. Sertifikat olamiz, avtomatik yangilanishini timer bilan kafolatlaymiz va Django'ni HTTPS'ga to'g'ri o'tkazamiz.
Botni xizmat qilishni o'rgangan edik, endi web-ilova navbati. Gunicorn'li Django saytini systemd ostiga olamiz: bazaga bog'liqlik, graceful reload, xotira chegarasi va sandbox himoyalari — shu saytning o'zida ishlab turgan sozlamalar asosida.
Cron o'rniga systemd timer: loglari jurnal ichida, o'tkazib yuborilgan ishga tushishlarni quvib yetadi va sinash oson. Shu tool bilan bazani har kuni avtomatik zaxiralaymiz, eski nusxalarni tozalaymiz va eng muhimi — tiklashni ham sinaymiz.
Reboot vaqtini siz tanlamaysiz — kernel yangilanishi, provayder ishlari yoki oddiy elektr muammosi uni sizsiz qiladi. Serverni tekshirib chiqamiz: nimalar o'zi qaytadi, nimalar jim o'lib qoladi, va buni qanday oldindan bilish mumkin.
git push'dan production'gacha qo'l tegmasin.
Hozir o'qiyotgan maqolangiz serverga qo'lda yuklanmagan: men push qildim, GitHub Actions testlarni o'tkazdi, o'zi deploy qildi, hatto Telegram kanalga e'lonni ham o'zi yubordi. Shu pipeline'ni boshidan oxirigacha ochib beraman — real fayllar bilan.
Dasturchining shaxsiy sayti deyarli har doim React'da quriladi — bu bugungi standart. Men aksincha yo‘l tutdim: Django monolit, HTMX va git'da yashaydigan markdown fayllar. Nega shunday qilganimni va bu qaror nimaga asoslanganini aytib beraman.
Nosozlik chiqqanda to'g'ri savolni topish tezlikning o'zi.
Xizmat yiqilganda taxmin bilan emas, loglar bilan ishlanadi. journalctl'ning kundalik ishda kerak bo'ladigan qismini o'rganamiz: to'g'ri savol berish, vaqt bo'yicha toraytirish, yashirin restart-halqalarni ushlash va jurnal diskni yeb qo'ymasligini ta'minlash.
«Server yotdi» degan uch soatlik vahima aslida mintaqaviy internet-marshrut uzilishi bo‘lib chiqdi — server esa butun shu vaqt davomida sog‘ turgan edi. Bir noto‘g‘ri savol qanday qilib bir necha soatni yeb qo‘yishi va to‘g‘ri savol 30 soniyada javob berishi haqida.
Sekinlashgan API'ni tashxis qilish va tuzatish.
Lokalda uchib turgan sahifa serverda sudralib qoladi, chunki ORM har bir yozuv uchun bazaga alohida borib keladi. N+1 qanday tug‘iladi, uni qanday ushlash va select_related bilan prefetch_related orasidagi farq nimada.
Bir xil ma'lumot qayta-qayta bazadan so‘ralsa, uni Redis'da saqlab, bazani tinch qoldirsa bo‘ladi. Cache-aside naqshini yozamiz, TTL bilan tanishamiz va keshlashning eng qiyin qismi — invalidatsiyani o‘z misolimizda ko‘ramiz.
Bosh sahifadagi loyihalar soni bir kun ichida eskirib qotib qoldi — lokalda esa hammasi joyida. Sababi men bilib turib qazigan chuqur edi: xato natijani ham muvaffaqiyat bilan bir xil muddatga keshlab qo‘yganman. Tashxis va yechim.
Kod xavfsiz yozilishi — audit emas, odat bo'lishi kerak.
settings.py ichida parol saqlash — klassik xato, chunki u kod bilan birga git'ga, git bilan birga GitHub'ga tushadi. Sozlamalarni muhitga chiqaramiz, settings'ni dev va prod'ga bo‘lamiz va nega bu xavfsizlik masalasi ekanini ko‘ramiz.
GitHub'ga tushib qolgan bot tokeni bir necha daqiqada topiladi — buni skanerlash botlari tinimsiz qilib turadi. Sirlarni to'g'ri saqlash tartibini quramiz: .env fayllar, ruxsatlar, sizib chiqqandagi harakatlar rejasi va commit'dan oldingi himoya.
Baza sizib chiqsa, foydalanuvchilaringizning paroli hujumchi qo‘lida nima bo‘ladi? Bu parolni qanday saqlaganingizga bog‘liq. SHA-256 nega yaramasligini, salt nima berishini va Argon2 nega tanlanishini kod bilan ko‘ramiz.
Darsda JWT mavzusiga kelganimizda talabalarning ko‘pchiligi token shifrlangan deb o‘ylaydi. Aslida uning ichini istalgan odam ochib o‘qiydi. Shu farqdan kelib chiqadigan xatolar va ularning oldini olish yo‘llari.
Ochiq API'dan kimdir albatta haddan ortiq foydalanadi — bilib yoki bilmay. Token bucket g‘oyasini tushunamiz, Redis bilan ishlaydigan cheklovni yozamiz va uni terminaldan o‘zimiz sinab ko‘ramiz.
Eng qadimiy zaifliklardan biri, lekin hali ham ishlab turibdi. Kichik zaif ilova yozamiz, uni o‘zimiz buzamiz, keyin bitta o‘zgarish bilan yopamiz — hammasini o‘z kompyuteringizda takrorlab ko‘rasiz.
Web-xavfsizlikdagi eng nufuzli ro‘yxatni quruq ta'riflar bilan emas, har biri qanday ko‘rinishda uchrashi va nima bilan yopilishi tomonidan ko‘rib chiqamiz. Eng ko‘p uchraydigan zaiflikni esa kod bilan ochib beraman.
