جنگو کنده، پس نباید استفاده کنیم؟ 🙂‍↔️

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

چرا میگن جنگو کنده؟
خب راستشو بخواین، جنگو واقعا کنده (نسبت به فریم‌ورک‌های async بیس مثل FastAPI و زبان‌های کامپایلری مثل Go که توی I/O bound حرف اولو میزنن). ولی چرا؟

جنگو سینکروسه 🥸
جنگو از اساس برای وب‌اپلیکیشن‌های سنتی طراحی شده(طبیعیم هست چون ۲۰ سال پیش ساخته شد اون موقع مفهومی به اسم async به این صورت نبود).
ولی فریم‌ورک‌هایی مثل FastAPI می‌تونن همزمان چند درخواست رو مدیریت کنن (به لطف async).

‏Overhead بالای ORM 🏋️‍♂️
‏ORM جنگو سنگینه. هر کوئری که میزنی، کلی پردازش اضافه انجام میده تا کارتو راحت کنه، ولی همین باعث میشه کندتر از ORMهای سبک‌تر باشه.

‏Middleware و Request Cycle پیچیده‌تره 🌀

جنگو یه سری پردازش‌های اضافه برای هر درخواست انجام میده (مانند middleware ها، سیگنال‌ها، template rendering و ...)، که باعث میشه به طور طبیعی کمی کندتر باشه.

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

1⃣ سرعت، همیشه مهم‌ترین فاکتور نیست
اکثر پروژه‌ها، گلوگاه سرعت، فریم‌ورک نیست، بلکه دیتابیس، شبکه، و لاجیک‌های بیزینسی هستن. یه اپلیکیشن CRUD ساده که روزی ۱۰۰۰ تا درخواست داره، با FastAPI یا جنگو، تفاوت محسوسی نداره.

2⃣ توسعه سریع‌تر = زمان و پول بیشتر
جنگو کلی چیز آماده داره. سیستم مدیریت کاربر، فرم‌ها، ORM، ادمین پنل، و کلی ماژول دیگه. این یعنی تو به جای ساختن همه‌چی از صفر، فقط تمرکزت روی بیزینس لاجیکه. توسعه سریع‌تر = هزینه کمتر.

3⃣ امنیت، یکپارچگی، و قابلیت اطمینان
جنگو به طور پیش‌فرض مقاوم در برابر حملات XSS، CSRF، SQL Injection و غیره‌ست. ولی FastAPI؟ باید خودت امنیت رو درست کنی و Middleware بنویسی، که اگه اشتباه کنی، فاجعه میشه

کی بریم سمت FastAPI یا Go یا هرچیز سریع؟

1⃣ وقتی واقعا به Async نیاز داری
اگه داری یه چت‌اپ، وب‌ساکت، یا یه سیستم پردازش سنگین با درخواست‌های همزمان بالا می‌نویسی، FastAPI و Go گزینه‌های بهتری هستن.

2⃣ وقتی هر میلی‌ثانیه مهمه
توی سرویس‌های real-time مثل سیستم‌های تریدینگ، گیمینگ، یا پردازش داده سنگین، Go و Rust گزینه‌های بهتری هستن، چون کامپایل میشن و خیلی سریع‌تر از پایتون اجرا میشن.

پس چی کار کنیم؟

اگه سرعت برات مهمه: Go بزن Java بزن یا ...

اگه یه API سبک و سریع لازم داری: FastAPI بزن

اگه می‌خوای سریع یه اپلیکیشن کامل و امن بالا بیاری: Django بهترین گزینه‌ست

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

خوشحال میشم نظرتون رو بشنوم
تو کامنتای همین پست بگید 👇

#️⃣ #programming #django #backend

➖➖➖➖➖➖➖➖➖

🥷 CHANNEL | GROUP

سلام به همه دوستان
نتیجه قرعه کشی اعلام شد و به دوستانی که برنده شدند پیامک ارسال شد

۱۰ میلیون تومان مبلغ قرعه کشی به حساب خانه ای بی واریز شد

فیش واریزی قرعه کشی های قبلی
https://news.1rj.ru/str/c/1525472919/2990

