دامنه رایگان بدون دردسر

https://github.com/DigitalPlatDev/FreeDomain

مراحلش سادست کافیه ثبت نام کنید و طبق توضیحاتشون پیش برید.

@Syntax_fa

هوش مصنوعی توی فرانت اند

برای فرانت اند پروژه های اپن سورس دارم از AI استفاده میکنم و خروجی دوتا از پروژه ها این دوتا بودن:

وب سایت معرفی کوئیک کانکت:
https://quick-connect.syntaxfa.ir

وب سایت معرفی دانجو:
https://danjoo.syntaxfa.ir

قبلا زیاد امتحان نکرده بودم و برای خودم خیلی جالب بود. نسبت به توضیحی که داده بودم خیلی خوب درآوردن کارو.

@Syntax_fa

- ‏وقتی به جای گروک و‌چت جی پی تی و ... میرم سراغ گوگل: من برگشتم خونه...استاد

source

#fun

@Syntax_fa

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

معماری تلگرام، اون رو به یک بهشت آشوب تبدیل کرده.

مشکل فقط چندتا کانال متخلف نیست؛ مشکل در هسته‌ی طراحی این پلتفرمه.

۱. توهمِ نظارت (جعبه سیاه ریپورت)

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

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

۲. مشکل هیدرا (محتوای ابدی)

این خطرناک‌ترین بخش ماجراست.
فرض کنید یه محتوای مجرمانه (مثلاً یه ویدیوی دلخراش) در یک کانال پست می‌شه. حالا هزاران نفر اون رو می‌بینن، در Saved Messages خودشون ذخیره می‌کنن، یا به پیوی و گروه‌های خصوصی فوروارد می‌کنن.

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

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

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

۳. اکوسیستم جنگل تاریک (ویترین عمومی، انبار خصوصی)

این معماری، یک اکوسیستم دوگانه ساخته:

1. "ویترین عمومی" (Public Channels): جایی که نظارت (هرچند ضعیف) وجود داره. این‌ها برای تبلیغ و جذب نیرو استفاده می‌شن.
2. "جنگل تاریک" (Private Ecosystem): شامل گروه‌های خصوصی و چت‌های شخصی. اینجا هیچ نظارتی وجود نداره. صفر.

گروه‌های مجرمانه، افراطیون و کلاهبردارها در "ویترین عمومی" تبلیغ می‌کنن و اعضا رو به "جنگل تاریک" (گروه‌های خصوصی) می‌کشونن. جایی که دیگه هیچ قانونی وجود نداره.

@Syntax_fa

Go + HTMX
ادمین پنل Quick Connect

ما توی پنل ادمین(سرویس adminapp) قید فریم‌ورک‌های سنگین جاوااسکریپت (مثل React/Vue) رو زدیم و مستقیم سراغ ترکیب Go + HTMX رفتیم.

چرا؟ چون سریعه، ساده و فوق‌العاده قدرتمنده.

معماری چطوریه؟
الگوی BFF هستش. adminapp ما یک Backend for Frontend (BFF) کلاسیک هست.

این یعنی چی؟
Go Server (BFF): adminapp
یک سرور Go هست که مخصوص UI ادمین ساخته شده. این سرور، مرورگر رو به عنوان فرانت‌اند خودش می‌بینه.

ارتباط باطن با gRPC.
این سرور Go، برای گرفتن دیتا (مثلا لیست یوزرها)، با managerapp یا سرویس‌های دیگه از طریق gRPC صحبت می‌کنه.

رندر سمت سرور (SSR):
وقتی دیتا رو از gRPC گرفت، میاد اون رو توی قالب‌های HTML (فایل‌های .../templates/) رندر می‌کنه.

بدون JSON، فقط HTML: اینجا دیگه خبری از API یی که JSON برگردونه و یه فرانت‌اند جاوااسکریپتی اون رو بگیره و کامپوننت بسازه نیست. سرور Go مستقیم خود HTML نهایی رو می‌سازه و می‌فرسته.

