Redis in-memory database bo'lgani uchun, juda tezkor va asinxron ishlay oladi. Odatda, caching yoki async messanging(xuddi biz hozir yozishib turgan telegram chat) uchun ishlatiladi. Bir kishi yozgan xabar parallel ravishda qolganlarga ham yetib boradi, yangilash shart emas.

Celery esa message queue uchun ishlatiladi(lekin ishlatib ko'rmaganman). Ya'ni guruhda hozir birdaniga 50 kishi yozsa, ularni tartib bilan handle qilish uchun.

Bir narsani tushuning, hozir men u kishining muammosini yechim berganim bilan, uning ildizi o'z holicha qoladi. Ertaga rekursiyaga bog'liq yana biror error chiqqanda, yana yordam so'rashga majbur bo'ladi.
Maqsadim, xatoni qanday tuzatishni emas, u qayerdan kelganini ko'rsatish. Shunda keyingi safar o'zi muammoni topa oladi.
Agar qarmoq bo'lmasa baliqlar albatta bir kun tugaydi.

Bo'ldi, ortiq flood qilmoqchi emasman. Fikringizni hurmat qilaman.

Yana bir maslahat, dynamic urlpattern bilan ishlaganda ehtiyot bo'ling. Iloji bo'lsa, static pathdan keyin ishlating. Tartibda ham static urllarni birinchi qo'yganingiz yaxshi.
'',
'detail/<int:pk>/',
'results/<int:pk>',

shaklida. Bo'lmasa, so'rov yuborgan url'ingiz aytgan manzilingizga yetib bormasidan boshqa dynamic urlpatternga "tiqilib" qolishi mumkin.

Authentication uchun biror unique, ya'ni butun table bo'yicha takrorlanmaydigan column kerak bo'ladi. Umuman olganda har bir userning takrorlanmas id'si bor, lekin bu userning o'zi uchun eslab qoishga noqulay va sensitive data hisoblanadi(kimdir shu joyini noto'g'ri deyishi mumkin).
Shuning uchun birorta unique column qo'yish kerak. Bu turli xil: email, username, telefon raqam va hokazo bo'lishi mumkin.
Django default User modelida auth uchun username ishlatilgan. Agar boshqa biror narsadan foydalanib auth qilmoqchi bo'lsangiz, custom User model yozsangiz bo'ladi.

Function-based viewlarda renderga context dicrionary o'tkazasiz. Bu dictionary backenddan templatega jo'natiladigan hamma datani ichiga oladi.
Class-based(generic) viewlarda bu ishni get_context_data() methodi bajaradi. Default holda bu yerda faqat get_queryset() methodi qaytargan queryset bo'ladi. Qo'shimcha context qo'shish uchun methodni override qilish kerak:

posts = Post.objects.all()
authors = Author.objects.all()

def get_context_data(self, **kwargs):
context = super().get_context_data(**kwargs)
context["authors"] = authors
context["posts"] = posts
return context

Templateda {{posts}}, {{authors}} ko'rinishida ishlataverasiz.

ManyToMany relationship aslida databaseda simmetrik bo'lsa-da, yordamchi tableni djangoning o'zi tuzgani uchun biz faqat bir tarafdan reference qilamiz. Shuning uchun, ikkinchi model bu relationshipdan "bexabar" bo'ladi. Shuning uchun admin panelda ko'rinmaydi.

InlineModelAdmin orqali siz aytgan natijani olish mumkin, lekin bu unchalik yaxshi fikr emas deb o'ylayapman.
Yaxshisi, ModelAdminga filter qo'ying. Shunda, narigi model orqali "aylanib" kirishga hojat qolmaydi.

Birorta rich editor ishlatib ko'ring.

Agar manual markdown qilmoqchi bo'lsangiz(ya'ni html taglarni o'zingiz yozib) buning ham iloji bor.
https://docs.djangoproject.com/en/3.2/ref/templates/builtins/#safe
Mana buni qarab ko'ring.
Lekin buni ishlatishda ehtiyot bo'lishni tavsiya qilaman. Bu xavfsizlik bo'yicha bir qancha muammolar(masalan, XSS attack)ni keltirib chiqarishi mumkin.

Bu form adashmasam, registration uchun.
Va bilishimcha, TemplateViewdan inherit qilgansiz.
TemplateView faqat GET requestga javob beradi.
Yaxshisi, boshlanishiga function-based viewdan boshlang. Nima sodir bo'layotganini yaxshiroq tushunasiz. Yangi boshlaganda muhimi murakkab narsalar qilish emas, nima qilayotganingizni, kodingiz aslida qanday ishlayotganini tushunish.
Keyinchalik class basedga o'tsangiz bo'laveradi.

Form orqali modelga field qo'shib bo'lmaydi.
Formni xuddi qutidek tasavvur qilishingiz mumkin:
Siz uni templatega bo'sh holda chiqarasiz. User esa unga ma'lumot kirgizib, yana o'zingizga qaytarib beradi.

Djangoda ikki xil form bor: Form va ModelForm.

Form bu shunchaki oddiygina 'quti'. Unga xohlagancha field kiritasiz va xohlagan ma'lumotingizni olasiz.
Bu faqat ma'lumot o'tkazish uchun. Bu yerda Modelga aloqador narsa yo'q.

ModelForm esa eng ko'p ishlatiladigan kodlarni kamaytirish uchun ishlab chiqilgan.
Ya'ni siz har bir fieldni qo'lda kiritib chiqish o'rniga faqat bir modeldagi fieldlardan qaysilarini "quti"ga chiqarishni tanlaysiz.
Natijada, bu form faqat sizdagi modelga mos ma'lumot qabul qiladi.

Bu offtopic bo'lsa ham vijdonim qiynalgani uchun yozayapman.

Eng avval sizga ba'zi savollarni bermoqchiman:

Aynan nega sizga Professionali kerak?
Community version sizning talablaringizga javob bermayaptimi?
Nega boshqa tekin editorlardan foydalanmaysiz?
Nega Professionalni pullik qilib qo'yishgan?

Javoblar katta ehtimol bilan ko'pchilikda o'xshash bo'ladi:
Bu narsa bizga "ODAT" bo'lib qolgan.
Hamma joyda crack version.
Copyright oyoq osti bo'lib bo'lgan.
Yana kamiga crack versiyani chiqarish, uni ishlatishdan faxrlanishadi. Tan olasizmi yoki yo'q, biz, O'zbeklar mana shunday "O'ZBEKCHILIK"larni odat qilganmiz.

Sotib olishga pulim yo'q deysizmi?
Bilasizmi kim ferrari minadi?
Ferrari sotib olishga puli va xohishi bor odam. Agar puli yetmasa sekin boshqa variantlarni ko'radi.

Sizga ham tavsiyam shu. Xohlasangiz narxiga sotib oling.
Sotib olmasangiz o'sha "luxury class" versiondan hozircha voz kechib, oddiyroq biror narsa ishlatib turing.

P.S. Tepadagi gaplarim ba'zilarga shunchaki yetib bormaydi. Kimdir menga aql o'rgatishni ham boshlashi mumkin.
Shunchaki odam bo'laylik. Ertaga kattaroq loyiha ishlab chiqqan vaqtingiz xuddi shu narsa sizning boshingizga tushmasin.
Vijdonni ham ishlatib turaylik...

Hammaga salom. Pythonni bilmaydiganlarga yordam berishinglar yaxshi, ammo tanganing ikkinchi tarafini ham hisobga olsanglar yomon bo'lmasdi. Hozir siz yordam berayotgan(student)lar aslida shu narsani vaqtida o'rganishi kerak edi(Universitetga kirishdan maqsad nima?). Hozir sizning "sharofatingiz" bilan imtihondan o'tishyapti. Ular xursand, siz xursand, ularning kelajagi esa ... Ertaga 4 yil vaqtini bekorga sarflab, universitetdan diplom bilan chiqishadi, bilim esa yo'q.
Siz ham qaysidir ma'noda ularga vaqtini isrof qilish va o'z-o'zini aldashda ko'maklashayapsiz. Sababi, agar ular bugun o'ta olmasa, ertaga o'zlari o'rganishadi.
Yordam berayapman deb o'ylab, aslida ularning ziyoniga ishlamang, azizlar. Qolgani vijdoningizga havola.

Agar siz biror loyiha ustida yillab ishlasangiz-u, uni bittasi chiqib tekinga tarqatsa sizga yoqqan bo'larmidi? Pro versiyani tekinga tarqatish yoki umuman, tekinini topishga urinishdan oldin o'ylab ko'ring, shu ishingiz to'g'rimi?
Dinimiz bu ishingizni ma'qullaydimi yoki vijdoningiz?
Muallif mehnati va mualliflik huquqini hurmat qiling.

Sababi, tepadagi gapning ma'nosini hamma tushuna olmaydi. Kimdir uchun bu gaplar shunchaki safsata. Agar sizga tushuntira olgan bo'lsam, bundan xursandman. Hamma qilayapti degani bu ish to'g'riligini anglatmaydi.

Python interpreted language va user uchun juda qulaylashgan. User uchun qulay bo'lishi uchun qiyinchiliklarning asosiy qismi komputerga yuklanadi. Mana shu faktorlar asosiy kamchiliklarga sabab bo'ladi. Tezlik pastligi, grafiklar bilan ishlashda noqulaylik va hokazo.

OneToOneField bir model objectini boshqa bir modelning biror objectiga bog'lash uchun ishlatiladi.
Bizning holda UserDetail objectini User objectiga bog'lash uchun ishlatilgan. Ya'ni Har bir UserDetail objecti aynan bitta User objectiga tegishli. Aynan qaysi object ekanligini ko'rsatish uchun biz user=user yozdik. Bu yerdagi birinchi user UserDetail modelidagi user fieldi. Ikkinchi(tenglikdan keyingi) user esa biz hozirgina yaratgan User objecti.

1) Python bilan NodeJSni taqqoslashning iloji yo'q, biri dasturlash tili, ikkinchisi framework.

