برنامه‌نویسی

چه زمانی از Django استفاده کنیم؟


۲۵ تیر ۱۳۹۹
چه زمانی از Django استفاده کنیم؟

انتخاب یک زبان برنامه‌نویسی و فریم‌ورک برای یک پروژه به دلیل اینکه آخرین پروژه شما با آن زبان و فریم‌ورک انجام شده است و یا حتی به این دلیل که تاحدودی به آن‌ها مسلط هستید، کار منطقی و درستی نیست.

قبل از شروع یک پروژه، شما باید ابتدا ارزیابی کنید که کدام زبان و فریم‌ورک برای رسیدن نتیجه مدنظرتان مناسب است. چه چیزی برای شما مهم است؟ امنیت؟ توسعه سریع؟ مقیاس‌پذیری؟ تطبیق پذیری؟ پشتیبانی؟

وقت گذاشتن برای یک تصمیم مطلع و مطمئن قبل از شروع پروژه، بهتر از این است که بعدها تصمیمتان را در این رابطه تغییر دهید (و یا حتی بدتر مجبور شوید از یک سری راه‌های غیر مرسوم، قابلیت‌هایی که می‌خواهید را به کدتان اضافه کنید، به این دلیل که فریم‌ورک مورد استفاده شما، این قابلیت‌ها را ندارد).

بعد از سال‌ها تجربه با تکنولوژی‌های مختلف (چه سمت وب و چه سمت موبایل)، به این معتقدم که Django قابلیت‌های کاملی را ارائه می‌کند که سایر فریم‌ورک‌ها نمی‌کنند.

می‌دانم که این ادعای بزرگی است. اجازه دهید بیشتر توضیح دهم.

وبسایت‌های پراستفاده و محبوب زیادی از Django استفاده می‌کنند، همچون Instagram و Pinterest و یا حتی Facebook از Django برای بسیاری از قابلیت‌هایش استفاده می‌کند. Django برای انتشار و یا publishing استفاده می‌شود، پس این جای تعجب نیست که سایت‌هایی نظیر Washington Post و Smithsonian Magazine از Django استفاده می‌کنند.

Amit Ashwini معاون بازاریاب در Zibtek

چه زمانی از Django استفاده کنیم؟

اگر تعداد کمی از موارد زیر را بررسی کنید (بدون مخالفت شدید با هرکدام از آن‌ها)، به احتمال زیاد Django برای پروژه شما مناسب است.

  • قصد دارید یک برنامه تحت وب و یا API توسعه دهید.
  • نیاز دارید به سرعت دیپلوی کنید و روبه‌جلو حرکت کنید و در عین حال هرچه جلوتر می‌روید، تغییراتی ایجاد کنید.
  • به صورت پیشفرض برنامه شما باید از آسیب‌پذیری‌ها و حملاتی نظیر CSRF، SQL Injection، XSS، Clickjacking و … ایمن باشد.
  • ممکن است برنامه شما در هر زمانی نیاز داشته باشد تا به مقیاس بالاتر و یا پایین‌تری تغییر پیدا کند (به عبارتی در پروژه‌تان مقیاس پذیری از اهمیت ویژه‌ای برخوردار است).
  • شاید بخواهید در آینده با تکنولوژی‌های روز، نظیر یادگیری ماشین (Machine Learning)، تعامل داشته باشید.
  • به فریم‌ورک قابل اطمینانی نیاز داشته باشید که به صورت فعال توسعه پیدا کند، همچنین توسط وبسایت‌ها و یا شرکت‌های بزرگ و سطح بالا استفاده شده باشد.
  • بخواهید برنامه و API را در یک کد داشته باشید تا با اصل Single source of truth مطابقت کنید.
  • نمی‌خواهید با دستورات دیتابیس مستقیما سروکله بزنید و به فریم‌ورکی نیاز دارید که از ORM پشتیبانی کند.
  • قصد استفاده از یک پروژه متن‌باز را دارید.
  • نگران این هستید که شاید در یک مساله گیر کنید و نتوانید راه‌حلی پیدا کنید، پس به دنبال یک فریم‌ورک با مستندات کامل به همراه یک جامعه کاربری بزرگ و فعال هستید.

