💎 معرفی node.js 💎


🔬 تاریخچه

تا قبل از سال 2009 اجرای کد های جاوااسکریپت فقط داخل مرورگر ممکن بود.

یعنی برای اینکه یه سری کد جاوااسکریپت رو اجرا کنی باید کد های جاوااسکریپتی رو می‌نوشتی و توی یه فایل html حالا یا به صورت embedded یا به صورت رفرنس با تگ script اجرا میکردی.

دلیلش این بود که همه مرورگر ها داخل خودشون یه قطعه نرم‌افزاری داشتن به اسم "موتور جاوااسکریپت" این موتور جاوااسکریپت وظیفه اجرای کد های جاوااسکریپتی که توسط مرورگر دانلود میشدن رو بر عهده داشت.

هر مرورگری موتور جاوااسکریپت خودشو داره.
گوگل کروم موتور V8 رو داره، فایرفاکس spider monkey و ...


🎉 تولد nodejs

توی سال 2009 برنامه نویس باهوشی به اسم Ryan Dahl به فکرش زد که چقدر خوب میشد که بتونیم کد های جاوااسکریپت رو خارج از مرورگر و روی سرور اجرا کنیم و اومد موتور جاوااسکریپت V8 رو که توسط گوگل به صورت اوپن سورس (open source) منتشر شده بود رو برداشت و توی یه برنامه سی پلاس پلاس (++C) قرار داد و اسم اون برنامه رو گذاشت Node.js.

در واقع نود جی اس یه برنامه ای هست که بهش میگن ران تایم (Runtime) برای اجرای کد جاوااسکریپت خارج از مرورگر و سمت سرور برای توسعه سمت سرور

ران تایم Node.js مثل یه موتور قدرتمنده که برنامه‌های جاوا اسکریپت رو به حرکت درمیاره.

فرض کن یه ماشین مسابقه‌ای داری. ماشین خیلی خفنه اما بدون یه موتور قوی که بهش نیرو بده، نمی‌تونه مسابقه بده.

ران تایم Node.js هم دقیقا همین کارو برای برنامه‌های جاوا اسکریپت می‌کنه.

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

این کدها می‌تونن هر کاری انجام بدن، از ساختن یه وبسایت ساده تا مدیریت یه شبکه‌ی اجتماعی پیچیده.

❓چرا Node.js انقدر محبوب شده؟

1⃣ سرعت عمل بالا: Node.js خیلی سریع‌تر از خیلی از زبان‌های برنامه‌نویسی دیگه کارها رو انجام می‌ده.

2⃣ جاوا اسکریپت همه جا هست: اگه جاوا اسکریپت بلد باشی، یادگیری Node.js خیلی راحت‌تره.

3⃣ آسون و سبک: Node.js خیلی سبک و راحته و برای پروژه‌های کوچک و بزرگ قابل استفاده است.

4⃣ جامعه‌ی بزرگ: Node.js یه جامعه‌ی خیلی بزرگ و فعال داره که همیشه آماده‌ی کمک بهت هستن.

پس اگه می‌خوای برنامه‌نویسی بک‌اند رو شروع کنی، Node.js یکی از بهترین گزینه‌هاست. ✔️

حالا اگه سوالی داشتی، حتما بپرس. 😁

@ninja_learn_ir

دوتا قسمت دیگه هم از دوره DRF آپلود شد 😁

https://youtu.be/1PNnenZiAxU?si=x3hx9DNA1bCgwixF

@ninja_learn_ir

هرچی بگم از طنز ماجرا کم میشه :)

کی نکتش رو متوجه شد؟ 😂

بچه ها میخوام هر روز توی یه پست، خلاصه ای از کتاب REST API Design Rulebook رو واستون بذارم تا با اصول و قائده طراحی api آشنا بشید

نظری چیزی دارید کامنت کنید
همه‌رو میخونم 🌹

هر روز بین ساعت ۷ و ۸ میذارم نه سیخ بسوزه نه کباب 😁

File PDF REST API Design Rulebook

#file

