مقدمه ای بر فریم ورک وب Django در پایتون

در سه مقاله اول از این سری چهار قسمتی که فریم ورک های مختلف وب پایتون را مقایسه می کرد، ما فریم ورک های Pyramid، Flask و Tornado را پوشش دادیم. ما همان اپلیکیشن را سه بار ساخته ایم و در نهایت به Django رسیدیم. Django، به طور کلی، فریم ورک اصلی وب برای توسعه دهندگان پایتون امروزی است و دلیل آن چندان سخت نیست که بفهمیم. این فریم ورک در مخفی کردن بخش زیادی از منطق پیکربندی عالی عمل می کند و به شما اجازه می دهد روی ساخت سریع پروژه های بزرگ تمرکز کنید.

با این حال، وقتی پای پروژه های کوچک مثل اپلیکیشن To-Do List ما به میان می آید، Django می تواند کمی شبیه آوردن یک شلنگ آتش نشانی به یک مبارزه با تفنگ آب باشد. بیایید ببینیم همه چیز چگونه کنار هم قرار می گیرد.

درباره Django

Django خود را به عنوان «یک فریم ورک وب پایتون سطح بالا که توسعه سریع و طراحی پاک و عملی را تشویق می کند» معرفی می کند. این فریم ورک توسط توسعه دهندگان باتجربه ساخته شده و بسیاری از دردسرهای توسعه وب را برعهده می گیرد، تا شما بتوانید روی نوشتن اپلیکیشن خود تمرکز کنید بدون اینکه نیاز باشد چرخ را دوباره اختراع کنید. و آن ها واقعاً منظورشان همین است! این فریم ورک عظیم وب با تعداد زیادی ابزار و قابلیت همراه است که گاهی در طول توسعه، ممکن است برایتان یک معما باشد که چگونه همه چیز با هم کار می کند.

علاوه بر اینکه خود فریم ورک بزرگ است، جامعه Django نیز به طور مطلق عظیم است. در واقع، آنقدر بزرگ و فعال است که یک وب سایت کامل به پکیج های شخص ثالث اختصاص دارد که مردم طراحی کرده اند تا به Django متصل شوند و مجموعه ای از کارها را انجام دهند. این شامل همه چیز از احراز هویت و مجوزدهی، تا سیستم های مدیریت محتوای کامل با Django، تا افزونه های تجارت الکترونیک، و ادغام با Stripe می شود. واقعاً می توان گفت نیازی به اختراع دوباره چرخ نیست؛ احتمالاً اگر بخواهید کاری با Django انجام دهید، کسی قبلاً آن را انجام داده و می توانید به راحتی آن را وارد پروژه خود کنید.

برای این منظور، می خواهیم یک REST API با Django بسازیم، بنابراین از همیشه محبوب Django REST framework استفاده خواهیم کرد. وظیفه آن تبدیل فریم ورک Django، که برای ارائه صفحات HTML کاملاً رندر شده با موتور قالب بندی خود Django ساخته شده، به سیستمی است که به طور خاص برای مدیریت مؤثر تعاملات REST طراحی شده است. بیایید شروع کنیم.

راه اندازی و پیکربندی Django

$ mkdir django_todo

$ cd django_todo

$ pipenv install –python 3.6

$ pipenv shell

(django-someHash) $ pipenv install django djangorestframework

برای مرجع، ما با django-2.0.7 و djangorestframework-3.8.2 کار می کنیم.

برخلاف Flask، Tornado و Pyramid، نیازی به نوشتن فایل setup.py خودمان نداریم. ما در حال ساخت یک توزیع Python نصب شدنی نیستیم. مانند بسیاری از موارد، Django این کار را به روش خودش برای ما انجام می دهد. ما همچنان به یک فایل requirements.txt نیاز خواهیم داشت تا تمام نصب های لازم برای استقرار در مکان های دیگر را پیگیری کنیم. با این حال، تا حدی که هدف گذاری ما روی ماژول های داخل پروژه Django است، Django به ما اجازه می دهد زیرشاخه هایی که می خواهیم به آن ها دسترسی داشته باشیم را فهرست کنیم و سپس از آن زیرشاخه ها به عنوان پکیج های نصب شده وارد کنیم.