ا. HTMX اینجا چیکار می‌کنه؟
جادوی واقعی اینجاست!

بارگذاری اولیه: کاربر صفحه داشبورد رو باز می‌کنه. سرور Go کل صفحه dashboard.html رو رندر می‌کنه و می‌فرسته.

کاربر روی دکمه «ساختن یوزر جدید» کلیک می‌کنه.
ا. HTMX (که یه فایل .js کوچیکه) یه درخواست AJAX به سرور Go می‌فرسته (مثلا به POST /htmx/users/create-modal).

سرور Go این درخواست رو می‌گیره.
ا. Go فقط و فقط فایل user_create_modal.html رو رندر می‌کنه (نه کل صفحه رو!).

این تکه HTML کوچیک به مرورگر برمی‌گرده.
ا. HTMX این تکه HTML رو می‌گیره و تو صفحه swap می‌کنه مثلا داخل یه div خالی می‌ذاره).

نتیجه؟
ما یه داشبورد داینامیک و سریع داریم که حس اپلیکیشن‌های SPA (مثل ری‌اکت) رو می‌ده، اما:

* ۹۹٪ منطق توی Go نوشته شده.
* نیازی به Build Step جاوااسکریپتی نداریم.
* سرعت لود اولیه فوق‌العاده‌ست.
* توسعه‌ش به‌شدت ساده و لذت‌بخشه.
اگه از نوشتن Go لذت می‌بری و دلت نمی‌خواد درگیر پیچیدگی‌های فرانت‌اند مدرن بشی، معماری adminapp دقیقاً همون چیزیه که دنبالش می‌گردی.

Quick Connect
AdminApp

#go #htmx

@Syntax_fa

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

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

#fun

@Syntax_fa

صفحه بندی داده داده‌ها: Limit/Offset و Cursor-Based

وقتی صحبت از نمایش حجم زیادی از داده‌ها در صفحات مختلف میشه، استفاده از pagination ضروری میشه. دو روش رایج برای این کار وجود داره که هر کدوم سادگی‌ها و چالش‌های خاص خودشون رو دارن:

صفحه بندی با Limit و Offset سادگی ولی ...

صفحه بندی با Limit و Offset رو میشه ساده‌ترین و اولین روشی دونست که به ذهن میرسه. شما به دیتابیس میگید "فقط Limit تا رکورد بهم بده" و "از Offset مشخصی شروع کن".

سادگی:
پیاده‌سازی خیلی آسونی داره.
برای صفحات اول که تعداد رکوردها کمه، عملکرد خوبی داره.

چالش‌ها:
عملکرد ضعیف در صفحات بالا: با افزایش Offset، دیتابیس مجبور میشه تعداد زیادی از رکوردها رو اسکن کنه و بعد اونا رو دور بندازه که باعث کندی شدید میشه.
مشکل تغییر داده‌ها: اگه در حین حرکت بین صفحات، داده‌ای اضافه یا حذف بشه، ممکنه رکوردهای تکراری ببینید یا بعضی از رکوردها رو از دست بدید.
مرتب‌سازی (Sorting): معمولاً نیازمند مرتب‌سازی روی یک فیلد ثابت هستید تا نتیجه قابل پیش‌بینی باشه.

مثال ساده (SQL):

برای گرفتن ۱۰ رکورد اول از جدول products (صفحه ۱):

SELECT *
FROM products
ORDER BY id
LIMIT 10 OFFSET 0;

برای گرفتن ۱۰ رکورد بعدی (صفحه ۲):

SELECT *
FROM products
ORDER BY id
LIMIT 10 OFFSET 10;

صفحه بندی با روش Cursor-Based Pagination: راه حلی برای مقیاس‌پذیری

صفحه بندی با Cursor-based pagination با استفاده از یک "نشانگر" (cursor) که معمولاً یک فیلد یکتا و مرتب‌سازی شده (مثل تاریخ ایجاد یا ID) هست، صفحه بعدی رو مشخص میکنه. به جای گفتن "صفحه N رو بیار"، میگیم "رکوردها رو از بعد از این نقطه مشخص بیار".