2) Django va NodeJSni nazarda tutgan bo'lishingiz mumkin. NodeJSda ishlab ko'rmaganman, qulayliklari haqida ko'p ma'lumot bilmayman.
Djangoning eng katta kuchi bu "batteries included" xususiyatida. Ya'ni web application development jarayonida kerak bo'ladigan deyarli barcha tools ichida bor. Yana bir muhim jihati, o'sha har bir xususiyatni o'zingizga moslashingiz, qayta yozishingiz va hatto o'chirib tashlashingiz mumkin. Ya'ni Djangoni maksimal darajada o'zingizga kerakli tarzda moslashtira olasiz.

3) Bu Python community. Bu yerdan Python bilan NodeJSni taqqoslashni so'rash xuddi C++ guruhda "Python juda zo'r, to'g'rimi?" deb so'rashga o'xshaydi.

Yana bir gap. Bu majburiy emas va umuman, shart ham emas. Dasturchi sifatida mualliflik huquqini hurmat qiling. Siz qandaydir tricky usullar bilan ishlatayotgan, aslida pullik dastur ustida ko'plab odam oylar mobaynida ishlagan. Xudo xohlasa, kelajakda real proyektlar qilganingizda, oylab qilgan mehnatingizni kimdir shunchaki "uxlatsa" sizga yoqqan bo'larmidi?
Xulosa qiling.
Nimanidir yaxshi tomonga o'zgartirmoqchimisiz, unda o'zingizdan boshlang.
P.S. bular qoida emas, shaxsiy fikrlarim.

Slug bu asosan, url tarkibida ishlatishga qulay field.
Masalan, bitta postga id orqali link bersangiz, /posts/id=12/ kabi bo'ladi.
Slug buni ancha yaxshi ko'rinishga keltiradi: postdan biror bir qismi(masalan, title)ni olishingiz mumkin. Masalan,
/posts/what-is-django/ kabi.
Birinchidan, url tushunarliroq bo'lsa, ikkinchidan, SEOga osonroq bo'ladi.

while o'zidan keyin shart va o'z blokida kod oladi:

while shart:
kod
kod
...

kabi.
Shart rost qiymat qabul qilsa, sikl aylanaveradi. Yolg'on qiymat qabul qilgan zahoti to'xtaydi.
Masalan,

son = 1
while son <= 3:
print(son)
son += 1

kodning natijasi
1
2
3
Bo'lib chiqadi. Sababi, har safar siklda son chiqarilib, uning qiymatiga 1 qo'shilayapti.
Bu narsa 1, 2 va 3 uchun bo'ladi.
undan keyin son = 4 bo'ladi.
Unda shart bajarilmagani uchun sikl to'xtaydi.