علاوه بر موارد بالا، مهارت‌های شما و یا تیم‌تان باید درنظر گرفته شود.

اگر درحال حاضر توسعه‌دهنده‌ای هستید که به خوبی می‌دانید وب چگونه کار ‌می‌کند، استفاده از Django نسبتا بدون مشکل خواهد بود. تنها به این نیاز خواهید داشت که بدانید ساختار Django (و مطمئنا به همراه چند مورد دیگر) چگونه است، بعد از آن به راحتی می‌توانید پروژه را پیش ببرید.

وبسایت‌هایی که از Django استفاده می‌کنند

Django بیش از یک دهه است در دسترس توسعه‌دهندگان قرار دارد. در این مدت وبسایت‌های زیادی از آن استفاده کرده‌اند، که برخی از موارد قابل توجه را در لیست زیر خواهیم دید:

  • Pinterest Engineering
  • Mozilla
  • Bitbucket
  • Udemy
  • The Onion
  • Disqus
  • Washington Post
  • NASA
  • Spotify
  • Instagram Engineering
  • National Geographic
  • The Guardian
  • JSFiddle

آیا هنوز نمی‌دانید که صرف وقت، برای افزایش سرعت توسعه توسط Django، ارزش دارد یا نه؟ اول از همه دلایلی که Django مناسب پروژه شما نیست را در نظر بگیرید:

چه زمانی از Django استفاده نکنیم

  • برنامه بزرگی دارید که نمی‌توانید تمام آن را در یک کدپایه (basecode) قرار دهید. شاید قصد داشته باشید که برنامه‌تان را به چندین مایکروسرویس تبدیل کنید. هر لایه و بخش ممکن است توسط یک تیم و پردازش جدا بهتر عمل کند. حتی استفاده از تکنولوژی‌های مختلف برای هر بخش می‌تواند خیلی مفید باشد. ممکن است که Django برای برخی از موارد مناسب باشد، اما توسعه و ایجاد همه چیز توسط Django کار عاقلانه‌ای نیست (نه تنها Django، بلکه استفاده از یک فریم‌ورک برای همه بخش‌های یک پروژه درست نیست).
  • قصد ساخت برنامه ساده‌ای را دارید که به دیتابیس، انجام عملیات بر روی فایل‌ها و یا هر کار پیچیده دیگری نیاز ندارد. استفاده از مایکروفریم‌روک‌ها در این موارد به مراتب مناسب‌تر است. Flask یکی از معروف‌ترین مایکروفریم‌ورک‌هاست که با پایتون نوشته شده است. همچنین در زبان‌های دیگر نیز چنین مایکروفریم‌ورک‌هایی وجود دارد. مثل: Slim در PHP و Apache Spark در Java و یا Express برای Node.js و …
  • قصد دارید همه چیز را از صفر ایجاد کنید و به خوبی می‌دانید میخواهید چه کاری انجام دهید.
  • شما و یا تیم توسعه‌تان با پایتون و Django آشنا نیستید و نمی‌توانید وقت کافی و حداقلی را برای بدست آوردن مهارت‌های لازم به جهت انجام پروژه صرف کنید. در این حالت، بهترین راه استفاده از مواردی است که آن‌ها را به خوبی می‌شناسید و مهارت کافی در آن‌ها دارید. به این نکته هم توجه کنید که اگر پروژه‌ای را با تکنولوژی و یا فریم‌ورک جدیدی شروع کنید، احتمال اینکه گیج و سردرگم شوید چندبرابر می‌شود.

اگر هیچ کدام از موارد بالا شامل شما نمی‌شود، به احتمال زیاد Django انتخاب خوبی برای شماست.

دلایل استفاده از Django