سلامتی آزادی سلطان 🍾

💎 هدر X-Powered-By 💎

فرض کن یه ماشین خیلی خوشگلی داری. روی این ماشین یه برچسب کوچولو هست که نوشته "ساخت ایران". این برچسب به همه میگه که ماشینت ایرانیه.

هدر X-Powered-By هم دقیقا همین کارو برای وبسایت ها انجام میده. این هدر یه برچسب کوچولوئه که به همه میگه این وبسایت با چه زبان/فریمورکی ساخته شده.

مثلاً ممکنه بنویسه "ساخته شده با وردپرس" یا "ساخته شده با جاوا اسکریپت".


❓چرا مهمه؟

خب، این برچسب کوچولو یه دردسر کوچولو هم داره!

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


✅ مثال:

فرض کن یه وبسایت فروشگاهی با وردپرس ساخته شده.

یه هکر با دیدن هدر X-Powered-By میفهمه که این وبسایت با وردپرس ساخته شده.

بعدش میره تو اینترنت و دنبال یه راه برای هک کردن وردپرس میگرده. اگه این راه رو پیدا کنه، میتونه وارد وبسایت بشه و اطلاعات کارت های اعتباری مشتری ها رو بدزده.


❓چه کار کنیم که امنیت وبسایتمون بیشتر بشه؟

1⃣ این هدر رو مخفی کنیم: خیلی از زبان ها و فریمورک هایی که برای ساخت وبسایت استفاده میشن، این امکان رو بهمون میدن که این هدر رو مخفی کنیم. با این کار هکرها نمی تونن بفهمند که وبسایتمون با چه نرم افزاری ساخته شده.

2⃣ زبان/فریمورک مون رو همیشه آپدیت کنیم: هر زبان و فریمورکی ممکنه ایرادهایی داشته باشه. توسعه دهنده ها با آپدیت کردن این ایرادها رو برطرف میکنن. پس اگه زبان و فریمورکمون رو همیشه آپدیت کنیم، هکرها نمیتونن از این ایرادها برای هک کردن وبسایتمون استفاده کنند.

3⃣ از فایروال استفاده کنیم: فایروال مثل یه نگهبان برای وبسایتمون عمل میکنه. فایروال جلوی حملات هکرها رو میگیره و اجازه نمیده که به وبسایتمون آسیب برسونن.

☑️ خلاصه داستان:
هدر X-Powered-By یه برچسب کوچولوئه که به هکرها اطلاعات میده. برای اینکه وبسایتمون امن باشه باید این برچسب رو مخفی کنیم، زبان/فریمورک مون رو آپدیت کنیم و از فایروال استفاده کنیم.

🔴 نکته مهم:
امنیت وبسایت فقط به این هدر ختم نمیشه. خیلی چیزای دیگه هم هست که باید بهشون توجه کرد. مثلاً استفاده از رمزهای عبور قوی، بکاپ گرفتن از اطلاعات وبسایت و...

سوالی دارید بپرسید 🌹

پست فردا راجب پکیج debug toolbar باشه؟

#fun

Iran be like 😂

@ninja_learn_ir

📕کتاب REST API Design Rulebook

📌 فصل اول: معرفی (Introduction)

📍پارت: اول

#کتاب

💎 سلام به دنیای اینترنت 💎