محدودیت‌ها و نکته‌ها:
پیچیدگی پیاده‌سازی: نسبت به Limit/Offset کمی پیچیده‌تره و نیازمند طراحی دقیق‌تر کوئری‌هاست.
مرتب‌سازی: باید همیشه بر اساس فیلد Cursor مرتب‌سازی انجام بشه. این یعنی نمیتونید هر جور دلتون خواست داده‌ها رو مرتب کنید.
پرش به صفحات دلخواه: معمولاً قابلیت "پرش به صفحه 5" رو نداره و فقط میتونید به صفحه بعدی یا قبلی برید (Next/Previous). مناسب برای فیدها و لیست‌های طولانی: برای سیستم‌هایی مثل فید شبکه‌های اجتماعی که فقط به اسکرول کردن ادامه دار نیاز دارن و پرش به صفحه خاصی مطرح نیست، عالی عمل میکنه.

مثال ساده (SQL):

فرض کنید آخرین id محصولی که در صفحه قبلی دیده‌اید 1234 بوده:

SELECT *
FROM products
WHERE id > 1234
ORDER BY id
LIMIT 10;

#pagination #sql

@Syntax_fa

چهار ریپو پر ستاره دنیا در گیتهاب:

build-your-own-x
(۴۴۲ هزار استار)

"چرخ را دوباره اختراع کن تا یاد بگیری چطور کار می‌کند!"
این ریپوزیتوریِ جذاب به تازگی به رتبه اول صعود کرده است. ایده آن ساده اما فوق‌العاده است: لیستی از آموزش‌ها برای اینکه تکنولوژی‌های معروف را از صفر بسازید.

* دوست دارید «گیت» (Git) خودتان را بسازید؟
* می‌خواهید یک «سیستم عامل» یا «دیتابیس» ساده کدنویسی کنید؟
اینجا بهترین جا برای کسانی است که می‌خواهند از سطح مصرف‌کننده ابزار، به خالق ابزار تبدیل شوند.

freeCodeCamp
(۴۳۳ هزار استار)
"دانشگاه رایگان برنامه‌نویسی"
سال‌ها در رتبه اول بود و هنوز هم معتبرترین منبع آموزشی رایگان است. این مخزن سورس‌کدِ پلتفرم freeCodeCamp.org است که میلیون‌ها نفر با آن برنامه‌نویسی وب را یاد گرفته‌اند. اگر دنبال یک مسیر یادگیری (Roadmap) کامل و دریافت مدرک رایگان هستید، اینجا خانه شماست.

awesome
(۴۱۷ هزار استار)
"لیستی از لیست‌های عالی"
تا حالا شده دنبال "بهترین کتابخانه‌های پایتون" یا "بهترین ابزارهای هک و امنیت" بگردید؟ ریپوزیتوری Awesome یک دایرکتوری غول‌پیکر است که لینکِ تمام منابع باکیفیت برای هر زبان و تکنولوژی را یکجا جمع کرده است. گوگل کردن خوب است، اما گشتن در Awesome شما را سریع‌تر به نتیجه‌های حرفه‌ای می‌رساند.


996.ICU
(حدود ۲۷۰ هزار استار)
"صدای اعتراض برنامه‌نویسان"
این مخزن با بقیه فرق دارد؛ اینجا کدی برای اجرا نیست، بلکه نماد یک جنبش است. نام آن به فرهنگ کاری ناعادلانه در شرکت‌های فناوری چین اشاره دارد: کار از ۹ صبح تا ۹ شب، ۶ روز در هفته.
برنامه‌نویسان با استار دادن به این ریپوزیتوری، اعتراض خود را به شرایط کاری سخت و استثمار نیروهای فنی در سراسر جهان نشان می‌دهند.

@Syntax_fa

چرا Code-level Monolith معماری برنده است؟ (درس‌هایی از Grafana Loki)

