آشنایی با معماری میکروسرویس در فریمورک جنگو

توی دنیای توسعه وب، جنگو (Django) همیشه مثل "چاقوی سوئیسی" همه فن حریف بوده. ابزاری که میگفت: "نگران نباش! من همه چی دارم. ادمین پنل میخوای؟ دارم. احراز هویت میخوای؟ دارم. دیتابیس؟ اونم با من." این یعنی همون معماری Monolith؛ یک دژ محکم که همه چیز داخلش بود.

اما دنیا عوض شد. ما از ساختن دژ های سنگی رسیدیم به ساختن کلونی‌ های مورچه‌ای! یعنی میکروسرویس‌ها. اینجا دیگه بحث "همه فن حریف بودن" نیست، بحث "سریع و چابک بودنه". حالا سوالی که مو رو به تن جنگو‌ کارها سیخ میکنه اینه: آیا میشه این کامیون سنگین و قدرتمند (Django) رو آورد توی پیست مسابقه موتور سواری (Microservices)؟

جواب کوتاهش اینه: آره، ولی به شرطی که راننده ماهری باشی! بیایید ببینیم چطور.

چالش اصلی

بگذارید روراست باشیم. جنگو برای میکرو سرویس ساخته نشده بود. فلسفه جنگو "Batteries Included" هست، یعنی وقتی نصبش میکنی، کلی بار(Middlewares, Apps, Templates) با خودش میاره. توی معماری میکروسرویس، ما دنبال سرویس ‌هایی هستیم که: ۱. سریع بالا بیان (Fast Startup). ۲. رم (RAM) کمی مصرف کنن. ۳. فقط یک کار رو انجام بدن.

حالا اگر بیای برای یک سرویس ساده که فقط قراره "ساعت رو اعلام کنه"، جنگو رو نصب کنی، مثل اینه که برای خریدن نون از سر کوچه، با تریلی ۱۸ چرخ بری! هم هزینه‌بره، هم کند.

پس چرا هنوز از جنگو استفاده کنیم؟ (قدرت پنهان)

شاید بپرسید "خب چرا همش رو با FastAPI ننویسیم؟". سوال خوبیه. اما جنگو دو تا سلاح مخفی داره که هنوز بی ‌رقیبه:

1. Django ORM: قدرتمند ترین ابزار مدیریت دیتابیس در پایتون. اگر سرویس شما "لاجیک پیچیده دیتابیسی" داره، نوشتن کوئری ‌های SQL دستی توی ابزارهای دیگه پیرت میکنه، اما جنگو مثل آب خوردن هندلش میکنه.

2. Django REST Framework (DRF): این ابزار اونقدر کامله که سرعت توسعه API رو ۱۰ برابر میکنه.

قانون طلایی: اگر سرویس ‌ت CRUD سنگین داره (یعنی همش با دیتابیس و فرم و ولیدیشن درگیره)، جنگو پادشاهه. اگر سرویس‌ت قراره ۱۰۰ هزار تا درخواست در ثانیه رو پردازش کنه (Real-time)، جنگو رو بزار کنار.

پیاده‌سازی صحیح

اگر میخوایم جنگو رو ببریم توی معماری میکروسرویس، باید بهش "رژیم" بدیم. نمیشه همون settings.py همیشگی رو استفاده کرد. باید چربی‌ های اضافه رو آب کنیم.

بیایید یک سرویس مدیریت کاربران (User Service) بسازیم. این سرویس قلب تپنده سیستم ماست و چون بحث امنیت و دیتابیس وسطه، جنگو براش عالیه.

۱. حذف اضافات (The Diet Plan) ‌: در فایل settings.py، هر چیزی که لازم نداریم رو کامنت می‌کنیم. ما اینجا API میخوایم، پس نیازی به تمپلت و ادمین نداریم:

# settings.py - نسخه رژیمی

INSTALLED_APPS = [
    # 'django.contrib.admin',       <-- خداحافظ ادمین سنگین
    'django.contrib.auth',
    'django.contrib.contenttypes',
    # 'django.contrib.sessions',    <-- میکروسرویس باید Stateless باشه
    # 'django.contrib.messages',
    # 'django.contrib.staticfiles', <-- فایل استاتیک نداریم
    'rest_framework',               <-- فقط این مهمه
    'users',                        <-- اپ خودمون
]

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.middleware.common.CommonMiddleware',
    # 'django.contrib.sessions.middleware.SessionMiddleware', <-- حذف سشن
    # 'django.middleware.csrf.CsrfViewMiddleware',            <-- اگر فقط API هستیم و توکن داریم
]

نکته فنی: با حذف SessionMiddleware و Admin، سربار حافظه جنگو به شدت کاهش پیدا میکنه و سرعت بوت شدن بالا میره. حالا جنگو دیگه تریلی نیست، شده یک وانت پرقدرت!

۲. ارتباط با جهان بیرون (The API) :‌ حالا با DRF یک اندپوینت (Endpoint) ساده میسازیم که بقیه سرویس‌ ها (مثلا سرویس سفارش که شاید با FastAPI باشه) بتونن ازش اطلاعات کاربر رو بگیرن.

# views.py in Users Service
from rest_framework.views import APIView
from rest_framework.response import Response
from django.contrib.auth.models import User

class UserDetailView(APIView):
    def get(self, request, user_id):
        try:
            user = User.objects.get(id=user_id)
            # برگرداندن دیتای تمیز JSON
            return Response({
                "id": user.id,
                "username": user.username,
                "email": user.email,
                "is_active": user.is_active
            })
        except User.DoesNotExist:
            return Response({"error": "کاربر پیدا نشد"}, status=404)

معضل بزرگ: احراز هویت (Authentication) :‌ 

توی معماری Monolith، ما از "Session" استفاده میکردیم (همون کوکی). اما توی میکروسرویس، اگر کاربر توی سرویس A لاگین کنه، سرویس B از کجا بفهمه؟ نمیتونیم دیتابیس سشن رو بین همه شیر کنیم (این ضد الگوی میکروسرویسه).

راه حل: پاسپورت دیجیتال (JWT) ما به جای اینکه به کاربر "کلید اتاق" بدیم (Session)، بهش یک "پاسپورت مهر شده" میدیم (JWT).

1. کاربر نام کاربری/رمز رو میفرسته به سرویس جنگو.

2. جنگو چک میکنه و یک توکن JWT میسازه (Sign میکنه) و میده به کاربر.

3. کاربر این توکن رو میفرسته برای سرویس سفارش (FastAPI).

4. سرویس سفارش فقط امضای توکن رو چک میکنه. اگر معتبر بود، اجازه میده

جمع‌بندی

بیایید تعصب رو بزاریم کنار. بهترین معماری، معماری ترکیبیه. تصور کنید دارید یک شرکت بزرگ میسازید:

• بخش حسابداری و مدیریت کارمندان (جاهایی که دقت و نظم مهمه و تغییرات کمه) رو بسپارید به جنگو. چون ابزارهاش کامله و امنیتش تضمین شده است.

• بخش پیک موتوری و تحویل سریع (جاهایی که سرعت و تعداد درخواست بالاست) رو بسپارید به FastAPI یا Go.

جنگو برای میکرو سرویس‌ های "هسته مرکزی" (Core Business Logic) عالیه، اما برای سرویس‌ های کوچک و جانبی، بهتره سنگینش نکنید. هنر معمار نرم ‌افزار اینه که بدونه کجا از تریلی استفاده کنه و کجا از موتور سیکلت!