وب از یه گروه به اسم "داده‌گیری و کنترل" توی سازمان تحقیقاتی اروپا برای فیزیک هسته‌ای (CERN) در ژنو، سوئیس شروع شد.
این ماجرا از وقتی شروع شد که یه برنامه‌نویس کامپیوتر یه ایده هوشمندانه برای یه پروژه نرم‌افزاری جدید به ذهنش رسید.
توی دسامبر ۱۹۹۰، برای اینکه به اشتراک‌گذاری اطلاعات راحت‌تر بشه، "تیم برنرز-لی" یه پروژه غیرانتفاعی رو شروع کرد که اسمش رو "WorldWideWeb" گذاشت.
بعد از حدود یک سال کار مداوم روی پروژه‌اش، برنرز-لی اینا رو اختراع و پیاده‌سازی کرد:
• شناسه منبع یکتا (URI)، یه فرمت که به هر سند وب یه آدرس یکتا میده.
• پروتکل انتقال ابرمتن (HTTP)، یه زبان پیام‌محور که کامپیوترها می‌تونن ازش برای ارتباط توی اینترنت استفاده کنن.
• زبان نشانه‌گذاری ابرمتن (HTML)، برای نمایش اسناد اطلاعاتی که حاوی لینک‌هایی به اسناد مرتبط هستن.
• اولین سرور وب.
• اولین مرورگر وب، که برنرز-لی اسمش رو هم "WorldWideWeb" گذاشت و بعداً به "Nexus" تغییر داد تا با خود وب اشتباه گرفته نشه.
• اولین ویرایشگر HTML به صورت WYSIWYG (یعنی چیزی که می‌بینی همونه که دریافت می‌کنی)، که توی خود مرورگر ساخته شده بود.

در ۶ آگوست ۱۹۹۱، تیم برنرز-لی توی اولین صفحه وب نوشت:
"WorldWideWeb (W3) یه ابتکار برای بازیابی اطلاعات هایپرمیدیا توی یه منطقه وسیع هست که هدفش دسترسی عمومی به یه دنیای بزرگ از اسناد هست."
از همون لحظه، وب شروع به رشد کرد، گاهی به‌صورت تصاعدی. طی پنج سال، تعداد کاربران وب به ۴۰ میلیون نفر رسید. یه زمانی بود که این تعداد هر دو ماه دو برابر می‌شد. همون "دنیای اسناد" که برنرز-لی توصیف کرده بود، واقعاً در حال گسترش بود.

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

@ninja_learn_ir

💎 ابزار Django debug toolbar 💎
امروز می‌خوایم دربارهٔ یه ابزار فوق‌العاده برای دیباگ کردن توی پروژه‌های جنگویی صحبت کنیم: Django Debug Toolbar. این ابزار می‌تونه بهتون کمک کنه تا جزئیات دقیق درخواست‌ها، کوئری‌های پایگاه داده، قالب‌ها و خیلی چیزای دیگه رو ببینید و مشکلات پروژه‌تون رو سریع‌تر پیدا و برطرف کنید. توی این پست قراره قدم به قدم نحوهٔ نصب و استفاده از این ابزار رو توضیح بدم. 🚀


1. نصب Django Debug Toolbarبرای شروع، باید Django Debug Toolbar رو نصب کنید :
این ابزار به‌راحتی از طریق pip قابل نصب هست. کافیه ترمینال رو باز کنید و این دستور رو وارد کنید: 💻

pip install django-debug-toolbar

با این کار، پکیج مورد نیاز نصب میشه. ✅

2. اضافه کردن به تنظیمات پروژه  :
حالا باید Django Debug Toolbar رو به تنظیمات پروژهٔ جنگوییتون اضافه کنید. برای این کار، فایل settings.py رو باز کنید و این کدرو رو به تنظیمات اضافه کنید: 🛠️

اضافه کردن به INSTALLED_APPS:

INSTALLED_APPS = [
    ...
    'debug_toolbar',
]

اضافه کردن به MIDDLEWARE:

MIDDLEWARE = [
    ...
    'debug_toolbar.middleware.DebugToolbarMiddleware',
]

با این کار، Django Debug Toolbar به پروژه‌تون اضافه می‌شه و میتونید ازش استفاده کنید. 🎉
3. تنظیم آیپی‌های مجازبرای اینکه این ابزار بتونه توی مرورگر نمایش داده بشه، باید آیپی‌هایی که برای دیباگ تولبار مجاز هستن رو تنظیم کنید. معمولاً برای توسعه توی لوکال از 127.0.0.1 استفاده می‌کنیم. بنابراین، این خط رو به settings.py اضافه کنید: 🌐

INTERNAL_IPS = [
    '127.0.0.1',
]