دوراهی مونولیت یا میکروسرویس:
از یک طرف، مونولیت (Monolith) ساده است اما اگر بد نوشته شود به "کد اسپاگتی" تبدیل می‌شود.
از طرف دیگر، میکروسرویس (Microservices) مقیاس‌پذیر است اما شما را در جهنمی از پیچیدگی‌های شبکه، دیپلوی و مدیریت ۵۰ کانتینر مختلف غرق می‌کند.

اما اگر راه سومی وجود داشته باشه چی؟ راهی که در آن کدتان را "مثل میکروسرویس" می‌نویسید، اما آن را "مثل مونولیت" اجرا می‌کنید.

در معماری Code-level Monolith، شما مرزهای سرویس‌هایتان را کاملا رعایت می‌کنید. یعنی سرویس Auth و سرویس Order کدهای کاملا جداگانه‌ای دارند (درست مثل میکروسرویس).
اما در زمان بیلد (Build Time)، به جای اینکه آنها را در کانتینرهای جداگانه بسته‌بندی کنید، همه را در یک فایل اجرایی (Binary) واحد لینک می‌کنید.

شعار این معماری:
> *"میکروسرویس در توسعه، مونولیت در اجرا."*

جادوی Grafana Loki و Tempo
بهترین مثال زنده این معماری در دنیا، ابزارهای شرکت Grafana Labs (مانند Loki برای لاگ، Tempo برای تریس و Mimir برای متریک) هستند.

سورس کد Grafana Loki از اجزای مختلفی تشکیل شده است:
* Ingester (دریافت لاگ)
* Distributor (توزیع بار)
* Querier (جستجو)

نکته نبوغ‌آمیز اینجاست: همه این‌ها در یک کدبیس و یک فایل باینری هستند.

1. حالت (All-in-One):
وقتی می‌خواهید Loki را روی لپ‌تاپ یا سرور کوچک خود اجرا کنید، دستور زیر را می‌زنید:
./loki -target=all
در این حالت، تمام اجزا در یک پروسه اجرا می‌شوند. ارتباط بین Distributor و Ingester از طریق Function Call در حافظه رم انجام می‌شود.
* تاخیر: صفر نانوثانیه.
* پیچیدگی: صفر.

2. حالتِ اسکیل بالا (Microservices):
وقتی ترافیک شما میلیونی می‌شود، همان فایل باینری را با فلگ متفاوتی اجرا می‌کنید:
./loki -target=ingester
حالا این باینری فقط نقش Ingester را بازی می‌کند و بقیه کدها خاموش می‌شوند. در این حالت، ارتباطات به صورت خودکار به gRPC/HTTP تغییر می‌کند.

چرا باید به این روش فکر کنید؟

1. حذف سربار شبکه (Zero Latency):
در میکروسرویس، داده‌ها باید Serialize شوند، به شبکه بروند و Deserialize شوند. در Code-level Monolith، این فقط یک جابجایی اشاره‌گر (Pointer) در حافظه است. سرعت اجرای شما وحشتناک بالا می‌رود.

2. دیپلوی آسان (Operational Simplicity):
برای شروع پروژه، نیازی به Kubernetes و مدیریت ۱۰ تا فایل YAML ندارید. یک فایل باینری را کپی و اجرا می‌کنید.

3. انعطاف‌پذیری (Agility):
شما امروز نمی‌دانید پروژه شما چقدر بزرگ می‌شود. با این روش، شما امروز ساده شروع می‌کنید، اما کدتان "Ready to Scale" است. هر زمان لازم شد، با تغییر کانفیگ، مونولیت را می‌شکنید.

چطور پیاده‌سازی کنیم؟ (مثال Go)
کلید کار در استفاده از Interface هاست.
به جای اینکه سرویس A مستقیماً با gRPC کلاینتِ سرویس B صحبت کند، با یک اینترفیس صحبت می‌کند.

* **در حالت Monolith: پیاده‌سازی اینترفیس، مستقیماً متد سرویس B را صدا می‌زند.
* در حالت Microservice: پیاده‌سازی اینترفیس، یک درخواست gRPC می‌فرستد.