https://news.1rj.ru/str/c/1525472919/2177

https://news.1rj.ru/str/c/1525472919/2504

@gocasts

ا DBMS ها یه کار دیگه میکنن 😅
چون خوندن از ایندکس و بعد خوندن دیتا از رو دیسک زمان بره. دیتابیس ها تصمیم میگیرن که اصن از ایندکس بخونن یا نه مثلا توی پست گرس planner این کار رو میکنه.
سه تا حالت ممکنه پیش بیاد:

1⃣ Scan index
کوئری ما دامنه چیزهای که میخواد بگیره نسبت به جدول کمه. پس میرم ایندکس رو میخونم

2⃣ Bitmap index scan
این برای موقعی که بخش بزرگی از جدول رو میخوایم برگردونیم، توی این حالت کل درخت ایندکس خونده میشه و pageهای که اطلاعات ما توشه علامت گذاری میشن تا در مرحله بعد دیتا ها خونده شن

3⃣ Full table scan
توی این حالت دیتابیس به ما میگه: داداش این چیزی که میخوای تقریبا کل جدوله من اگه از ایندکس استفاده نکنم سریعترم😂

اها این توییتر snowflake هم داشته باشیم یه کار دیگه هم باهاش میتونیم بکنیم:

توی کوئری های pagination داره ما از offset استفاده میکنیم این یعنی اگه جدول ما 100000010 تا رکورد داشته باشه و ما فقط ۱۰ تاشو بخوایم، همه اش از روی دیسک گرفته میشه ۱۰ تای لازم رو میده بهمون و بقیه رو دراپ میکنه، چقدر دهشتناک...

حالا ما میتونیم به جای افست بیایم بر اساس id خود ساخته خودمون کار کنیم

Select * from people order by sid desc where sid > 1029383737 limit 10;

این io اش خیلی کمتره. یعنی خیلی خیلی کمتره

توی btree معمولی اگه بخوایم یه کوئری رنج بزنیم مثلا

Select * from people where id > 10

درخت btree ما بارها و بارها Traverse میشه. یادمون باشه که ایندکس خودش یه io هستش و خوندن دیتاها یه io دیگه.

اینکار اصلا بهینه نیست، بخاطر همین dbms ها رفتن روی الگوریتم b+tree

اB+tree دقیقا مثله btree هستش ولی اطلاعات توی leaf ها ذخیره میشن فقط این باعث دوتا چیز میشه:

۱. هر نودی که میخونیم چون دیتای نداره(به غیر از لیف ها) لحاظ به حجمی سبک تره، io سریعتری خواهیم داشت.

۲. چون اطلاعات در لیف ها هستن میتونیم لیف ها رو با لینکدلیست بهم وصل کنیم تا کوئری های range خیلی خیلی سریعتر اجرا شن

🔰دستورات کمتر دیده شده در لینوکس #سری بیست و سوم
🔹دستور getfacl

این دستور در لینوکس برای خواندن لیست کنترل دسترسی (ACL) فایل‌ها و دایرکتوری‌ها استفاده می‌شود. در این مثال، دستور getfacl برای خواندن ACL فایلی به نام hossein.txt اجرا شده است. خروجی این دستور به شرح زیر است:

user@pcname$  getfacl /hossein.txt
# file: hossein
# owner: user
# group: user
user::rw-
group::r--
mask::rwx
other::r--

📌نویسنده: حسین سیلانی
📌منبع :  آکادمی کندوی دانش
https://learninghive.ir

#تاریخ_رشته_کامپیوتر در ایران
لیست دروس ارائه شده توسط گروه کامپیوتر (رشته ریاضی و علوم کامپیوتر) دانشگاه آریامهر (شریف کنونی) در نیمسال اول سال تحصیلی 52-51
از آرشیو آقای علی پارسا
-
رشته "ریاضی و علوم کامپیوتر" در سال 1349 در دانشگاه شریف تاسیس شده است.

@mollanasraddinx

البته دیتابیس ها از b+tree استفاده میکنن ولی عموما توی داک هاشون میگن b-tree.

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