اول، باید یک پروژه Django ایجاد کنیم.

وقتی Django را نصب کردیم، اسکریپت خط فرمان django-admin را نیز نصب کردیم. وظیفه آن مدیریت تمام دستورات مرتبط با Django است که به ما کمک می کند پروژه خود را کنار هم قرار دهیم و در طول توسعه آن را حفظ کنیم. به جای اینکه کل اکوسیستم Django را از ابتدا بسازیم، django-admin به ما اجازه می دهد با تمام فایل های کاملاً ضروری (و بیشتر) که برای یک پروژه استاندارد Django نیاز داریم، شروع کنیم.

دستور فراخوانی دستور start-project در django-admin به شکل زیر است:

django-admin startproject

ما می خواهیم فایل ها در دایرکتوری کاری فعلی ما وجود داشته باشند، بنابراین:

(django-someHash) $ django-admin startproject django_todo .

نوشتن دستور ls یک فایل جدید و یک دایرکتوری جدید را نشان می دهد.

(django-someHash) $ ls

manage.py django_todo

فایل manage.py یک فایل اجرایی پایتون در خط فرمان است که در نهایت تنها یک پوشش (wrapper) برای django-admin محسوب می شود. بنابراین، وظیفه آن همان است: کمک به مدیریت پروژه ما. از همین رو نام آن manage.py گذاشته شده است.

دایرکتوری که ایجاد شد، یعنی django_todo داخل خود django_todo، نمایانگر ریشه پیکربندی پروژه ما است. بیایید اکنون به آن بپردازیم.

پیکربندی Django

با نام گذاری دایرکتوری django_todo به عنوان «ریشه پیکربندی»، منظور این است که این دایرکتوری شامل فایل های لازم برای پیکربندی کلی پروژه Django ما است. تقریباً همه چیز خارج از این دایرکتوری تنها بر «منطق کسب وکار» مرتبط با مدل ها، ویوها، مسیرها و غیره تمرکز خواهد داشت. تمام نقاط اتصال پروژه به اینجا ختم می شوند.

وقتی در داخل دایرکتوری django_todo دستور ls را اجرا کنیم، چهار فایل نشان داده می شود:

(django-someHash) $ cd django_todo

(django-someHash) $ ls

__init__.py settings.py urls.py wsgi.py

• init.py خالی است و صرفاً وجود دارد تا این دایرکتوری به یک پکیج قابل وارد شدن (importable) پایتون تبدیل شود.
• settings.py جایی است که بیشتر آیتم های پیکربندی در آن تنظیم می شوند، مثل اینکه پروژه در حالت DEBUG باشد، چه پایگاه های داده ای استفاده شوند، Django باید کجا به دنبال فایل ها بگردد و غیره. این بخش «پیکربندی اصلی» ریشه پیکربندی است و به زودی به آن خواهیم پرداخت.
• urls.py همان طور که از نامش پیداست، محل تعریف URLها است. اگرچه نیازی نیست که هر URL پروژه را صریحاً در این فایل بنویسیم، اما باید این فایل از هر مکان دیگری که URLها تعریف شده اند، مطلع باشد. اگر این فایل به URLهای دیگر اشاره نکند، آن URLها وجود نخواهند داشت.
• wsgi.py برای ارائه برنامه در محیط تولید (production) است. درست همانند Pyramid، Tornado و Flask که یک شیء «app» را برای سرو برنامه آماده می کردند، Django نیز باید یک شیء مشابه ارائه دهد. این کار در اینجا انجام می شود و سپس می توان آن را با ابزارهایی مانند Gunicorn، Waitress یا uWSGI سرو کرد.

تنظیم settings

نگاهی به داخل settings.py نشان می دهد که چقدر بزرگ است — و این تنها تنظیمات پیش فرض است! حتی شامل هوک ها برای پایگاه داده، فایل های استاتیک، فایل های رسانه ای، هرگونه ادغام با فضای ابری، یا ده ها راه دیگر که پروژه Django می تواند پیکربندی شود، نیست. بیایید از بالا به پایین بررسی کنیم:

• BASE_DIR مسیر مطلق دایرکتوری پایه، یا جایی که manage.py قرار دارد، را تنظیم می کند. این برای پیدا کردن فایل ها مفید است.
• SECRET_KEY کلیدی است که برای امضای رمزنگاری در پروژه Django استفاده می شود. در عمل، برای مواردی مانند سشن ها، کوکی ها، محافظت CSRF و توکن های احراز هویت کاربرد دارد. بهتر است هرچه زودتر، ترجیحاً قبل از اولین کامیت، مقدار SECRET_KEY تغییر داده شود و به یک متغیر محیطی منتقل شود.
• DEBUG به Django می گوید که پروژه را در حالت توسعه یا تولید اجرا کند. این تمایز بسیار حیاتی است.
• در حالت توسعه، وقتی خطایی رخ می دهد، Django کل stack trace و تمام تنظیمات و پیکربندی های مربوط به اجرای پروژه را نشان می دهد. این می تواند یک مشکل امنیتی بزرگ باشد اگر DEBUG در محیط تولید روی True باشد.
• در حالت تولید، Django تنها یک صفحه خطای ساده نمایش می دهد و هیچ اطلاعات دیگری جز کد خطا ارائه نمی کند.
• یک راه ساده برای محافظت از پروژه این است که DEBUG را روی یک متغیر محیطی تنظیم کنیم، مثل: bool(os.environ.get(‘DEBUG’, ”)).
• ALLOWED_HOSTS فهرست واقعی نام های میزبان (hostnames) است که برنامه از آن ها سرو می شود. در توسعه این می تواند خالی باشد، اما در تولید پروژه Django اجرا نخواهد شد اگر میزبان ارائه دهنده پروژه در فهرست ALLOWED_HOSTS نباشد. این نیز یکی از متغیرهای محیطی است.
• INSTALLED_APPS فهرست «اپلیکیشن ها» (apps)ی Django است که پروژه به آن ها دسترسی دارد. برخی از موارد پیش فرض شامل:
• وب سایت مدیریت داخلی Django
• سیستم احراز هویت داخلی Django
• مدیر یکسان برای همه مدل های داده
• مدیریت سشن ها
• پیام رسانی مبتنی بر کوکی و سشن
• استفاده از فایل های استاتیک سایت مثل CSS، JS و تصاویر طراحی سایت
• MIDDLEWARE همان طور که از نامش پیداست، میان افزارهایی است که به اجرای پروژه Django کمک می کنند. بیشتر آن ها برای مدیریت انواع امنیت هستند، اگرچه می توانیم موارد دیگری اضافه کنیم.
• ROOT_URLCONF مسیر import فایل پیکربندی URL پایه را تنظیم می کند. همان urls.py که قبلاً دیدیم؟ به طور پیش فرض، Django به آن فایل اشاره می کند تا تمام URLها را جمع آوری کند. اگر بخواهیم Django جای دیگری نگاه کند، مسیر import آن مکان را اینجا تنظیم می کنیم.
• TEMPLATES فهرست موتورهای قالب است که Django برای رابط کاربری سایت استفاده می کند اگر ما به Django برای ساخت HTML اعتماد کنیم. چون ما این کار را نمی کنیم، این بخش بی ربط است.
• WSGI_APPLICATION مسیر import برنامه WSGI را تنظیم می کند — چیزی که در تولید سرو می شود. به طور پیش فرض به یک شیء application در wsgi.py اشاره دارد و به ندرت نیاز به تغییر دارد.
• DATABASES مشخص می کند پروژه Django به کدام پایگاه های داده دسترسی دارد. پایگاه داده پیش فرض باید تنظیم شود. سایر پایگاه ها نیز می توانند نام گذاری شوند به شرط اینکه HOST، USER، PASSWORD، PORT، NAME و ENGINE مناسب ارائه شوند. این ها اطلاعات حساسی هستند و بهتر است در متغیرهای محیطی مخفی شوند. (برای اطلاعات بیشتر، به مستندات Django نگاه کنید.)
• نکته: اگر به جای ارائه اجزای جداگانه موقعیت پایگاه داده، می خواهید URL کامل پایگاه داده ارائه دهید، به dj_database_url مراجعه کنید.
• AUTH_PASSWORD_VALIDATORS عملاً فهرستی از توابع است که برای بررسی رمز عبور ورودی اجرا می شوند. چند مورد پیش فرض داریم، اما اگر نیاز به اعتبارسنجی پیچیده تر بود، می توانیم آن ها را اضافه کنیم.
• LANGUAGE_CODE زبان سایت را تنظیم می کند. به طور پیش فرض انگلیسی آمریکایی است، اما می توان به سایر زبان ها تغییر داد.
• TIME_ZONE منطقه زمانی برای هر timestamp خودکار در پروژه Django است. بسیار مهم است که از UTC استفاده کنیم و هر پردازش خاص منطقه زمانی را جای دیگری انجام دهیم. UTC یک معیار مشترک بین تمام مناطق زمانی است، چون اختلاف زمانی ندارد. اگر اختلاف زمانی اهمیت دارد، می توانیم آن را از UTC محاسبه کنیم.
• USE_I18N به Django اجازه می دهد از سرویس های ترجمه خود برای ترجمه رشته ها در رابط کاربری استفاده کند. I18N = internationalization (۱۸ حرف بین i و n)
• USE_L10N (L10N = localization [۱۰ حرف بین l و n]) اگر True باشد، قالب بندی محلی رایج داده ها استفاده می شود، مثلاً تاریخ ها: در آمریکا MM-DD-YYYY و در اروپا DD-MM-YYYY
• STATIC_URL بخشی از تنظیمات بزرگتر برای سرو فایل های استاتیک است. چون ما یک REST API می سازیم، نیازی به نگرانی درباره فایل های استاتیک نداریم. به طور کلی مسیر ریشه پس از نام دامنه برای هر فایل استاتیک را تنظیم می کند. مثال: اگر یک لوگو داشته باشیم، مسیر آن https:////logo.gif خواهد بود.