این تنظیمات به تولبار میگه که فقط وقتی از این آیپی درخواست میاد، نمایش داده بشه. 👀

4. اضافه کردن URLهای مربوطه حالا باید URLهای مربوط به Django Debug Toolbar رو به پروژه‌تون اضافه کنید. برای این کار، فایل urls.py رو باز کنید و این خطوط رو اضافه کنید: 🌍

django.conf import settings
from django.conf.urls import include
from django.urls import path

if settings.DEBUG:
    import debug_toolbar
    urlpatterns = [
        path('__debug__/', include(debug_toolbar.urls)),
    ] + urlpatterns

این کار باعث می‌شه که وقتی پروژه توی حالت DEBUG هست، تولبار فعال بشه و URLهای مربوط به اون هم در دسترس باشن. 🔧

5. استفاده از Django Debug Toolbar حالا دیگه کارمون تمومه! کافیه سرور جنگو رو دوباره راه‌اندازی کنید و یکی از صفحات پروژه‌تون رو باز کنید. اگه همه چیز درست پیش رفته باشه، یه نوار ابزار (Toolbar) در سمت راست صفحه نمایش داده می‌شه.
این نوار ابزار اطلاعات خیلی مفیدی دربارهٔ درخواست HTTP، کوئری‌های پایگاه داده، قالب‌ها، تنظیمات و موارد دیگه بهتون نشون میده.

مثلاً با استفاده از این ابزار می‌تونید ببینید چه کوئری‌هایی به پایگاه داده زده شده، چقدر زمان برده و جای بهینه‌سازی داره یا نه.
همچنین میتونید اطلاعات مربوط به درخواست‌ها و پاسخ‌های HTTP رو به‌دست بیارید و از نحوهٔ پردازش درخواست‌ها در سمت سرور مطلع بشید. 🔍

جمع‌بندی ✅
فهمیدیم Django Debug Toolbar ابزاری قدرتمنده که میتونه خیلی بهتون کمک کنه تا پروژه‌هاتون رو بهینه تر کنید و مشکلات رو سریع‌ تر پیدا کنید.
پیشنهاد میکنم حتماً امتحانش کنید و ببینید چقدر کارتون رو راحت‌تر می‌کنه. 💪

دراینده یه ویدیو هم درمورش ضبط میکنیم

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

@ninja_learn_ir

📕 کتاب REST API Design Rulebook

📌 فصل اول: معرفی (Introduction)

📍پارت: دوم

#کتاب

💎 معماری وب 💎

در اواخر سال ۱۹۹۳، "روی فیلدینگ"، یکی از بنیان‌گذاران پروژه سرور HTTP آپاچی، نگران مشکل مقیاس‌پذیری وب شد.
بعد از تحلیل، فیلدینگ متوجه شد که مقیاس‌پذیری وب تحت تأثیر یه سری محدودیت‌های کلیدی قرار داره. اون و دیگران تصمیم گرفتن که با یه رویکرد عملیاتی، وب رو بهبود بدن: باید همه این محدودیت‌ها رو به‌صورت یکسان برآورده کنن تا وب بتونه به گسترش خودش ادامه بده.
فیلدینگ این محدودیت‌ها رو به شش دسته تقسیم کرد و به مجموعه این دسته‌ها "سبک معماری وب" گفت:

۱. کلاینت-سرور (Client-server)
۲. رابط یکپارچه (Uniform interface)
۳. سیستم لایه‌ای (Layered system)
۴. کش (Cache)
۵. بدون حالت (Stateless)
۶. کد به‌صورت درخواستی (Code-on-demand)

1️⃣ کلاینت-سرور (Client-server)
موضوع اصلی محدودیت‌های کلاینت-سرور در وب، جداسازی وظایف است. وب یک سیستم مبتنی بر کلاینت-سرور است که در آن کلاینت‌ها و سرورها نقش‌های مجزا و مشخصی دارند. این بخش‌ها می‌توانند به‌صورت مستقل پیاده‌سازی و مستقر شوند، با استفاده از هر زبان یا فناوری، به شرطی که با رابط یکنواخت وب سازگار باشند.

