Ninja Learn | نینجا لرن
1.26K subscribers
95 photos
36 videos
11 files
306 links
یادگیری برنامه نویسی به سبک نینجا 🥷
اینجا چیزایی یاد میگیری که فقط نینجاهای وب‌ بلدن 🤫

📄 Send me post: https://t.iss.one/NoronChat_bot?start=sec-fdggghgebe

👥 ɢʀᴏᴜᴘ: https://t.iss.one/+td1EcO_YfSphNTlk
Download Telegram
Forwarded from Python BackendHub (Mani)
هیچوقت جنس پیچیدگی که دیزاین پترن به کد شما اضافه میکنه رو عمیقا متوجه نشده بودم (یعنی نمیتونستم توضیحش بدم)، تا اینکه این ویدیو رو دیدم:

https://youtu.be/SEp0NrXWwoo?si=mBy7nitVakta-SNz

پیچیدگی که به برنامه شما اضافه میکنه اسم گذاری هست😄. با دیدن این ویدیو متوجه این جملم میشین. حتما توصیه میکنم ببینید خیلی جالبه.

@PyBackendHub
🔥51
Ninja Learn | نینجا لرن pinned «اگه تجربه ای دارید یا چیزی دوست دارید به برنامه نویسای کشورتون بگید میتونید به پیوی من بفرستید تو کانال قرار بدم 👇 @mohammad_strout 🔆 CHANNEL | GROUP»
Ai will take all our jobs it so over 😔


🔆 CHANNEL | GROUP
🥰5🤣21
خب خب JWT چیه؟

ـJWT یا JSON Web Token یک استاندارد برای انتقال امن و فشرده اطلاعات بین کلاینت و سروره. این توکن‌ها معمولاً برای احراز هویت و مجوز دسترسی استفاده می‌شن.

از چه بخش‌هایی تشکیل شده؟
ـJWT از سه بخش اصلی تشکیل شده:

ـHeader 🧾
شامل نوع توکن (معمولاً JWT) و الگوریتم امضا مثل HS256 یا RS256.
{ 
"alg": "HS256",
"typ": "JWT"
}

ـPayload 🎒
شامل اطلاعاتی که باید منتقل بشه (Claims). این Claims ها می‌تونن عمومی باشن (مثل sub یا iat) یا سفارشی (مثل username).
{ 
"sub": "1234567890", "name": "John Doe", "admin": true
}

ـSignature
ترکیبی از Header و Payload که با استفاده از یک کلید خصوصی یا secret امضا شده. این بخش تضمین می‌کنه که توکن دستکاری نشده.
ـJWT این سه بخش رو با نقطه (.) جدا می‌کنه، مثلاً:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

هر بخش چطور ساخته می‌شه؟
ـHeader:
به فرمت JSON نوشته و سپس با Base64Url رمزگذاری می‌شه.

ـPayload:
دقیقاً مثل Header با Base64Url رمزگذاری می‌شه.

ـSignature:

از الگوریتم تعریف‌شده در Header استفاده می‌کنه و ترکیب base64(Header) + "." + base64(Payload) رو امضا می‌کنه.

نکته: در Base64Url، کاراکترهای "+" و "/" به "-" و "_" تبدیل میشن و "=" حذف می‌شه تا توکن برای استفاده در URL مناسب بشه.
چطور اعتبارسنجی می‌شه؟
برای اعتبارسنجی JWT:
ـHeader و Payload دیکد می‌شن
و محتوا با استفاده از Base64Url خونده می‌شه.

امضا بررسی می‌شه
سرور با استفاده از secret key یا public key امضا رو بررسی می‌کنه. اگه امضا درست باشه، یعنی توکن دستکاری نشده.

ـClaims ها چک می‌شن

ـExpiration (exp):
بررسی می‌شه که توکن منقضی نشده باشه. پیشنهاد می‌کنم exp Access Token بین ۱۵ دقیقه تا ۱ ساعت باشه.

ـIssuer (iss):
مطمئن می‌شه که توکن از سرور معتبری صادر شده.


ـAudience (aud):
بررسی می‌کنه که توکن برای اپلیکیشن درستی صادر شده باشه.
این فرآیند به طور خودکار توسط کتابخونه‌های JWT انجام می‌شه و نیازی نیست برنامه‌نویس کاری انجام بده.


اشتباهات رایج در استفاده از JWT 🚨
ذخیره توکن در LocalStorage
این روش ناامنه و ممکنه در برابر حملات XSS آسیب‌پذیر باشه. بهتره به جای اون از Secure Cookies استفاده بشه.

نکته تکمیلی: برای امنیت بیشتر، کوکی‌ها رو با ویژگی‌های HttpOnly و SameSite تنظیم کن.
استفاده نادرست از JWT
ـJWT بیشتر برای احراز هویت و انتقال اطلاعات و دادن دسترسی با عمر محدود مناسبه. استفاده از اون برای مواردی مثل مدیریت طولانی‌مدت Session توصیه نمی‌شه.