ساخته شدن فریم‌ورک Django با پایتون

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

  • پایتون یکی از زبان‌های برنامه‌نویسی معروف، محبوب و رو به رشد در دنیاست. منابع:
    1. TIOBE index
    2. Indeed.com Jobs’ data analysis by Coding Dojo
    3. GitHub Octoverse
    4. Stack Overflow Developer Survey 2018
  • یادگیری پایتون بسیار راحت، ساده و معمولا جز یکی از اولین انتخاب‌ها، میان توسعه‌دهندگان است.
  • اجازه ندهید که مورد قبلی به اشتباه این دیدگاه را در ذهن شما ایجاد کند که این زبان برای تازه‌کارهاست. غول‌های بزرگی نظیر Google به صورت گسترده از پایتون در زیرساخت خود استفاده می‌کند.
  • پایتون برای ساخت خزنده‌های وب (web scrapers) بسیار مناسب است.
  • به خوبی می‌تواند با سایر زبان‌ها ارتباط برقرار کند. استفاده از پایتون به این معنا نیست که شما مجبورید تنها از کتابخانه و ماژول‌هایی که با پایتون ساخته شده‌اند استفاده کنید، بلکه شاید نیاز داشته باشید از کتابخانه‌های زبان‌های دیگر، نظیر C++/C و یا Java، استفاده کنید.
  • پایتون قابل حمل است و به راحتی می‌توان یک کد پایتونی را خواند و متوجه شد که چه اتفاقی درحال رخ دادن است.
  • حتی می‌توانید پایتون را بر روی JVM اجرا کنید. برای اطلاعات بیشتر، Jython را بررسی کنید.
  • پایتون به صورت گسترده در تکنولوژی‌های روز، نظیر بیگ‌دیتا و یادگیری ماشین و … استفاده می‌شود.
  • با استفاده از پایتون به کتابخانه وسیع و گسترده PyPI دسترسی خواهید داشت.

توسعه یک برنامه توسط پایتون ۵ الی ۱۰ برابر سریع‌تر از استفاده از C++/C و ۳ الی ۵ برابر سریع‌تر از Java است.

منبع

Django فریم‌ورکی با ویژگی Batteries Included است

Batteries Included به این معنی است که Django اکثر کتابخانه‌ها و ابزارهایی که برای استفاده‌های مرسوم نیاز است را به همراه خود دارد. Django ORM، Middlewares، Authentication، HTTP libraries، Multi-site supprort، i18n، Django Admin، template engine و … (که به اصطلاح باتری‌ها (batteris) هستند) هیچ کدام از فریم‌ورک‌های دیگری که می‌شناسم، این حجم از قابلیت‌ها را یکجا ندارند.

برخی‌ها این مورد را جنبه مثبت و برخی دیگر آن را جنبه منفی در نظر می‌گیرند، هر طرف دلایل خودشان را دارند، اما من با هردو طرف موافق هستم.

منفی است، زیرا باعث می‌شود که فریم‌ورک خیلی بزرگ و سنگین شود. بحث من این است که اگر به این قابلیت‌هایی که باعث حجیم‌تر شدن فریم‌ورک می‌شود و در عین حال قابلیت‌های زیادی به آن می‌دهند، نیازی ندارید، باید از کتابخانه‌های دیگر و یا کتابخانه‌ای که خودتان آن را می‌نویسید، استفاده کنید.

چرا از چیزی که به بهترین نحو ممکن ساخته شده است، در شرایط سخت هم جوابگو بوده، بسیاری از وبسایت‌های بزرگ دنیا از آن استفاده کرده‌اند، کاملا فعال و خیلی سریع در حال توسعه‌ است و توسط یک جامعه کاربری بزرگ پشتیبانی می‌شود، استفاده نکنیم؟

اگر به این قابلیت‌هایی که توسط Django ارائه می‌شود و به آن‌ها اشاره کردیم، نیازی ندارید، باید در نظر بگیرید که از مایکروفریم‌ورک‌ها استفاده کنید.

چرخ را دوباره اختراع نکنید، این را بیاد دارید؟ وقت خود را بر روی موارد مهم صرف کنید و اجازه دهید که Django مابقی قضیه را برایتان انجام دهد.

Django Admin

گرچه که من در بخش قبلی اشاره کردم، این بخش به توجه بیشتری نیاز دارد. فریم‌ورک‌های زیادی نظیر Laravel، Yii و … تلاش کرده‌اند که کار با پنل Admin را ساده‌تر کنند. پروژه‌های بسیاری را توسط فریم‌ورک‌های مختلف توسعه داده‌ام، هیچ کدام از آن‌ها ذره‌ای به Django در ساده و روان‌بودن کارکردن با پنل Admin نزدیک نیستند.

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