2️⃣ رابط یکپارچه (Uniform interface)
تعاملات بین اجزای وب، یعنی کلاینت‌ها، سرورها و واسطه‌های مبتنی بر شبکه، به یکنواختی رابط‌هایشان بستگی دارد. اگر هر یک از این اجزا از استانداردهای تعیین‌شده خارج شوند، سیستم ارتباطی وب دچار اختلال می‌شود.
اجزای وب در چارچوب چهار محدودیت رابط یکنواخت که فیلدینگ شناسایی کرده است، به‌طور سازگار با هم کار می‌کنند:

1- شناسایی منابع
2- دستکاری منابع از طریق نمایه‌ها
3- پیام‌های خودتوصیفی
4- هایپرمدیا به عنوان موتور حالت برنامه (HATEOAS)

1- شناسایی منابع
هر مفهوم مجزای مبتنی بر وب به عنوان یک منبع شناخته می‌شود و می‌تواند با یک شناسه یکتا، مثل URI، مورد خطاب قرار گیرد. برای مثال، یک URI خاص مثل https://www.google.com منحصراً به مفهوم ریشه‌ی یک وبسایت خاص اشاره دارد.

2- دستکاری منابع از طریق نمایه‌ها
کلاینت‌ها نمایه‌های منابع را دستکاری می‌کنند. یک منبع مشخص می‌تواند به شکل‌های مختلف برای کلاینت‌های مختلف نمایه شود. مثلاً، یک سند ممکن است به‌صورت HTML به یک مرورگر وب نمایش داده شود و به‌صورت JSON به یک برنامه خودکار. ایده کلیدی این است که نمایه‌ها راهی برای تعامل با منبع هستند، اما خود منبع نیستند. این تمایز مفهومی اجازه می‌دهد که منبع به روش‌ها و فرمت‌های مختلف نمایه شود بدون اینکه شناسه‌اش تغییر کند.

3- پیام‌های خودتوصیفی (Self-descriptive)
وضعیت مورد نظر یک منبع می‌تواند در پیام درخواست کلاینت نمایه شود. وضعیت کنونی منبع ممکن است در پیام پاسخ سرور که بازمی‌گردد، نمایش داده شود. به‌عنوان مثال، یک ویرایشگر صفحه ویکی ممکن است از پیام درخواست برای انتقال یک نمایه که پیشنهاد یک بروزرسانی صفحه (وضعیت جدید) برای یک صفحه وب مدیریت‌شده توسط سرور است، استفاده کند. سرور تصمیم می‌گیرد که درخواست کلاینت را بپذیرد یا رد کند.

4- هایپرمدیا به عنوان موتور حالت برنامه (HATEOAS)
نمایش وضعیت یک منبع شامل لینک‌هایی به منابع مرتبط هست. لینک‌ها مثل نخ‌هایی هستند که وب رو به هم متصل می‌کنن و به کاربرا این امکان رو می‌دن که به صورت معنادار و هدفمند بین اطلاعات و برنامه‌ها حرکت کنن. وجود یا نبودن یه لینک روی یک صفحه، بخش مهمی از وضعیت فعلی اون منبعه.

3️⃣ سیستم لایه‌ای (Layered system)
محدودیت‌های سیستم لایه‌ای این امکان رو می‌ده که واسطه‌های مبتنی بر شبکه مثل پروکسی‌ها و درگاه‌ها، به‌صورت شفاف بین کلاینت و سرور مستقر بشن و از رابط یکنواخت وب استفاده کنن. به‌طور کلی، یه واسطه مبتنی بر شبکه برای یه هدف مشخص ارتباط کلاینت و سرور رو رهگیری می‌کنه. این واسطه‌ها معمولاً برای اجرای امنیت، کش کردن پاسخ‌ها و متعادل کردن بار ترافیکی استفاده می‌شن.