نداشتن Expiration (exp)
توکن‌های بدون تاریخ انقضا خطرناک هستن چون هیچ‌وقت منقضی نمی‌شن و ممکنه به دست افراد اشتباه بیفتن. برای Refresh Token پیشنهاد می‌کنم ۷ تا ۳۰ روز exp در نظر بگیرید تا کاربرانی که از سیستم خارج نشده‌اند، تجربه بهتری داشته باشند.

عدم اعتبارسنجی Claims ها
حتماً Claims مثل iss یا aud رو بررسی کن تا مطمئن بشی توکن از منبع معتبری صادر شده.

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

امید وارم مفید بوده باشه :)

#programming #برنامه_نویسی #jwt



🔆 CHANNEL | GROUP
🔥14👍92
خب خب خب gRPC چیه؟ 🛰

اگه تاحالا با سیستم‌های توزیع‌شده کار کرده باشی، احتمالاً فهمیدی که یکی از چالش‌هاش ارتباط بین سرویس‌هاست. اینجا gRPC میاد وسط. یه فریم‌ورکه برای ارتباط سریع و بهینه بین سرویس‌ها.
gRPC (Google Remote Procedure Call)

یه سیستم Remote Procedure Call یا همون RPC مدرنه که گوگل توسعه داده. تو این مدل، می‌تونی توابعی رو از یه سرویس صدا بزنی انگار که دارن تو همون سرویس لوکال اجرا می‌شن.

چرا gRPC؟

دلیل‌هاش زیاده:

سرعت بالا 🚀
ـgRPC از HTTP/2 استفاده می‌کنه که خیلی سریع‌تر از HTTP/1.1 عادیه. این یعنی درخواست‌ها موازی می‌شن، فشرده‌سازی هدرها انجام می‌شه و ارتباطات پایدار (persistent connections) دارن.
استفاده از Protocol Buffers 📦
ـgrpc به جای JSON یا XML، از ProtoBuf استفاده می‌کنه که فشرده‌تر، سریع‌تر و بهینه‌تره. این باعث کاهش پهنای باند مورد نیاز می‌شه که برای سیستم‌های توزیع‌شده فوق‌العاده مهمه.
پشتیبانی از استریم 📡
ـgRPC بهت اجازه می‌ده ارتباط دوطرفه (bidirectional streaming) داشته باشی. این یعنی هم کلاینت و هم سرور می‌تونن هم‌زمان داده بفرستن و دریافت کنن.
زبان‌باز بودن 🌍
ـgRPC از خیلی زبان‌ها مثل Go، Python، Java، C# و... پشتیبانی می‌کنه.


قابلیت مقیاس‌پذیری 🔄
ـgRPC به دلیل طراحی کارآمد و استفاده از HTTP/2 برای سیستم‌هایی که قراره در آینده بزرگ بشن، انتخاب خیلی خوبیه.


ـgRPC چطور کار می‌کنه؟
برای استفاده از gRPC، باید با مفهوم Protocol Buffers (یا همون ProtoBuf) آشنا باشی. ProtoBuf یه فرمت برای تعریف داده‌ها و توابعه. یه فایل .proto می‌نویسی و توش مشخص می‌کنی که چه متدهایی داری و ورودی و خروجی‌هاش چیه. بعدش gRPC این فایل رو به کدی برای زبان دلخواهت تبدیل می‌کنه.

مثلاً:
syntax = "proto3";  

service Greeter {
rpc SayHello (HelloRequest) returns (HelloResponse);
}

message HelloRequest {
string name = 1;
}

message HelloResponse {
string message = 1;
}

اینجا یه متد SayHello داریم که یه درخواست می‌گیره و یه پاسخ برمی‌گردونه.

کجاها از gRPC استفاده کنیم؟
ـgRPC معمولاً تو سیستم‌های توزیع‌شده استفاده می‌شه، مثل:

ارتباط بین میکروسرویس‌ها 🔗
اگه داری میکروسرویس‌ها رو مدیریت می‌کنی، gRPC می‌تونه ارتباط بینشون رو سریع‌تر و ساده‌تر کنه.


سیستم‌هایی با نیاز به استریم 🎥
مثل چت‌روم‌ها، بازی‌های آنلاین یا هر جایی که داده‌ها باید به‌صورت زنده رد و بدل بشن.


سیستم‌های چندزبانه 🌐
چون gRPC از زبان‌های مختلف پشتیبانی می‌کنه، تو سیستم‌های چندزبانه عالیه.


کجاها از gRPC استفاده نکنیم؟