—-

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

سوال:
در گوئیک کانکت چطور میشه به code level monolith رسید؟
https://github.com/syntaxfa/quick-connect

#code_level_monolith

@Syntax_fa

چند تا گیتهاب اکشن کاربردی که بدرد اکثر ریتوزیتوری ها میخوره:

1. اکشن لینت
با این اکشن، اکشن هارو لینت کن و بررسی کن ورژن ها، سینتکس و همه چی اوکیه یا نه. همچنین خودش تو پول ریکوئست ها کامنت هم میذاره و مشکلات رو میگه.

نمونه کد:
https://github.com/syntaxfa/quick-connect/blob/main/.github/workflows/action-lint.yml

2. داکر لینت:
فایل Dockerfile هارو لینت میکنه
از نظر امنیتی، استاندارد و اینکه الکی حجم ایمیج رو زیاد نکرده باشید و ... لینت میکنه.

نمونه کد:
https://github.com/syntaxfa/quick-connect/blob/main/.github/workflows/docker-lint.yml


3. کامیت لینت:
لینت کردن کامیت ها مسیج کامیت و ...

نمونه کد:
https://github.com/syntaxfa/quick-connect/blob/main/.github/workflows/commit-lint.yml

4. SQL Lint:
فایل های sql رو لینت میکنه.

نمونه کد:
https://github.com/syntaxfa/quick-connect/blob/main/.github/workflows/sql-lint.yml


5. دپلوی روی داکر هاب
نمونه کد:
https://github.com/syntaxfa/quick-connect/blob/main/.github/workflows/admin-deploy.yml


#github #action

@Syntax_fa

میتونید gemini business یک ماهه اشتراک آزمایشی بگیرید. هیچیم نمیخواد ازتون.

https://business.gemini.google/

ترفند Issue Trick یا Github Asset Hosting

میخواید پروژتون رو توی README با استفاده از گیف و ویدیو معرفی کنید ولی نمیدونید فایل هارو کجا قرار بدید؟
اگه فایلتون حجمش کمه مثلا زیر 3 مگ، میتونید تو دایرکتوری docs داخل خود سورس کد پروژه بذارید ولی بازم روش خوبی نیست بنظرم.

اما اگه فایلتون حجمش زیاده بنظرتون اینکار منطقیه؟
یکی بخواد clone کنه باید همراهش چند تا فایل بی ربط رو دانلودش کنه.

خب چه کار هایی میتونیم؟
میتونیم تو فضای ذخیره سازی ای مثل aws و ... قرار بدیم ولی بازم وابسته شدیم به یه سرویس خارجی که فردا ممکنه فیلتر یا قطع بشه.

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

میریم قسمت ایشو
یک ایشو جدید باز میکنیم
بعد فایلمون رو تو قسمت description آپلود میکنیم.
بعدش صبر کنید تا آپلود فایل تموم بشه.
گیتهاب به شما یک لینک میده.
همونو کپی کنید تو README قرارش بدید!

نکته طلایی:
اصلا نیازی نیست دکمه submit new issue رو بزنید! حتی اگه ایشو کنسل بشه یا کامل ببندید و نسازیدش، اون فایل روی سرور های پرسرعت گیت‌هاب باقی میمونن!

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

نکته:
توی خود README هم میتونید همینکارو کنید.

#github

@Syntax_fa

💻 ناهمگونی خوندن داده‌ها یا Read Phenomena در دیتابیس‌ها
وقتی تراکنش‌ها همزمان دارن با داده‌ها کار می‌کنن، بعضی وقت‌ها نتیجه‌ای که می‌بینی، اون چیزی نیست که انتظار داری! به این وضعیت میگن Read Phenomena.

🔹 سه حالت اصلی:

1️⃣ خواندن داده کثیف (Dirty Read)
تراکنش A یه رکوردو تغییر میده ولی هنوز commit نکرده، تراکنش B میاد می‌خونه.
اگه بعداً A رولبک بشه، B یه داده‌ای خونده که واقعیت نداشته!

