❤️ یلدا مبارک همگی

🔆 CHANNEL | GROUP

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

ـRedis یکی از سریع‌ترین و محبوب‌ترین ابزارهای in-memory data store تو دنیاست. این ابزار هم به عنوان database، هم cache و هم message broker استفاده می‌شه . اما این که هرجایی ازش استفاده کنی، اصلا کار درستی نیست. تو این پست می‌خوایم بررسی کنیم کجا Redis انتخاب خوبیه و کجا بهتره سراغش نری.

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

1⃣ ـCaching 🗃️
وقتی یه داده رو مدام از دیتابیس اصلی می‌خونی و نیاز به سرعت بالا داری، Redis می‌تونه به عنوان یه کش عالی عمل کنه. مثلا:
کش کردن نتایج کوئری‌های سنگین 🔍
ذخیره صفحات رندر شده 📄
ذخیره session data برای کاربرها 👤

2⃣ـ Real-Time Analytics 📊
اگه می‌خوای یه داشبورد real-time بسازی که اطلاعات رو لحظه‌ای نشون بده، Redis با ساختارهای داده سریعش (مثل sorted sets) می‌تونه خیلی کمک‌کننده باشه.

3⃣ ـRate Limiting 🚦
وقتی می‌خوای تعداد درخواست‌های کاربرها رو محدود کنی، مثلا برای جلوگیری از حملات DDoS یا اسپم، Redis یه گزینه عالیه.

4⃣ Pub/Sub Systems 📩
برای ارتباط بین سرویس‌ها یا ارسال پیام در سیستم‌های real-time مثل چت‌ها، Redis با قابلیت publish/subscribe خیلی خوب عمل می‌کنه.

5⃣ـ Leaderboard ها و سیستم‌های امتیازدهی 🏆
ساختار داده sorted sets برای ساختن رتبه‌بندی‌های real-time (مثل امتیاز بازیکن‌ها) ایده‌آله.

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

1⃣ ذخیره‌سازی داده‌های پایدار 🛠
ـRedis یه in-memory database هست. یعنی داده‌ها رو تو حافظه ذخیره می‌کنه، نه روی دیسک. اگه برق بره یا سیستم ری‌استارت بشه، داده‌ها ممکنه از دست برن. برای داده‌هایی که نمی‌خوای از دست برن، از دیتابیس‌هایی SQL مثل PostgreSQL یا Mysql یا ... استفاده کن.

2⃣ حجم‌های بالا 📦
اگه حجم داده‌هات خیلی زیاده و رم کافی نداری، Redis انتخاب خوبی نیست. مثلا ذخیره‌سازی داده‌های سنگین مثل فایل‌ها یا لاگ‌ها.

3⃣ آنالیزهای پیچیده 🤔
اگه نیاز به کوئری‌های پیچیده داری (مثل join یا aggregation)، بهتره از دیتابیس‌های relation-based مثل MySQL یا PostgreSQL استفاده کنی.

اشتباهات رایج در استفاده از Redis ‼️

1⃣ استفاده از Redis برای همه‌چیز ⚠️
خیلیا وقتی Redis رو یاد می‌گیرن، فکر می‌کنن باید همه‌چیز رو توش ذخیره کنن. ولی این ابزار برای همه نوع داده مناسب نیست. مثلا برای ذخیره تراکنش‌های مالی یا داده‌های حساس، بهتره از دیتابیس‌های دیگه استفاده کنی.

2⃣ تنظیم نکردن TTL ⏳
اگه از Redis به عنوان کش استفاده می‌کنی ولی TTL (زمان انقضای داده‌ها) رو تنظیم نکنی، ممکنه حافظه پر بشه و سیستم کرش کنه.

3⃣ نادیده گرفتن محدودیت رم 🧠
ـRedis همه داده‌ها رو تو رم ذخیره می‌کنه. اگه حجم داده‌هات از ظرفیت رم بیشتر بشه، سیستم به مشکل می‌خوره.

4⃣ مدیریت نکردن replication 🔄
برای سیستم‌های حساس، باید replication رو تنظیم کنی تا در صورت خرابی سرور اصلی، داده‌ها از بین نرن.