وب اپلیکیشن‌های عمومی 🌍:
اگه می‌خوای چیزی مثل REST API برای کلاینت‌های مرورگر بسازی، gRPC خیلی انتخاب مناسبی نیست چون مرورگرها به طور مستقیم با gRPC سازگار نیستن. البته می‌تونی از gRPC-Web استفاده کنی تا این محدودیت رو رفع کنی.
وقتی که نیاز به دیباگ ساده داری 🛠️:
ـJSON رو راحت می‌تونی تو مرورگر یا ابزارهای مختلف دیباگ کنی، ولی ProtoBuf این‌طور نیست و نیاز به ابزارهای خاص خودش داره.
پروژه‌های کوچیک 🪶:
برای پروژه‌هایی که سرعت یا مقیاس‌پذیری خیلی مهم نیست، پیچیدگی gRPC ممکنه بیش از حد باشه. REST API یا حتی JSON-RPC می‌تونه ساده‌تر و کافی باشه.

اشتباهات رایج در استفاده از gRPC 🚨
نادیده گرفتن محدودیت مرورگرها:
مرورگرها مستقیم gRPC رو ساپورت نمی‌کنن و باید از gRPC-Web استفاده کنی.

بی‌توجهی به اندازه پیام‌ها:
اگه پیام‌های بزرگ یا سنگین می‌فرستی، ممکنه gRPC بهینه نباشه.

عدم استفاده از استریم وقتی لازمه:
بعضی وقت‌ها دولوپرها استریم رو نادیده می‌گیرن و همین باعث می‌شه از پتانسیل gRPC کامل استفاده نکنن.

تنظیم نکردن Timeouts و Retries⏱️:
فراموش کردن تنظیم timeouts و retries می‌تونه باعث مشکلات بزرگی در ارتباط بین سرویس‌ها بشه.

جمع‌بندی 🎯
ـgRPC یه ابزار قدرتمنده که سرعت و کارایی بالایی به ارتباط بین سرویس‌ها می‌ده. ولی باید دقیق و هوشمندانه ازش استفاده کنی. اگه تو جای درست به کارش بگیری، می‌تونه کلی از مشکلات سیستم‌های توزیع‌شده رو برات حل کنه.

یادت باشه: هر ابزاری جای خودش رو داره. با انتخاب هوشمندانه، می‌تونی بهترین نتیجه رو بگیری.


#programming #web #grpc



🔆 CHANNEL | GROUP
👍1610🔥31👏1
دوستان اگه تاالان محتوای کانال براتون مفید بوده و تونستم به علمتون کمی اضافه کنم.
ممنون میشم با بوست کردن یا استار زدن از منو پستام حمایت کنید :) ❤️

🔗 لینک بوست 👇
https://t.iss.one/boost/ninja_learn_ir


🔆 CHANNEL | GROUP
18👌4
خیلی ممنون که تابه امروز کنارم بودید :)❤️

اگه نمیدونید چیه امار چنلمونه تواین مدتی که فعالیت میکنم

اینم لینک رباته برای گرفتن امار 👇
@telemetr_io_bot


🔆 CHANNEL | GROUP
17🤩1
😂😂


🔆 CHANNEL | GROUP
🤣161👍1🔥1
واقعا نفهمیدیم کی ۲۰۲۴ تموم شد هعیییییی
👍22
پست پیشنهادیتون چیه دوستان؟
(لطفا پیشنهادات مثل سری پیش خفن باشه)
🔥6
خب خب خب Django Channels چیه؟ و چرا من ازش خوشم نمیاد

قبل از اینکه با هم بریم سراغ Django Channels، یه کم درباره WebSocket بگیم که اصلاً بدونیم داریم درباره چی حرف می‌زنیم. خب، WebSocket یه پروتکل که بهت اجازه میده ارتباط دوطرفه و دائمی بین کلاینت و سرور داشته باشی. یعنی چی؟ یعنی مثلاً تو یه اپلیکیشن چت، به جای اینکه هر چند ثانیه یه بار درخواست بفرستی "چیزی جدید اومده؟"، سرور خودش هر وقت یه پیام جدید داشت، بلافاصله می‌فرسته سمتت 🚀.

حالا Django Channels چی میگه؟ 🤔
ـDjango Channels یه ابزار تو اکوسیستم Djangoئه که میاد پشتیبانی از WebSocket، پروتکل‌های real-time و کارای async رو به پروژه‌هات اضافه می‌کنه. به زبان ساده، اگه Django عادی رو یه "خیابون یک‌طرفه" فرض کنیم، Channels میاد این خیابون رو دوطرفه می‌کنه. این یعنی می‌تونی کارایی مثل:

چت real-time 💬


نوتیفیکیشن‌های فوری 🔔


استریم داده (مثل قیمت‌های ارز دیجیتال) 📈


و...

رو خیلی راحت‌تر با Django انجام بدی.

خب پس مشکلش چیه؟ چرا من ازش خوشم نمیاد؟ 🤷‍♂️