4️⃣ کش (Cache)
کش کردن یکی از مهم‌ترین محدودیت‌های معماری وب هست. محدودیت‌های مربوط به کش به سرور وب می‌گن که باید قابلیت کش شدن داده‌های هر پاسخ رو مشخص کنه. کش کردن داده‌های پاسخ می‌تونه به کاهش تأخیر احساس‌شده توسط کاربر، افزایش دسترسی‌پذیری و قابلیت اطمینان یک برنامه، و کنترل بار سرور وب کمک کنه. به طور خلاصه، کش کردن هزینه کلی وب رو کاهش می‌ده.
کش می‌تونه در هر جایی از مسیر شبکه بین کلاینت و سرور وجود داشته باشه. این کش‌ها ممکنه در شبکه سرور وب یک سازمان، داخل شبکه‌های تحویل محتوای تخصصی (CDNها) یا حتی داخل خود کلاینت باشن.

5️⃣ بدون حالت (Stateless)
محدودیت بدون حالت (Stateless) می‌گه که یه سرور وب نباید وضعیت برنامه‌های کلاینت‌هاش رو به خاطر بسپاره. به همین خاطر، هر کلاینت باید تو هر تعامل با سرور، تمام اطلاعات مرتبط و مورد نیازش رو همراه داشته باشه. سرورهای وب از کلاینت‌ها می‌خوان که پیچیدگی مدیریت وضعیت برنامه‌هاشون رو خودشون انجام بدن تا سرور بتونه به تعداد بیشتری از کلاینت‌ها خدمات بده. این مبادله یکی از عوامل کلیدی در مقیاس‌پذیری سبک معماری وب هست.

6️⃣ کد به‌صورت درخواستی (Code-on-demand)
وب به شدت از "کد به صورت درخواستی" (Code-on-demand) استفاده می‌کنه، این محدودیت به سرورهای وب اجازه می‌ده که به‌طور موقت برنامه‌های اجرایی مثل اسکریپت‌ها یا پلاگین‌ها رو به کلاینت‌ها منتقل کنن. کد به صورت درخواستی باعث می‌شه که یه نوع وابستگی تکنولوژیکی بین سرورهای وب و کلاینت‌ها ایجاد بشه، چون کلاینت باید توانایی فهم و اجرای کدی که به صورت درخواستی از سرور دانلود می‌کنه رو داشته باشه. به همین دلیل، کد به صورت درخواستی تنها محدودیت سبک معماری وب هست که اختیاری در نظر گرفته می‌شه. تکنولوژی‌هایی که در مرورگرهای وب استفاده می‌شن، مثل جاوا اپلت‌ها، جاوا اسکریپت و فلش، نمونه‌های بارز این محدودیت هستن.


💎 استاندارد های وب 💎
فیلدینگ همراه با تیم برنرز-لی و چند نفر دیگه برای افزایش مقیاس‌پذیری وب کار کرد. برای استانداردسازی طراحی‌هاشون، اونا یه مشخصات جدید برای نسخه جدید پروتکل انتقال ابرمتن (HTTP/1.1) نوشتن.
همچنین، نحو شناسه‌های یکنواخت منابع (URI) رو هم در RFC 3986 رسمی کردن.
این استانداردها به‌سرعت در سراسر وب پذیرفته شد و راه رو برای رشد بیشترش هموار کرد.

@ninja_learn_ir

💎 همه چیز درباره DDoS و روش‌های جلوگیری با Cloudflare 💎

امروز میخوایم در مورد یه مشکل خیلی جدی برای وب‌سایت‌ها صحبت کنیم: DDoS و اینکه چجوری میتونید با Cloudflare از سایتتون محافظت کنید.

حالا DDoS یعنی چی؟ 🤔

خب DDoS مخفف Distributed Denial of Service هست. یعنی یه تعداد زیادی کامپیوتر یا سرور همزمان کلی درخواست به یه سرور خاص می‌فرستن تا اون سرور از کار بیفته و سایتتون بالا نیاد.

چرا DDoS خطرناکه؟ ⚠️

1⃣ قطعی سرویس: سایت یا سرور شما ممکنه زمان زیادی از دسترس خارج بشه.