5⃣ عدم مانیتورینگ 📡
خیلی‌ها Redis رو راه می‌ندازن ولی هیچ وقت مانیتور نمی‌کنن که چقدر حافظه مصرف می‌شه یا چقدر latency داره. این اشتباه می‌تونه باعث مشکلات جدی بشه.

پیشنهاد: قبل از استفاده از Redis، نیازمندی‌هات رو مشخص کن و مطمئن شو این ابزار برای پروژه‌ت مناسبه.

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

#برنامه_نویسی #db #redis

🔆 CHANNEL | GROUP

پست بعدی چی باشه دوستان ؟
(پیشنهاد خفن بدید)

اگه تجربه ای دارید یا چیزی دوست دارید به برنامه نویسای کشورتون بگید میتونید به پیوی من بفرستید تو کانال قرار بدم 👇

@mohammad_strout

🔆 CHANNEL | GROUP

دوره ها ازت برنامه نویس نمی سازن بلکه پروژه هایی که میزنی ازت برنامه نویس در میاره.

⬅️ «از اشکان»

➖➖➖➖➖➖➖➖

🔆 CHANNEL | GROUP

اگه توصیه ها زیاد بود هرروز یدونه بزارم یا چندتا ؟ 🤔

یدونه 👍 چندتا 👎

➖➖➖➖➖➖➖➖

🔆 CHANNEL | GROUP

باقیمت مفت کار نکن، هزینه زحمتاتو بگیر

«از آرش»

➖➖➖➖➖➖➖➖

🔆 CHANNEL | GROUP

از شنبه شروع نکنید.

«از مرد کامپیوتری»

➖➖➖➖➖➖➖➖

🔆 CHANNEL | GROUP

سه نفر بشید هر روز برید دیسکورد مایک رو ببندید و تمرین کنید دوره ببینید داکیومنت یا هر کاری که میخواید رو بکنید

تکی سخته یکم پیش بردن، نسبت به چند نفری، برای اول کار
اینجوری اگه یه روز کار نکنی آبروی آدم پیش اون 2 نفر میره و اون دو نفر زوری میارنت اون روز

«از خسرو»

➖➖➖➖➖➖➖➖➖

🔆 CHANNEL | GROUP

حقیقتا بنظر خود من روش بهتری وجود داره. چه روش بهتری؟
بااون تیمی که داری یا دوستایی که دارید یه منبع اموزشی مثل کتاب ، داکیومنت هرچی مشخص کنید و بگید تا جمعه هفته بعد تا اینجاشو بخونید همگی تا وقتی که تموم شه.
اخر هفته هم میاید توی یه میتینگی نکاتی که فهمیدی رو میگید به هم و درواقع share Knowledge میکنید.
اخر سرهم میتونید با توجه به چیزایی که یاد گرفتید یه پروژه بیارید بالا یا اصلا مقاله بنویسید که خیلی برای رزومتون خوبه.

➖➖➖➖➖➖➖➖➖

🔆 CHANNEL | GROUP

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

هیچوقت جنس پیچیدگی که دیزاین پترن به کد شما اضافه میکنه رو عمیقا متوجه نشده بودم (یعنی نمیتونستم توضیحش بدم)، تا اینکه این ویدیو رو دیدم:

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

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

@PyBackendHub

Ai will take all our jobs it so over 😔

➖➖➖➖➖➖➖➖➖

🔆 CHANNEL | GROUP

خب خب 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

نظرتون درمورد بنر کانال چیه؟ 😁

خب خب خب 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

دوستان شیرو ریکشن فراموش نشه 😊❤️

دوستان اگه تاالان محتوای کانال براتون مفید بوده و تونستم به علمتون کمی اضافه کنم.
ممنون میشم با بوست کردن یا استار زدن از منو پستام حمایت کنید :) ❤️

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

➖➖➖➖➖➖➖➖➖

🔆 CHANNEL | GROUP

از اونجایی که بعضی هاتون ممکنه متوجه نشده باشید که چه اتفاقی داره میوفته
پیشنهاد میکنم ویدیو دوست خوبم سیروان جان رو حتما ببینید

مشاهده ویدیو

➖➖➖➖➖➖➖➖➖

🔆 CHANNEL | GROUP