Tayyor servislar emas, avval o‘zim qurib ko‘raman

Men bir narsaga tobora ko‘proq ishonib boryapman:

Biror servisdan foydalanishdan oldin, hech bo‘lmaganda uning core mantiqi qanday ishlashini o‘zim qurib ko‘rishim kerak.

Bu “hamma narsani noldan yozaman” degani emas.

Aksincha, production’da tayyor va ishonchli servislar juda katta vaqtni tejaydi. Lekin men uchun ishlatish bilan tushunish ikki xil narsa.

Masalan, Supabase juda yaxshi platforma. Authentication, PostgreSQL, Storage, Realtime va boshqa ko‘plab imkoniyatlarni tayyor holda beradi. Lekin oddiy loyiha uchun ham darrov Supabase ishlatishdan ko‘ra, ba'zan o‘z VPS'imda PostgreSQL ko‘tarib, database bilan o‘zim ishlashni afzal ko‘raman.

Nega?

Chunki men PostgreSQL'ni shunchaki “database service” sifatida emas, database qanday ishlashini tushunish uchun ishlatmoqchiman.

CDN bor. Lekin CDN qanday ishlashini ham bilish kerak.

CDN ishlatish — albatta yaxshi.

Security yaxshi bo‘lishi mumkin. DDoS protection bor. Caching bor. Global edge serverlar bor.

Lekin men uchun savol boshqa:

CDN requestni qanday qabul qiladi?

Cache qachon ishlaydi?

Origin serverga qachon boradi?

Cache invalidation qanday ishlaydi?

TLS qayerda terminate bo‘ladi?

Reverse proxy nima qiladi?

Mana shu narsalarni tushunish men uchun servis nomini bilishdan ko‘ra qiziqroq.

Shuning uchun ba'zida oddiy VPS + Nginx + application server bilan hammasini o‘zim yig‘ib ko‘raman.

Keyin kerak bo‘lsa Cloudflare yoki boshqa CDN'ni qo‘shaman.

Endi men CDN ishlatayotganimda, u men uchun “magic” bo‘lmaydi.

Men uning ortida nima bo‘layotganini taxminan bilaman.

Authentication ham xuddi shunday.

Tayyor authentication servisidan foydalanish juda qulay.

Bir necha configuration.

OAuth.

JWT.

Session.

Refresh token.

Va tayyor.

Lekin authentication tizimini hech bo‘lmaganda bir marta o‘zim qurib ko‘rmasam, men uchun ko‘p narsalar abstraksiya bo‘lib qoladi.

Masalan:

  • password qanday hash qilinadi?
  • session qanday saqlanadi?
  • access token nima?
  • refresh token nima?
  • token rotation nima?
  • cookie qanday ishlaydi?
  • CSRF nimaga kerak?
  • OAuth flow'da nima sodir bo‘ladi?
  • authorization va authentication o‘rtasidagi farq nima?
  • permission qayerda tekshiriladi?

Bularni tushunib olgandan keyin tayyor Auth service ishlatish boshqa darajadagi qarorga aylanadi.

Men endi shunchaki:

“Bu servis authentication qiladi.”

demayman.

Men:

“Men authentication qanday ishlashini bilaman, shu sababli bu qismini production'da tayyor servisga topshirishim mumkin.”

deyman.

Queue ham xuddi shunday.

RabbitMQ yoki Kafka ishlatishdan oldin oddiy queue'ni o‘zim implement qilib ko‘rish juda foydali.

Producer.

Consumer.

Message.

Acknowledgement.

Retry.

Dead letter.

Ordering.

Concurrency.

Backpressure.

Shularni tushunib olgandan keyin RabbitMQ ishlatish ancha tushunarli bo‘ladi.

Aks holda infrastructure'da biror muammo chiqsa:

“RabbitMQ ishlamayapti.”

degan joyda qolib ketish mumkin.

Lekin core mantiqni bilsangiz:

“Message broker'da consumer acknowledgement bo‘lmagan, shu sababli message qayta delivery bo‘lyapti.”

degan darajada fikrlay boshlaysiz.

Bu esa butunlay boshqa skill.

Men hamma narsani o‘zim yozaman deganim yo‘q.

Bu juda muhim.

Production'da g‘ildirakni qayta ixtiro qilish har doim ham yaxshi qaror emas.

Men o‘zim payment gateway yozib, keyin bank infratuzilmasini noldan qurishga urinmayman.

Men o‘zim database engine yozib, production database sifatida ishlatmayman.

Men o‘zim cryptography algorithm yozib, real user passwordlarini unga ishonib topshirmayman.

Men o‘zim CDN yozib, butun production traffic'ni unga tashlab qo‘ymayman.

Bu boshqa masala.

Men aytayotgan narsa:

Avval tushunish. Keyin abstraction'dan foydalanish.

“Build → Understand → Use”

Men uchun yaxshi workflow taxminan shunday:

1. Build

Oddiy versiyasini o‘zim quraman.

2. Break

Uni buzishga harakat qilaman.

3. Understand

Nima sababdan buzilganini tushunaman.

4. Compare

Keyin production-grade yechimlar qanday qilganini ko‘raman.

5. Use

Kerak bo‘lsa tayyor servisdan foydalanaman.

Shunda abstraction menga qarshi emas, men uchun ishlaydi.

VPS'dagi PostgreSQL ham men uchun shuning uchun qiziq.

Supabase'dan foydalanish noto‘g‘ri emas.

Aksincha, ko‘p hollarda bu juda yaxshi engineering decision bo‘lishi mumkin.

Lekin men o‘z VPS'imda PostgreSQL ko‘tarib ko‘rishni yaxshi ko‘raman.

Database.

Backup.

Restore.

Connection pooling.

Migration.

Replication.

Monitoring.

Disk usage.

Memory.

CPU.

Logs.

Networking.

Security.

Bularning barchasi bilan o‘zingiz ishlaganingizda infrastructure boshqa ko‘z bilan ko‘rina boshlaydi.

Keyin managed PostgreSQL'ga o‘tsangiz ham:

“Men buni tushunmayman, provider hal qiladi.”

emas,

“Men buni tushunaman, provider menga operational burden'ni olib tashlayapti.”

degan fikr paydo bo‘ladi.

Bu juda katta farq.

Menimcha, developer uchun eng xavfli narsa — “magic”.

Framework magic.

Cloud magic.

Database magic.

Authentication magic.

Deployment magic.

Networking magic.

Agar hamma narsani:

“Shuni install qilamiz, ishlaydi.”

darajasida bilsak, bir kun kelib tizim ishlamay qolganida nima bo‘layotganini tushunish qiyinlashadi.

Shuning uchun men imkon qadar core mantiqni bir marta bo‘lsa ham o‘zim qurib ko‘rishga harakat qilaman.

Keyin tayyor servisdan foydalanishdan qo‘rqmayman.

Chunki men servisga bog‘lanib qolmayman.

Men konseptga ega bo‘laman.

Oxirida

Mening maqsadim:

“Hamma narsani o‘zim yozaman.” emas.

Mening maqsadim:

“Hamma narsaning qanday ishlashini tushunishga harakat qilaman.”

Tayyor servislar — vaqtni tejaydi.

Lekin o‘zingiz qurib ko‘rish — bilim beradi.

Shuning uchun men uchun eng yaxshi kombinatsiya:

Learn by building.
Understand the core.
Then use the abstraction.

Chunki biror narsani ishlata olish — skill.

Uni kerak bo‘lsa o‘zingiz qurib ko‘rgan bo‘lish esa — boshqa darajadagi tushunish.