این تنظیمات به طور پیش فرض آماده استفاده هستند. تنها چیزی که باید تغییر دهیم، تنظیمات DATABASES است. ابتدا پایگاه داده ای که استفاده خواهیم کرد را ایجاد می کنیم:

(django-someHash) $ createdb django_todo

ما می خواهیم از پایگاه داده PostgreSQL استفاده کنیم، همانند Flask، Pyramid و Tornado. این یعنی باید تنظیمات DATABASES را تغییر دهیم تا سرور ما بتواند به PostgreSQL دسترسی داشته باشد. ابتدا: موتور (ENGINE). به طور پیش فرض، موتور پایگاه داده django.db.backends.sqlite3 است. ما آن را به django.db.backends.postgresql تغییر خواهیم داد.

برای اطلاعات بیشتر درباره موتورهای موجود Django، مستندات را بررسی کنید. توجه داشته باشید که اگرچه از نظر فنی امکان استفاده از راه حل NoSQL در پروژه Django وجود دارد، به طور پیش فرض Django به شدت به سمت راه حل های SQL تمایل دارد.

سپس باید جفت های کلید-مقدار برای بخش های مختلف پارامترهای اتصال مشخص شوند:

• NAME نام پایگاه داده ای است که تازه ایجاد کردیم.
• USER نام کاربری فرد برای پایگاه داده Postgres است.
• PASSWORD رمز عبور لازم برای دسترسی به پایگاه داده است.
• HOST میزبان پایگاه داده است. localhost یا 127.0.0.1 مناسب است، چون به صورت محلی توسعه می دهیم.
• PORT هر پورتی است که برای Postgres باز است؛ معمولاً 5432 است.

settings.py انتظار دارد برای هر یک از این کلیدها مقدار رشته ای (string) ارائه دهیم. اما این اطلاعات بسیار حساس است و برای هیچ توسعه دهنده مسئولیت پذیری مناسب نیست که آن ها را به این شکل ذخیره کند. راه های متعددی برای حل این مشکل وجود دارد، اما ما فقط از متغیرهای محیطی استفاده خواهیم کرد.