از دور که نگاه می‌کنی، Channels خیلی جذاب به نظر میاد، ولی وقتی می‌خوای باهاش کارکنی، مشکلات خودش رو نشون میده:

1⃣ پیچیدگی توی تنظیمات 😵‍💫
ـDjango همیشه به خاطر سادگی معروف بوده، ولی Channels میاد این سادگی رو خراب می‌کنه خیلی خراب میکنه. باید ASGI رو راه بندازی، Redis نصب کنی، routing یاد بگیری، و کلی تنظیمات دیگه انجام بدی. یه پروژه ساده که با Django راحت بود، یهو برات میشه یه جنگل از تنظیمات.

نکته: از Django 4.0 به بعد، پشتیبانی از ASGI مستقیم داخل هسته Django اومده، پس برای پروژه‌های ساده شاید نیاز نباشه کل پروژه رو وابسته به Channels کنی.

2⃣ وابستگی به Redis 🤦‍♂️
یکی از مشکلات بزرگ Channels اینه که برای مدیریت eventها و ارتباط‌ها حتماً نیاز به Redis داره. خب چرا؟ دلیلش اینه که Redis به‌عنوان message broker استفاده میشه تا پیام‌ها بین کلاینت‌ها و سرور مدیریت بشه. ولی اگه پروژه کوچیک باشه، این وابستگی می‌تونه دردسرساز بشه.

جایگزین: می‌تونی از RabbitMQ یا حتی راه‌حل‌های ساده‌تر مثل In-Memory Layers برای پروژه‌های سبک استفاده کنی.


3⃣ محدودیت توی scale کردن 😩
اگه پروژه کوچیک باشه، Channels بد نیست. ولی وقتی تعداد کاربران زیاد میشه و حجم درخواست‌ها بالا میره، Channels سریع از نفس می‌افته. این محدودیت بیشتر به خاطر پیچیدگی WebSocket و محدودیت‌های سرورهای تک رشته ای هست تا خود Channels. برای پروژه‌های بزرگ و real-time محور، ابزارای دیگه‌ای مثل Socket.IO یا FastAPI خیلی بهتر عمل می‌کنن.

4⃣ مشکلات performance 🚨
حتی اگه پروژه خیلی هم بزرگ نباشه، Channels برای real-time پروژه‌های سنگین خوب عمل نمی‌کنه. کارای پیچیده async و ارتباطات real-time می‌تونن سرور رو داغون کنن. البته با تنظیم درست workerها و Redis channel layers می‌تونی بخشی از این مشکلات رو کم کنی، ولی باز هم کار اضافه‌ست.

5⃣ کمبود مستندات و منابع آموزشی درست و حسابی 📚
یکی دیگه از مشکلات اینه که منابع آموزشی کامل و به‌روزی برای Channels خیلی کمه. هر وقت گیر کنی، یا باید بری توی GitHub دنبال issueها، یا دست به دامن دیگران بشی. این باعث میشه زمان زیادی صرف حل مشکلات کنی.

خب حالا راه‌حل چیه؟ 💡
اگه بخوای real-time کار کنی، اینا می‌تونن گزینه‌های بهتری باشن:

ـFastAPI: اگه دنبال سرعت، سادگی و پرفورمنس خوب هستی، FastAPI انتخاب فوق‌العاده‌ایه. با WebSocket خیلی راحت کار می‌کنه و خبری از دردسرای Channels نیست 🚀.

ـSocket.IO: این یکی برای پروژه‌های real-time شاهکاره. خیلی ابزارای متنوع داره و با Node.js هم عالی مچ میشه.


جمع‌بندی 🎯
ـDjango Channels می‌تونه برای پروژه‌های کوچیک و ساده مناسب باشه، ولی اگه بحث scale، پرفورمنس یا راحتی کار مطرح باشه، اصلاً گزینه خوبی نیست. من از پیچیدگی‌ها و محدودیت‌هاش خسته شدم و به جای اون سراغ ابزارای دیگه رفتم.
نظر تو چیه؟ Django Channels تا حالا اذیتت کرده یا ازش خوشت میاد؟ بگو ببینم چی تو ذهنت می‌گذره🧐


#programming #web #django



🔆 CHANNEL | GROUP
👍251👎1
پست بعدی یکم راجب کامپایلر صحبت کنم؟
👍23👎2
از محتوای کانال راضی هستید؟
Anonymous Poll
84%
بله 😃
8%
خیر 🫤
8%
تو کامنتا میگم 💬
6
Ninja Learn | نینجا لرن
از محتوای کانال راضی هستید؟
دوستان اگه عیبی هست بگید درستش کنم
نظراتتون خیلی ارزشمنده برام
8
درک نمیکنم چرا یه کورس خوب برای Fastapi نباید باشه 🙄
👍23🤣2