2⃣ افت عملکرد: سرعت سایتتون به شدت میاد پایین.

3⃣ ضرر مالی: ممکنه ضرر مالی زیادی ببینید.

چجوری با Cloudflare جلوی DDoS رو بگیریم؟ 🛡

1⃣ استفاده از CDN: Cloudflare به عنوان یه CDN، محتوای سایت شما رو توی سرورهای مختلف تو دنیا ذخیره می‌کنه. این کار باعث میشه درخواست‌ها به جای سرور اصلی، برن به نزدیک‌ترین سرور Cloudflare و فشار روی سرور اصلی کم بشه. 🌍
 
2⃣ فایروال‌های پیشرفته: Cloudflare فایروال‌های خیلی قوی داره که میتونن درخواست‌های مشکوک رو تشخیص بدن و مسدودشون کنن. 🔥

3⃣ محافظت از لایه DNS: خب Cloudflare از Anycast DNS استفاده می‌کنه، یعنی درخواست‌ها رو بین سرورهای مختلف پخش می‌کنه و این کار جلوی DDoS رو می‌گیره. 🌐

4⃣ تحلیل و نظارت ترافیک: با ابزارهای Cloudflare میتونید ترافیک ورودی به سایتتون رو دقیق بررسی کنید و از حملات احتمالی مطلع بشید. 📊

5⃣ محدود کردن درخواست‌ها: Cloudflare به شما این امکان رو میده که تعداد درخواست‌های ورودی از هر IP رو محدود کنید. ⛔

6⃣ خدمات Mitigation: خب Cloudflare ابزارهای ویژه‌ای برای مقابله با حملات DDoS داره که خودکار و فوری وارد عمل میشن. 💼

چیکار کنیم موقع حمله DDoS؟ 🤔

- پیکربندی Cloudflare: مطمئن بشید که تنظیمات Cloudflare درست انجام شده و محافظت DDoS فعال هست. 🛠️

سخن پایانی🎯:
فهمیدیم که ddos چقدر خطرناکه و چطوری میتونیم با استفاده از ابزارهایی مثل cloud flare جلوشو بگیریم

امیدوارم این مطلب به دردتون خورده باشه :)❤️

#cdn #ddos #وب #امنیت_اینترنتی

@ninja_learn_ir

دوتا قسمت دیگه هم اپلود شد 🤗

قسمت ۱۰:
https://youtu.be/7EIETZsnug4?si=8scR_A4B-MaihEew

قسمت ۱۱:
https://youtu.be/mlRZ_SMetbc?si=evTftHxoIJBqkUS1


@ninja_learn_ir

📕 کتاب REST API Design Rulebook

📌 فصل اول: معرفی (Introduction)

📍پارت: سوم

#کتاب

💎 REST 💎
در سال ۲۰۰۰، بعد از اینکه مشکل مقیاس‌پذیری وب حل شد، فیلدینگ تو پایان‌نامه دکترای خودش سبک معماری وب رو اسم‌گذاری کرد و اسمش رو "انتقال حالت نمایشی" یا همون REST رو برای این سبک معماری انتخاب کرد. این سبک شامل محدودیت‌هایی هست که قبلاً بهشون اشاره کردیم.

💎 REST API ها 💎

وب سرویس‌ها (Web Services) سرورهای مخصوصی هستن که نیازهای یه سایت یا هر اپلیکیشن دیگه‌ای رو برطرف می‌کنن.

برنامه‌های کلاینت (یا همون نرم‌افزارهایی که با سرور ارتباط می‌گیرن) از طریق API با این وب سرویس‌ها ارتباط برقرار می‌کنن.

به زبان ساده، API ها یه سری داده و عملکرد رو در اختیار برنامه‌های دیگه قرار می‌دن تا بتونن با هم تعامل کنن و اطلاعات رد و بدل کنن.

یه وب API مثل ویترین یه وب سرویسه که مستقیماً درخواست‌های کلاینت رو می‌شنوه و بهشون جواب می‌ده.