Django Admin به خوبی ساختار یافته است. در برخی از پروژه‌هایم از خود Django admin استفاده کردم و در برخی دیگر به طور کامل آن را با templateهایی که از پایه شخصی‌سازی کرده بودم جایگزین کردم. در هر موردی، اگر چنین کاری را در سایر فریم‌ورک‌هایی که میشناسم، انجام می‌دادم، زمان بیشتری می‌گرفت.

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

قاعده DRY و یا Don’t Repeat Yourself

فریم‌ورک‌های زیادی را دیده‌ام که سازگاری با DRY را به رخ می‌کشند. با بسیاری از آن‌ها هم کار کرده‌ام، اما با هیچ کدام نمی‌توان با توجه به این قاعده کار کرد. بیشتر فریم‌ورک‌ها، متاسفانه به رعایت قاعده DRY توجهی نمی‌کنند. از دیدگاه من، اگر در حال ساخت برنامه‌ای هستید که قرار است مرتبا آن را بروزرسانی کنید (بیشتر برنامه‌های امروزی)، باید از قاعده DRY پیروی کنید تا از رخ دادن مشکلات پیشگیری کنید.

در Laravel، برای مثال نیاز دارید تا اعتبارسنجی هر route را به صورت جداگانه بنویسید. این مورد در اکثر فریم‌ورک‌ها وجود دارد. برای اینکه کدتان با قاعده DRY سازگار باشد، باید تلاش کنید تا این قاعده را پیاده کنید. مخصوصا هنگامی که در یک تیم هستید بررسی و چک کردن، سخت‌تر می‌شود.

در طرف دیگر، فریم‌ورک Django، به گونه‌ای طراحی شده است که برای نقض قاعده DRY، باید از مسیر خودتان در پروژه خارج شوید. همانگونه که باید باشد است، درست است؟ آیا به مثال نیاز دارید؟

در اینجا نحوه کار اعتبار سنجی و migrationهای دیتابیس‌ها را در Django بررسی می‌کنیم:

  1. مدلی به همراه فیلدهای مورد نیاز ایجاد کنید. همچنین اعتبارسنجی‌ها و محدودیت‌‌ها بیشتری که نیاز است را هم مشخص کنید.
  2. migrationها توسط یک دستور در خط فرمان ایجاد می‌شوند: python manage.py makemigrations
  3. تغییرات در دیتابیس توسط این دستور در خط فرمان اعمال خواهند شد: python manage.py migrate
  4. اعتبارسنجی‌ها و محدودیت‌ها به صورت خودکار توسط هر کدام از عملیات‌های CRUD (یعنی Create, Read, Update, Delete) بررسی می‌شوند (چه در Django Admin و چه در Django Rest). در واقع نیازی ندارید تا دوباره اعتبارسنجی‌ها را خودتان بنویسید.
  5. از مدل مشابه‌ای برای ایجاد CRUD برای ظاهر بخش Django Admin استفاده می‌شود و به HTML/CSS شخصی‌سازی‌شده نیاز ندارد.

اگر این موارد را با سایر فریم‌ورک‌ها مقایسه کنید، فکر نمی‌کنم بتوانند تمام این کارها را تنها مثل چند خط زیر توسط Django انجام دهند:

class Employee(models.Model):
    name = models.CharField(max_length=127)
    email = models.EmailField(null=True, blank=True)
    created_at = models.DateTimeField(blank=True, null=True, auto_now_add=True)
    updated_at = models.DateTimeField(blank=True, null=True, auto_now=True)

این تنها در رابطه با “تکرار نکردن خودتان” (not repeating yourself) نیست. این قضیه به شما کمک می‌کند تا از ایجاد مشکلات و باگ‌ها در آینده پروژه پیشگیری کنید. همه ما در این وضعیت قرار داشتیم که وقتی یک چیزی را در جایی از کد تغییر می‌دهیم و فراموش می‌کنیم که مابقی مواردی که نیاز به تغییر دارند را، تغییر دهیم و متوجه این مشکل نخواهیم شد، تا اینکه به طور مثال مشتری و یا کاربر این باگ را گزارش کند.

در Django، با توجه به تکه کد بالا، اگر بخواهید max_length یک فیلد را تغییر دهید، این تغییر را تنها در همینجا انجام دهید، به صورت خودکار این تغییر و سایر تغییرات شما بر روی اعتبارسنجی تمامی routeها و دیتابیس اعمال خواهد شد.

