راهنمای کامل Django برای بکاند
چرا جنگو در میان فریمورکهای بکاند پایتون، هنوز انتخاب اصلی پروژههای جدی است و چطور میتوانید از صفر تا استقرار، یک اپلیکیشن واقعی با آن بسازید؟
اولین پروژه جدی که با جنگو ساختم، یک سامانه رزرو آنلاین بود. سه ماه طول کشید تا به نسخه اول برسد، اما در ماه چهارم، وقتی مشتری خواست چند قابلیت جدید اضافه شود، تفاوت جنگو با دیگر فریمورکها را حس کردم: قابلیتهای جدید در چند روز اضافه شدند، نه چند هفته. آن پروژه، دلیل روشنی به من داد که چرا جنگو (Django) بعد از اینهمه سال، هنوز انتخاب اصلی پروژههای جدی است: نه فقط ابزار ساخت سریع، بلکه بستری برای رشد پایدار و نگهداری بلندمدت.
جنگو چیست و چرا هنوز انتخاب اصلی است؟
جنگو (Django) یک فریمورک وب پایتونی است که با فلسفه «باتریها همراه» (Batteries Included) ساخته شده: بخشهای اصلی یک اپلیکیشن وب — از دیتابیس و احراز هویت تا پنل مدیریت و امنیت — از پیش در خودش دارد. تفاوت اصلی جنگو با فریمورکهای سبک (مثل Flask) در همین است: جنگو مسیر ساخت را کوتاهتر میکند، در حالی که Flask آزادی و مسئولیت بیشتر میدهد.
سه دلیل که پس از سالها کار با فریمورکهای مختلف، جنگو را در صدر انتخابهایم نگه داشته است:
- پنل مدیریت آماده: این ویژگی یکی از بزرگترین مزیتهای جنگو است. برای اکثر پروژهها، نیازی به ساخت پنل مدیریت از صفر نیست. این صرفهجویی میتواند معادل هفتهها کار تیم باشد.
- امنیت پیشفرض: جنگو بهطور پیشفرض در برابر تهدیدهای رایج مثل SQL Injection، CSRF، XSS و Clickjacking حفاظت میکند. توضیح دقیق این تهدیدها در امنیت وب چیست و چه اصولی دارد آمده است.
- کامنیتی بالغ و مستندات عالی: مستندات رسمی جنگو از بهترین مستندات فریمورکهای وب محسوب میشود. اگر به یک مشکل نادر بربخورید، احتمالاً کسی قبلاً حلش کرده و راهحلش در گیتهاب یا Stack Overflow هست.
اگر با پایتون آشنایی کافی ندارید، پیشنهاد میکنم قبل از ادامه، آموزش پایتون از صفر را بخوانید. اگر میخواهید تصویر کلی بکاند را در ذهن بسازید، بکاند چیست و چه وظایفی دارد نقطه شروع خوبی است.
در انتخاب بین جنگو و Flask، پاسخ درست همیشه یکی نیست. اما اگر پروژه شما به پنل مدیریت، احراز هویت و امنیت قوی نیاز دارد، جنگو معمولاً مسیر کوتاهتری است.
نصب و راهاندازی پروژه جنگو
پیش از هر کاری، محیط مجازی بسازید تا وابستگیهای پروژه جداگانه مدیریت شوند:
python -m venv venv
source venv/bin/activate # Linux/Mac
# venv\Scripts\activate # Windows
pip install django
سپس پروژه را بسازید:
django-admin startproject myproject
cd myproject
python manage.py startapp core
نکتهای که در پروژهها به آن پایبندم: از همان ابتدا فایل requirements.txt بسازید تا وابستگیها قابل بازتولید باشند:
pip freeze > requirements.txt
در نهایت، اولین مهاجرتها را اعمال کنید و سرور توسعه را اجرا کنید:
python manage.py migrate
python manage.py runserver
ساختار پروژه و اپلیکیشنها در جنگو
جنگو از یک مفهوم کلیدی استفاده میکند: پروژه (Project) و اپلیکیشن (App). پروژه، شامل تنظیمات کلی است و اپلیکیشنها، ماژولهای تخصصی که هرکدام یک دامنه از پروژه را پوشش میدهند. ساختار توصیهشده من:
myproject/
├── myproject/
│ ├── settings/
│ │ ├── base.py
│ │ ├── dev.py
│ │ └── production.py
│ ├── urls.py
│ └── wsgi.py
├── apps/
│ ├── users/
│ ├── products/
│ └── orders/
├── static/
├── media/
├── templates/
├── manage.py
└── requirements.txt
سه اصل در سازماندهی پروژه:
- جداسازی تنظیمات بر اساس محیط: یک
settings/base.py، یکsettings/dev.pyو یکsettings/production.py. این رویکرد، جلوی اشتباهات پرهزینه را میگیرد. - یک اپلیکیشن، یک دامنه: هر اپلیکیشن باید دقیقاً یک حوزه از پروژه را پوشش دهد. اپلیکیشنهای چاق، منبع بیپایان مشکل هستند.
- جدا کردن پوشههای عمومی: پوشههای
staticوmediaرا بیرون از کد قرار دهید تا مدیریتشان سادهتر باشد.
مدلها؛ قلب پایگاه داده در جنگو
مدلها در جنگو، لایه انتزاعی بین کد و دیتابیس هستند. با مدلها، بهجای نوشتن SQL دستی، با کلاسهای پایتون کار میکنید و ORM (Object-Relational Mapping — نگاشت شیء-رابطهای) کوئریها را میسازد:
from django.db import models
class Product(models.Model):
name = models.CharField(max_length=200)
slug = models.SlugField(unique=True)
price = models.DecimalField(max_digits=10, decimal_places=2)
description = models.TextField(blank=True)
created_at = models.DateTimeField(auto_now_add=True)
def __str__(self):
return self.name
چند نکته از تجربهام:
- slug برای URL: هر مدلی که URL عمومی دارد، باید یک slug داشته باشد.
- created_at و updated_at: این دو فیلد در هر مدلی که با داده کاربر کار میکند، ضروری هستند.
- متد __str__: همیشه تعریف کنید. بدون آن، در پنل مدیریت با اشیای بینام روبهرو میشوید.
مهاجرتها؛ مدیریت تغییرات دیتابیس
جنگو با سیستم مهاجرت، تغییرات مدلها را بهطور خودکار به دیتابیس اعمال میکند:
python manage.py makemigrations
python manage.py migrate
سه قاعده در مدیریت مهاجرتها:
- هر مهاجرت را بازبینی کنید: قبل از اجرای
migrate، فایل مهاجرت را بخوانید تا از عملیات منطقی مطمئن شوید. - در پروژههای زنده، مهاجرتهای پیچیده را با دقت اجرا کنید: حذف ستون در جدول بزرگ، میتواند ساعتها طول بکشد. پیش از اعمال، روی محیط ایزوله تست کنید.
- بکاپ دیتابیس پیش از مهاجرت: همیشه بکاپ داشته باشید، حتی اگر مهاجرت بهنظر ساده است.
ویوها و URL؛ منطق درخواست و پاسخ
ویوها در جنگو، منطق پردازش درخواست هستند. دو نوع ویو وجود دارد: تابعی (FBV — Function-Based View) و کلاسی (CBV — Class-Based View). نمونه یک ویو تابعی:
from django.shortcuts import render, get_object_or_404
from .models import Product
def product_detail(request, slug):
product = get_object_or_404(Product, slug=slug)
return render(request, 'products/detail.html', {'product': product})
و نمونهای از یک ویو کلاسی:
from django.views.generic import DetailView
from .models import Product
class ProductDetailView(DetailView):
model = Product
template_name = 'products/detail.html'
context_object_name = 'product'
کدام بهتر است؟ تجربهام نشان داده در پروژههای ساده و مشخص، ویو تابعی خواناتر است. در پروژههای با ساختار پیچیده و تکرار زیاد، ویو کلاسی کد را کاهش میدهد. قاعده ساده: وقتی شک دارید، با FBV شروع کنید و اگر تکرار دیدید، به CBV منتقل کنید.
قالبها؛ نمایش داده در جنگو
جنگو از یک زبان قالب اختصاصی استفاده میکند که ساده و امن است. نمونه:
<h1>{{ product.name }}</h1>
<p>قیمت: {{ product.price }} تومان</p>
{% if product.description %}
<p>{{ product.description }}</p>
{% endif %}
نکته مهم: زبان قالب جنگو بهطور پیشفرض همه متغیرها را escape میکند تا از XSS جلوگیری شود. اگر نیاز به خروجی خام HTML دارید، از فیلتر |safe استفاده کنید، اما این کار را فقط با محتوای معتمد انجام دهید.
در پروژههای واقعی، بهجای تکیه بر قالبهای پیچیده، سادگی را ترجیح میدهم. اگر قالب شما بیش از چند لایه تودرتو دارد، احتمالاً بخشی از منطق باید در ویو یا template tag جدا شود.
فرمها و اعتبارسنجی ورودی
فرمها در جنگو، لایه اصلی اعتبارسنجی ورودی هستند. تعریف یک فرم ساده:
from django import forms
class ContactForm(forms.Form):
name = forms.CharField(max_length=100)
email = forms.EmailField()
message = forms.CharField(widget=forms.Textarea)
def clean_message(self):
message = self.cleaned_data['message']
if len(message) < 20:
raise forms.ValidationError('پیام باید حداقل ۲۰ کاراکتر باشد')
return message
سه نکته در مورد فرمها:
- همیشه از فرمها استفاده کنید، نه اعتبارسنجی دستی: فرمها امنیت و اعتبارسنجی را یکجا میدهند.
- ModelForm برای فرمهای متصل به مدل: اگر فرم شما داده را در یک مدل ذخیره میکند، از
ModelFormاستفاده کنید تا کد کمتری بنویسید. - CSRF Token فراموش نشود: در قالبها، حتماً
{% csrf_token %}را درج کنید. بدون آن، فرم شما در محیط تولید رد میشود.
پنل مدیریت جنگو؛ ابزار مخفی بهرهوری
پنل مدیریت یکی از ویژگیهای پرکاربرد جنگو است که بهطور پیشفرض در دسترس قرار میگیرد. با چند خط کد، میتوانید مدلهای خود را در پنل مدیریت تعریف کنید:
from django.contrib import admin
from .models import Product
@admin.register(Product)
class ProductAdmin(admin.ModelAdmin):
list_display = ('name', 'price', 'created_at')
list_filter = ('created_at',)
search_fields = ('name', 'description')
prepopulated_fields = {'slug': ('name',)}
در پروژههای واقعی، سفارشیسازی پنل ادمین میتواند ساعتها کار تیم را صرفهجویی کند. تیم محتوا یا فروش میتواند بدون نیاز به توسعهدهنده، محصولات یا دادهها را مدیریت کند.
احراز هویت و مدیریت کاربران
جنگو یک سیستم احراز هویت کامل دارد که از ابتدا شامل ثبتنام، ورود، بازیابی رمز عبور و مدیریت نقشهاست. نمونه استفاده در ویو:
from django.contrib.auth.decorators import login_required
@login_required
def dashboard(request):
return render(request, 'dashboard.html')
برای نقشها و دسترسیهای پیچیدهتر، جنگو امکان تعریف گروهها و مجوزهای سفارشی را میدهد. اگر تازه با این مفاهیم آشنا میشوید، احراز هویت چیست و چه انواعی دارد نقطه شروع خوبی است. برای 2FA و امنیت بیشتر، احراز هویت دو مرحلهای چگونه امنیت را افزایش میدهد را ببینید.
امنیت در جنگو؛ دفاع پیشفرض
جنگو بهطور پیشفرض در برابر چند تهدید رایج محافظت میکند:
- SQL Injection: با ORM، کوئریها بهطور خودکار پارامتری میشوند.
- CSRF: با middleware توکن CSRF فعال است و برای همه فرمها الزامی است.
- XSS: قالبها بهطور پیشفرض همه متغیرها را escape میکنند.
- Clickjacking: با middleware
X-Frame-Optionsجلوگیری میشود. - Password Hashing: رمزها با الگوریتم امن هش میشوند، نه با MD5 یا SHA1.
با این حال، امنیت جنگو فقط با پیشفرضها کامل نمیشود. سه اقدام اضافه که در همه پروژهها اجرا میکنم:
- فعالسازی HTTPS اجباری: با تنظیم
SECURE_SSL_REDIRECT = True. - پیکربندی HSTS: با
SECURE_HSTS_SECONDSمقدار مناسب. - مدیریت کلید SECRET_KEY: این کلید هرگز نباید در مخزن کد قرار بگیرد و در محیط تولید باید از متغیر محیطی خوانده شود.
مبانی امنیت وب را در بهترین روشهای امنیت وب کدامند و تهدیدهای خاص را در SQL Injection چیست و چگونه جلوگیری کنیم و CSRF چیست و چگونه از آن جلوگیری کنیم باز کردهام.
ساخت API با Django REST Framework
در پروژههای مدرن، تقریباً همیشه نیاز به API دارید. Django REST Framework یا DRF، استاندارد غیررسمی این کار در اکوسیستم جنگو است. نمونه یک Serializer و ViewSet:
from rest_framework import serializers, viewsets
from .models import Product
class ProductSerializer(serializers.ModelSerializer):
class Meta:
model = Product
fields = '__all__'
class ProductViewSet(viewsets.ModelViewSet):
queryset = Product.objects.all()
serializer_class = ProductSerializer
DRF امکانات زیادی مثل احراز هویت، محدودسازی نرخ، مستندسازی خودکار و پشتیبانی از نسخهبندی API را بهطور بومی دارد. اصول طراحی API را در اصول طراحی REST API و احراز هویت را در احراز هویت در REST API آوردهام.
استقرار پروژه جنگو در محیط تولید
استقرار جنگو در محیط تولید، چند مرحله کلیدی دارد:
- جدا کردن تنظیمات محیط تولید:
DEBUG = FalseوALLOWED_HOSTSرا درست تنظیم کنید. - استفاده از سرور WSGI: گزینههای رایج: Gunicorn، uWSGI یا ASGI با Daphne/Uvicorn.
- پیکربندی سرور وب: معمولاً Nginx بهعنوان پروکسی معکوس جلو Gunicorn.
- سرویس فایلهای استاتیک: با
collectstaticو سرویسدهی توسط Nginx یا یک CDN. - مدیریت دیتابیس: در محیط تولید، PostgreSQL یا MySQL با پیکربندی مناسب.
- پایش و لاگ: ابزارهایی مثل Sentry و ابزارهای لاگ ساختاریافته برای رصد خطاها.
نمونه تنظیمات Nginx برای پروژه جنگو:
server {
listen 80;
server_name example.com;
location /static/ {
alias /path/to/staticfiles/;
}
location / {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
برای استقرار در محیطهای ابری یا Docker، بررسی Docker و پیادهسازی CI/CD راهنماهای عملی خوبی هستند، حتی اگر مخصوص وردپرس نوشته شده باشند، اصول یکسان است.
در پروژههای جنگو، استقرار یکی از نقاطی است که تفاوت بین پروژههای آماتور و حرفهای را آشکار میکند. تنظیمات محیط تولید، باید از روز اول طراحی و مستند شوند.
جدول خلاصه؛ نقش هر بخش در پروژه جنگو
| بخش | نقش | ابزار یا مفهوم کلیدی |
|---|---|---|
| مدلها (Models) | نمایش دیتابیس با کلاسهای پایتون | ORM، Migration |
| ویوها (Views) | منطق درخواست و پاسخ | FBV، CBV، Generic Views |
| قالبها (Templates) | نمایش داده به کاربر | DTL، Template Tags |
| فرمها (Forms) | اعتبارسنجی ورودی | Form، ModelForm |
| ادمین | پنل مدیریت خودکار | admin.ModelAdmin |
| احراز هویت | مدیریت کاربران و دسترسیها | django.contrib.auth |
| API | ارتباط با فرانتاند یا اپلیکیشن دیگر | Django REST Framework |
| استقرار | اجرا در محیط تولید | Gunicorn، Nginx، PostgreSQL |
اشتباهات رایج در پروژههای جنگو
- DEBUG=True در محیط تولید: بزرگترین اشتباه امنیتی. این حالت، جزئیات داخلی را فاش میکند و میتواند فاجعهبار باشد.
- نگهداری SECRET_KEY در مخزن کد: کلید امنیتی جنگو باید از متغیر محیطی خوانده شود، نه در فایل تنظیمات هاردکد شود.
- نادیده گرفتن مهاجرتها: تغییر مدلها بدون اجرای
makemigrationsباعث ناهماهنگی بین کد و دیتابیس میشود. - کوئریهای ناکارآمد: استفاده از حلقه برای دسترسی به روابط، میتواند منجر به مشکل
N+1 Queryشود. راهحل:select_relatedوprefetch_related. - استفاده از
|safeبدون ملاحظه: این فیلتر، از XSS جلوگیری نمیکند. فقط برای محتوای معتمد و تولیدشده در سمت سرور استفاده کنید. - نادیده گرفتن تست: تستنوشتن در جنگو بسیار ساده است اما بسیاری از پروژهها از آن چشمپوشی میکنند. در بلندمدت، همین پروژهها شکننده میشوند.
- مخلوط کردن منطق در ویو: ویوها باید نازک باشند و منطق در سرویسها یا مدلها. در غیر این صورت، کد بهسرعت غیرقابل نگهداری میشود.
- استفاده نکردن از پنل ادمین: یکی از مزیتهای اصلی جنگو، همین پنل است. اگر برای مدیریت داده از ساخت دستی پنل استفاده میکنید، یکی از مزیتهای اصلی جنگو را نادیده گرفتهاید.
نگاه معماری: جنگو بهعنوان بستر سیستمهای سازمانی
برای معماران پلتفرم و تیمهای فنی، جنگو نباید فقط بهعنوان یک فریمورک وب دیده شود؛ بلکه یک بستر معماری برای سیستمهای سازمانی است. چهار الگو که در پروژههای بزرگ جنگو به آن پایبندم:
- جداسازی لایهای (
Layered Architecture): در پروژههای بزرگ، جنگو را در چند لایه سازمان میدهم: لایه ارائه (Views، Templates، API)، لایه منطق تجاری (Services)، لایه داده (Models، Managers). این جداسازی، تستپذیری و نگهداری را چند برابر میکند. - استفاده از Async Views و ASGI: از Django 3.1 به بعد، ویوهای ناهمگام پشتیبانی میشوند. در پروژههایی که I/O سنگین دارند (APIهای خارجی، کار با فایل)، این ویژگی میتواند کارایی را چند برابر کند.
- گسترش ORM بدون شکنندگی: در پروژههای پیچیده، Custom Managers و QuerySets سفارشی، دسترسی به داده را تمیز و قابل استفاده مجدد میکنند. استفاده معقول از این ابزارها، کد را از منطق تکراری پاک میکند.
- پایش، لاگ و خطاگیری: در محیط تولید، جنگو باید با ابزارهای پایش یکپارچه شود: Sentry برای خطاها، Prometheus یا ابزارهای مشابه برای متریکها، و لاگ ساختاریافته برای ردیابی. این لایه، تفاوت بین پروژهای که در اولین حادثه میشکند و پروژهای که بیصدا و با ثبات کار میکند، است.
در این نگاه، جنگو نه بهعنوان یک ابزار ساخت سریع، بلکه بهعنوان زیرساخت معماری پایدار دیده میشود. تصمیمهایی که در روز اول گرفته میشوند (مثل ساختار اپلیکیشنها، جداسازی منطق، و استراتژی استقرار) در سال سوم تفاوت چند برابری در هزینه نگهداری ایجاد میکنند. برای دیدن تصویر کامل این نگاه در پروژههای وب، معماری مونولیتیک یا میکروسرویس و امنیت در Django: بهترین روشها مکملهای خوبی هستند.
پرسشهای پرتکرار
آیا جنگو برای پروژههای کوچک مناسب است؟ بله، اما اگر پروژهتان بسیار ساده و کوچک است، Flask ممکن است سبکتر و مستقیمتر باشد. جنگو وقتی میدرخشد که پروژه نیاز به ساختار، پنل مدیریت و امنیت داشته باشد.
چطور بین جنگو و Flask تصمیم بگیرم؟ اگر بهطور مشخص نیاز به پنل مدیریت، احراز هویت و ساختار مشخص دارید، جنگو انتخاب بهتری است. اگر آزادی و کنترل کامل میخواهید و پروژه کوچک است، Flask.
آیا استفاده از Django REST Framework ضروری است؟ اگر به API نیاز دارید، بله. DRF استاندارد غیررسمی اکوسیستم جنگو است و کار را بهشدت ساده میکند.
چطور کارایی جنگو را بهینه کنم؟ چند روش کلیدی: select_related و prefetch_related برای جلوگیری از N+1، کش با Redis یا Memcached، استفاده از Celery برای کارهای سنگین، و بهینهسازی کوئریها با django-debug-toolbar.
آیا جنگو برای پروژههای بلادرنگ (Real-time) مناسب است؟ بله، با Django Channels که از WebSocket و ASGI پشتیبانی میکند. اما برای پروژههای بسیار سنگین بلادرنگ، ترکیب جنگو با سرویسهای دیگر (مثل Node.js یا Go) ممکن است انتخاب بهتری باشد.
چطور پروژه جنگو را در Docker استقرار دهم؟ اصول مشابه هر پروژه پایتونی است: یک Dockerfile برای اپلیکیشن، docker-compose برای سرویسها (Gunicorn، Nginx، PostgreSQL، Redis). راهنمای کلی در بررسی Docker.
آیا جنگو از PostgreSQL پشتیبانی میکند؟ بله، و این انتخاب پیشنهادی من برای محیط تولید است. SQLite برای توسعه و پروژههای کوچک کافی است اما برای تولید، PostgreSQL انتخاب بهتری است.
سخن آخر
جنگو یکی از کاملترین فریمورکهای وب است که با فلسفه «باتریها همراه»، مسیر ساخت پروژههای جدی را کوتاه میکند. از مدلها و مهاجرتها تا پنل ادمین، احراز هویت و امنیت، همه بخشهایی که در پروژههای دیگر باید از صفر ساخته شوند، در جنگو از پیش طراحی شدهاند. تجربهام نشان داده پروژههایی که از روز اول با ساختار درست و اصولی شروع شدهاند، در سال دوم و سوم هزینه نگهداری چند برابر کمتری داشتهاند. کلید موفقیت با جنگو، نه یادگیری همه جزئیات در روز اول، بلکه شروع با مفاهیم پایه و تعمیق تدریجی در طول پروژه است.
اگر تجربهای از کار با جنگو در پروژههای خودتان دارید — چه یک الگوی معماری موفق، چه یک چالش پیچیده در استقرار، چه حتی یک اشتباه پرهزینه که کاش زودتر میدانستید — برای من و خوانندگان این سایت ارزشمند است که در دیدگاهها بخوانیم. بگویید در پروژه شما کدام بخش از جنگو بیشترین ارزش را ایجاد کرد و چرا؛ همان یک تجربه میتواند به خواننده بعدی که همین امروز در حال ساخت اولین پروژه جنگو است، چند هفته آزمونوخطا را صرفهجویی کند. 🐍