سبک معماری REST معمولاً برای طراحی API های وب سرویس‌های مدرن استفاده می‌شه. اگه یه وب API با سبک معماری REST طراحی شده باشه، بهش می‌گیم REST API.


⭕️ نکات:

مقیاس‌پذیری: یعنی یه سیستم بتونه بدون کاهش کیفیت، با افزایش ترافیک (مثلا تعداد کاربران) کنار بیاد و بتونه هندلشون کنه.

کلاینت: دستگاه یا نرم‌افزاری که به سرور وصل می‌شه و ازش درخواست می‌کنه. مثلاً مرورگر وب که به یه سایت وصل می‌شه.

وب سرویس: یه سرویس تحت وب که از طریق اینترنت قابل دسترسیه و خدمات خاصی رو ارائه می‌ده.

API: یه واسطه که به برنامه‌ها اجازه می‌ده با هم ارتباط برقرار کنن.


وقتی یه وب سرویس از REST API استفاده کنه، بهش می‌گیم که اون سرویس "RESTful" هست. یه REST API از یه سری منابع به هم پیوسته تشکیل شده که بهشون مدل منابع (Resource Model) گفته می‌شه. REST API هایی که خوب طراحی شده باشن، می‌تونن برنامه‌نویس‌های کلاینت رو جذب کنن تا از اون وب سرویس استفاده کنن. امروزه که سرویس‌های وب رقیب دارن با هم برای جلب توجه رقابت می‌کنن، داشتن یه REST API با طراحی تمیز و کاربرپسند یه ویژگی ضروریه.

طراحی REST API برای خیلی از ماها بیشتر شبیه یه هنره تا یه علم. یه سری از بهترین روش‌ها برای طراحی REST API توی استاندارد HTTP وجود داره، ولی یه سری روش‌های دیگه هم طی سال‌های اخیر به‌صورت نیمه‌استاندارد شکل گرفته.

با این حال، هنوز هم باید دنبال جواب برای یه سری سوالات مهم بگردیم، مثلا:

- کی باید اسم route هامون رو با اسم‌های جمع بنویسیم؟
- از کدوم متد ریکوست (مثل POST یا PUT) باید برای به‌روزرسانی وضعیت منابع استفاده کنیم؟
- چطور باید عملیات‌هایی که مربوط به CRUD نیستن (CRUD: ایجاد، خواندن، به‌روزرسانی، حذف) رو به route ها مپ کنیم؟
- کدوم کد استاتوس HTTP برای یه سناریوی خاص مناسبه؟
- چطور می‌تونم نسخه‌های مختلف نمایه‌های وضعیت یه منبع رو مدیریت کنم؟
- چطور باید لینک‌ها رو توی JSON ساختاردهی کنم؟

⭕️ نکات:
- URI آدرس مشخصی که برای دسترسی به یه منبع توی وب استفاده می‌شه.
- CRUD مخفف چهار عمل اصلی روی داده‌ها؛ ایجاد (Create)، خواندن (Read)، به‌روزرسانی (Update)، و حذف (Delete).
- HTTP Status Code کدهایی که وضعیت درخواست‌های HTTP رو نشون می‌دن، مثل 200 برای موفقیت‌آمیز بودن یا 404 برای پیدا نشدن.


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

خیلی از قوانین طراحی این کتاب از بهترین روش‌هایی گرفته شدن که به‌نوعی استانداردهای نانوشته‌ای شده‌ان. اگه تجربه‌ای توی طراحی REST API ها داری، احتمالاً با قوانینی که مربوط به طراحی URI در فصل ۲ و استفاده از HTTP در فصل ۳ هستن، آشنا خواهی بود. ولی در مقابل، بیشتر قوانین فصل ۴ و فصل ۵ (مخصوصاً اونایی که به نوع داده‌ها و فرم‌های نمایشی مربوط می‌شن) راه‌حل‌هایی هستن که خودم برای مسائلی که توافقی روشون نیست، ارائه دادم.

@ninja_learn_ir

#کتاب