Django Framework ORM

Django قابلیت ORM و یا Object-Relational Mapping را به طور کامل فراهم می‌کند. با ORMهای زیادی در تکنولوژی‌های مختلف کار کرده‌ام، از جمله Eloquent، greenDAO، Yii AR و … تمامی آن‌ها از queryهای پایه‌ای به طور کامل پشتیبانی می‌کنند اما گاهی اوقات مجبور بودم که خودم queryهای خام را برای دیتابیس بنویسم، زیرا این ORM در این مورد، نتوانسته نیازم را برطرف کند.

تا به حال، هنگام استفاده از Django ORM به این مشکلات برنخورده‌ام، زیرا به گونه‌ای ساخته شده است که به کل فراموش می‌کنید که در حال کار با queryهای دیتابیس هستید. یک ORM باید اینگونه باشد. در زیر چند مثال از Django ORM مشاهده می‌کنیم:

به طور مثال برای دریافت ۵ رکورد آخر از مدل Employee که در آن‌ها rank برابر ۱۰ و سن کمتر و مساوی از ۳۰ است از خط زیر استفاده می‌کنیم:

top_young_employees = Employee.objects.filter(rank=10, age__lte=30)[:5]

و یا برای وارد کردن یک رکورد با مقادیر مشخص:

employee = Employee.objects.create(name=’John Doe’, age=35, country=’IN’)

و در نهایت برای مشاهده مقدار یک فیلد:

print(employee.name)

توسعه سریع

این چیزی است که تقریبا تمام فریم‌ورک‌ها، دارا بودن آن را فریاد می‌زنند، احتمالا با توجه به تفسیرشان از “سریع” درست می‌گویند.

با استفاده از Django، می‌توانید کارهایتان را با سرعت وصف‌ناپذیری انجام دهید. به هنگام استفاده از Django، خواهید دید که با چه سرعتی می‌توانیم UI پنل admin، جداول دیتابیس و اعتبارسنجی‌های بالا را ایجاد کنیم.

این تنها بخش کوچکی از یک کوه یخ بود.

گرچه این ویژگی به خودی خود قابلیت حساب نمی‌شود. درحقیقت ویژگی‌ایی است که همراه قاعده DRY، مدل ORM، موتور template و فلسفه “batteries included” ارائه می‌شود.

امنیت فریم‌ورک Django

بیایید روراست باشیم، توسعه‌دهندگان گاهی اوقات تنبل هستند. حداقل من اینطور هستم. بیشتر اوقات انجام برخی taskها را که اهمیت زیادی ندارند را به تعویق می‌اندازم. عدم انجام این taskها معمولا باعث ایجاد آسیب‌پذیری‌ها و مشکلات امنیتی می‌شود.

دلیلی که بیشتر باعث می‌شود Django را دوست داشته باشم این است که برای ارائه قابلیت توسعه سریع، امنیت را به خطر نمی‌اندازد. قابلیت‌های امنیتی به صورت پیشفرض فعال شده‌اند و این که شما تنبل باشید یا نه اهمیتی ندارد.

متن‌باز، به طور کامل مستندسازی شده، جامعه‌کاربری بزرگ و …

به دلیل متن‌باز و معروف بودن، Django جامعه کاربری بزرگ و مفیدی دارد. فرض می‌کنم که از مزایای متن‌باز بودن یک پروژه آگاهی دارید. Django هم دارای این مزایاست.

مستندات رسمی Django برای توسعه‌دهندگان بیش‌از حد نیاز آن‌ها است. اگر در جایی گیر کنید و یا با مشکلی روبرو شوید، به راحتی می‌توانید راه‌حل مشکلات خود را پیدا کنید. علاوه‌براین Stack Overflow، پر از سوال و جواب‌هایی است که به Django مربوط است.