2️⃣ خواندن غیرتکراری (Non-Repeatable Read)
تراکنش A یه رکوردو می‌خونه، تراکنش B همون رکوردو تغییر میده و commit می‌کنه.
وقتی A دوباره می‌خونه، می‌بینه تغییر کرده!

3️⃣ خواندن شبح (Phantom Read)
تراکنش A یه مجموعه رکورد می‌خونه، تراکنش B بین دو بار خوندن یه رکورد اضافه یا حذف می‌کنه.
وقتی A دوباره می‌خونه، نتیجه فرق می‌کنه!

🔹 راه حل:
با سطوح Isolation در SQL میشه کنترلشون کرد:

Read Uncommitted

Read Committed

Repeatable Read

Serializable

هر سطح یه ترکیب متفاوت از سرعت و دقت داده‌ها میده.

📌 جمع‌بندی:
فهمیدن Read Phenomena کمک می‌کنه سطح Isolation مناسب انتخاب بشه و از مشکلاتی مثل محاسبات نادرست، داده‌های ناقص یا تداخل تراکنش‌ها جلوگیری بشه.
در پست‌های بعدی با جزئیات بیشتری به هر سطح Isolation می‌پردازم.

#database

@Syntax_fa

شما نتفلیکس نیستید! پس چرا از روز اول با پیچیدگی میکروسرویس‌ها خودکشی می‌کنید؟

صنعت نرم‌افزار در حال یک بازگشت عقلانی به سمت معماری‌های یکپارچه مدرن (Modular Monolith) است. جایی که یاد می‌گیریم معماری کد (Logical) باید از معماری استقرار (Physical) کاملا جدا باشه.

در اولین مقاله‌ام در ویرگول، با کالبدشکافی پروژه اپن‌سورس Quick Connect، معماری Code-Level Monolith رو معرفی کردم. معماری‌ای که حلقه گمشده بین سادگی و مقیاس‌پذیریه.

در این معماری:
۱. امروز: با سرعت بالا و هزینه کم به صورت یکپارچه دپلوی می‌کنید
۲. فردا: بدون بازنویسی کد و فقط با تغییر کانفیگ، ماژول‌های پرفشار رو جدا کرده و میکروسرویس می‌کنید (مثل Grafana Loki).

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

مطالعه کامل مقاله (فارسی و انگلیسی):

ویرگول:
https://vrgl.ir/JIk5n

Dev.to:
https://dev.to/alireza_feizi_2aa9c86cac4/code-level-monolith-the-hybrid-architecture-the-art-of-flexible-deployment-2jm2

#modulith

@Syntax_fa

جمنای عجب چیزیه.
الان یهو دیدم آزمونم طراحی میکنه

آیا کشتی نرم‌افزار شما هم مثل تایتانیک غرق میشه؟ پترن Bulkhead

اصطلاح Bulkhead از مهندسی کشتی سازی می آید.
در قدیم، بدنه کشتی‌ها یک فضای خالی بزرگ و یکپارچه بود. اگه صخره‌ای به بدنه می‌خورد و سوراخی ایجاد می‌شد، آب وارد می‌شد، کل فضای زیر کشتی پر از آب می‌شد و کشتی غرق می‌شد (مثل تایتانیک).

مهندسان راه‌حل رو پیدا کردند: تقسیم فضای داخلی به اتاقک‌های جداگانه و ضدآب.

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

در نرم افزار بدون Bulkhead:
فرض کنید یک فروشگاه آنلاین دارید:
۱. سرویس خرید محصول(حیاتی)
۲. سرویس پیشنهاد محصولات(سنگین و وابسته به هوش مصنوعی)

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

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

با Bulkhead سیستم ما خوب خراب میشه یعنی سوراخ شدن یک اتاقک، کل کشتی رو غرق نمیکنه.

درباره Bulkhead pattern در Azure Architecture Center
https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead

#buldhead

@Syntaxfa