تا جایی که دیده‌ایم Django کتابخانه‌های زیادی را مخصوص خودش ایجاد کرده است، شاید باعث حیرتتان شود که هیچ کتابخانه‌ای را برای تست نساخته است. به این معنا نیست که Django از تست‌گرفتن پشتیبانی نمی‌کند، مطمئنا پشتیبانی می‌کند. در مستندات Django یک بخش کاملا جدا مخصوص تست‌گرفتن پروژه است. با توجه به قانون “چرخ را دوباره اختراع نکنید”، وقتی پایتون کتابخانه‌ای عالی مخصوص تست‌گرفتن دارد، ایجاد کتابخانه‌ای مخصوص این کار توسط Django کار بیهوده‌ای است. Django به خوبی از این قضیه پشتیبانی می‌کند. همچنین با کتابخانه‌های دیگری نظیر pytest نیز به خوبی کار می‌کند.

وضعیت Django و سایر فریم‌ورک‌های معروف در این‌روز‌ها

تلاش کردم تا مشکلات و مسائلی که به هنگام استفاده از فریم‌ورک‌های دیگر در مقایسه با Django وجود دارد را به خوبی مطرح کنم. بعد از کار کردن با Yii، CodeIgniter، WordPress، CS-Cart، Laravel و … متوجه شدم که Django از تمامی آن‌ها بهتر است. گرچه این تنها نظر من است.

اگر بخواهید به آمارها نگاهی بندازید، موارد زیر، نظرسنجی سالانه Stack Overflow در چندسال اخیر است که نشان می‌دهد Django میان پراستفاده‌ترین و محبوب‌ترین فریم‌ورک‌ها قرار دارد:

اگر شما هم مثل من پارانوئید هستید، احتمالا بخواهید بیش از حد لازم برای معماری و ساختار کد برنامه وقت بگذارید.

به عنوان بخشی از تجربه‌ام با فریم‌ورک‌های PHP که در بالا اشاره کردم، کارکرده‌ام و همچنین برنامه‌های اندرویدی را توسط Java و پروژه‌های فرانت‌اندی را با استفاده از React.js، توسعه داده‌ام. در تمامی آن‌ها بیش از زمانی که نیاز است برای refactor کدپایه و یا codebase برنامه وقت گذاشته‌ام. پیدا کردن بهترین معماری، مواجه‌شدن با مشکلات مقیاس پذیری بعد از چند ماه، باعث refactor دوباره می‌شود.

اخیرا یک برنامه‌ای که بیش از یکسال بر روی Laravel بوده است را به Django منتقل کرده‌ام. در کمتر از ۱۰ روز به همراه کدهای کمتر و به طبع پیچیدگی کمتر، قادر به استقرار برنامه بودم. اگر این مورد طور دیگر، و یا برعکس بود، با اطمینان می‌توانم بگویم این کار بیش از یک ماه زمان می‌برد.

اگر مستقیما سایر کتابخانه‌ها را با Django مقایسه ‌کنید، به قطع یقین هیچ جای دیگری نخواهید رفت و از Django استفاده خواهید کرد.

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

این موضوع تنها در مورد فریم‌ورک‌های سایر تکنولوژی‌ها نیست. اگر با پایتون آشنا باشید، به احتمال زیاد با مایکروفریم‌ورک Flask، که از Django معروف‌تر است و به همین دلیل بیشتر پیشنهاد می‌شود، آشنا باشید. این باعث تعجب شما می‌شود که کدام یکی را انتخاب و دنبال کنید.

پیشنهاد من چیست؟ این دو را هرگز با یکدیگر مقایسه نکنید. Django یک فریم‌ورک تمام عیار با قابلیت‌های تمام و کمال (batteries included) است. در طرف دیگر Flask حضور دارد که یک مایکروفریم‌ورک است. هدف و نیازتان را به همراه مهارت‌هایتان بشناسید، سپس یکی را انتخاب کنید.

جمع‌بندی

از دیدگاه من، Django تعادل خوبی میان کارایی، معماری، تلاش و کار در توسعه، امنیت و مقیاس پذیری ایجاد کرده است. اگر قصد دارید یک پروژه را از صفر توسعه دهید، شخصا استفاده از Django را پیشنهاد می‌کنم. در این مقاله تلاش کردم به بهترین حالتی که می‌توانم تجربه‌ام با Django را نسبت به سایر فریم‌ورک‌هایی که با آن‌ها کار کرده‌ام، بیان کنم.

منبع: https://medium.com/crowdbotics/when-to-use-django-and-when-not-to-9f62f55f693b