این یک فایل داکر هست که ما توی میکروسرویس White Label ساختیم.
همین چند خط کد کار مارو راه میندازه و همونطور که میبینید خیلی آسونه من چند خط اول رو براتون توضیح میدم تا ببینید چقدر آسون کار میکنه.

@csharptips
@easymicroservice
@easymicroservices

#docker

دوتا مفهوم مهم که توی داکر باید متوجه بشید Images و Containers هستند.
اگر بخوام مثل پست قبلی ساده توضیح بدم.
در واقع Image هارو سورس کدی ببینید که قراره توی یک محیطی اجرا کنید. و Containers ها رو تب های مرورگر ببینید که همشون به یک سورس وصل هستند ولی کاملا مستقل از هم اجرا شدن و کاری با هم ندارن . حالا یکم تعریف رو تخصصی تر کنم، Images ها در واقع همون جایی هستند که سیستم عامل مجازی شما نصب میشه که میتونه لینوکس یا ویندوز یا ... باشه. و Container ها در واقع بسته های ایزوله ای هستند که روی اون سیستم عامل اجرا میشن. مثلا شما یک سیستم عامل لینوکس انتخاب و نصب میکنی بعد داخلش 5 تا کانتینر میسازی که هرکدوم از این کانتینرها میتونن یک سورس اپلیکیشن شمارو در خودشون اجرا کنن. شبیه کاری که هاست ها می کنن و شما میتونید صد تا وبسایت رو روی یک سیستم عامل اجرا کنید یا کاری که IIS یا Apache میکنه.

چیزی که توی تصویر میبینید یه سری دستور هست برای ساخت و اجرای Image و هرکسی این فایل رو داشته باشه میتونه با یه سری دستور توی داکر Image رو بسازه و وبسایت رو به صورت ایزوله اجرا کنه که جلوتر توضیح میدم.


@csharptips
@easymicroservice
@easymicroservices

#docker

توی خط اول ما دستور زیر رو داریم:

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS Build

با این دستور شما پایه‌ی Image خودتون رو مشخص می‌کنید. فرض کنید میخوا‌هید توی برنامه نویسی از یک کلاس ارث ببرید و اون کلاسی که ازش ارث می‌برید یک سری مشخصات پایه رو توی خودش داره که قسمت زیادی از کار شمارو راه می‌اندازه.
الان این دستور داره از سایت مایکروسافت اطلاعات پایه‌ی کانتینر رو برای دات نت 6 فراهم می‌کنه. مثلا sdk دات نت 6 روی Image شما نصب میشه تا بتونید سورس های دات نت 6 رو روش اجرا کنید.

بچه‌ها مشابه همین دستورات رو برای Github Actions و Azure Pipeline ها هم دارید که برای مباحث CI/CD می‌تونید ازشون استفاده کنید. برای اینکه یکم با مباحث Devops هم آشنا بشید جلوتر بهتون میگم که توی گیتهاب و آژور اینا به چه شکل هستند و چیکار می‌کنند.

بزن لایک رو و شیر کن که انگیزه بگیرم زودتر مطالب منتشر کنم 😍.

#docker
#داکر

@csharptips
@easymicroservice
@easymicroservices

بعدش دوتا دستور زیر رو داریم

WORKDIR /source
COPY . .

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

بعد از این دوتا دستور، دستور RUN رو داریم، اینجا شما یک دستور رو توی سیستم عامل اجرا میکنید. با دستورات و کامند های دات نت که آشنا باشید از اینجا به بعد همش دستورات دات نت هست و ربطی به داکر نداره.

RUN dotnet restore EasyMicroservices.WhiteLabelsMicroservice-net6.0.sln
RUN dotnet build EasyMicroservices.WhiteLabelsMicroservice-net6.0.sln --no-restore
RUN dotnet test EasyMicroservices.WhiteLabelsMicroservice-net6.0.sln --no-build --verbosity normal -f net6.0
RUN dotnet publish EasyMicroservices.WhiteLabelsMicroservice-net6.0.sln -c release -o /app --no-restore

توی خط اول بهش گفتم پکیج های پروژمو دانلود کن و پروژمو آماده کن.
توی خط دوم گفتم پروژه دات نتم رو کامپایل بگیر
توی خط سوم گفتم تست هام رو اجرا کن روی دات نت 6.0
توی خط چهارم هم گفتم پروژمو پابلیش بگیر.

#docker
#داکر

@csharptips
@easymicroservice
@easymicroservices

نرم افزار داکر رو میتونید از لنیک زیر دانلود کنید:

https://www.docker.com/products/docker-desktop/

بعدش توش ثبت نام کنید و لاگین بشید.

بعد از اون شما به یک سیستم عامل نیاز دارید تا Image ها و Container هاتونو بتونید توش اجرا کنید. برای نصب سیستم عامل لینوکس به این دستور نیاز دارید:

docker pull ubuntu:18.04

بسته به نیازتون هر نسخه از سیستم عاملی که داکر ساپورت میکنه رو میتونید نصب کنید.که اینجا من نسخه ی 18.04 رو نصب کردم. البته میتونید نسخه های کاستوم نشده رو هم نصب کنید که حجم کمتری دارند و کلی کارای دیگه.

بعد از اینکه تنظیمات اولیه ی داکر رو انجام دادید میتونید از دستور زیر برای ساخت Image خودتون استفاده کنید:

docker build . -t mytesttag

اون نقطه ای که اون وسط میبینید محل موجود بودن فایل DockerFile شماست که توی سورسی که همون اول بهتون دادم وجود داره و آموزش ها رو بر اساس همون فایل بردیم جلو. حالا اگه مسیرتون جای دیگه بود میتونید به جای نقطه یک مسیر به داکر بدید تا فایل ساخت Image رو پیدا کنه.
فایل image شما به نام mytesttag که توی دستور زدید ساخته میشه و با دستور زیر میتونید لیست Image هاتونو ببینید:

docker images

خب بعد از این فقط کافیه که image خودتون رو توی یک container اجرا کنید:

docker run -d -p 8080:1041 mytesttag mycontainer

خوب بریم دستور بالا رو بررسی کنیم ببینیم چیکار میکنه.
فلگ -d مشخص میکنه که کانتینر در پس زمینه اجرا بشه و روی کنسول فعلی که دارید دستورات رو میزنید اجرا نشه و اگر میخواهید همه چیز رو توی همین کنسولی که دستور رو میزنید ببینید میتونید فلگ رو بردارید.
فلگ -p هم باعث میشه که کانتینر روی یک پورت خاص گوش بزنگ باشه. الان کانتینر روی پورت 8080 روی localhost سیستم شما گوش بزنگ میمونه و توی مرورگر بزنید پورت 8080 رو به کانتینر میزنه حالا کانتینر میاد این پورت رو به پورت 1041 که جلوش زدم فروارد میکنه و پاسخ رو به شما بر میگردونه.
اینطوری شما میتونید چندتا کانتینتر بیارید بالا که همشون روی پورت 1041 گوش بزنگ هستند ولی پورت های کانتینر باید متفاوت باشه. مثلا 8080 و 8081 و 8082 و الی آخر.
برای همین میتونیم روی ایزوله بودن و مستقل بودن محیط ها روش حساب کنیم.

در ادامه یک فاصله و اسم image تون رو میدید و با یک فایل اسم کانتینر که اینجا mycontainer هست رو مشخص میکنیم.

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

آسون بود؟

@csharptips
@easymicroservice
@easymicroservices

#داکر
#docker

چرا باید از پترن MVVM توی میکروکامپوننت‌ها استفاده کنیم؟ مزیت این پترن روی معماری میکروکامپوننت چیه؟

همانطور که در تصویر می‌بینید ما به ازای رابط کاربری برای هر کامپوننت بهتره که فقط یک View Model داشته باشیم. View Model شامل بیزینس لاجیک یا به عبارتی Code Behind شما می‌شن.
فرض کنید من یک میکرو کامپوننت میزنم که قراره فقط صفحه‌ی لاگین رو پوشش بده.
طراحی، پیاده سازی UI ممکنه توی سه تا بیزنس زیر متفاوت باشه:
1.دسکتاپ
2.وب
3.موبایل
4.پنل

آیا به ازای هر کدوم از این رابط کاربری ها باید یکبار بیزینس لاجیک ها و Api call ها رو پیاده سازی کنم؟ خیر.

برای همین ما یک لایه به نام View Model میسازیم تا تمامی UI ها از اون رابط کاربری استفاده کنند. اینطوری رابط کاربری از لاجیک کاملا جداسازی شده و وابستگی بینشون از بین میره و توسعه سریعتر و خطایابی آسون‌تر از همه مهمتر تست نویسی رو آسونتر میکنیم.

@easymicroservice
@easymicroservices
@csharptips

#microcomponent
#میکروکامپوننت
#میکروفرانت
#microfrontend

پکیج EasyMicroservices.Logger یک اینترفیس به شما ارائه میکنه که با استفاده از اون میتونید توی اپلیکیشن خودتون هرچی میخواید رو لاگ کنید.
این اینترفیس میتونه سطوح زیر رو لاگ کنه:

Verbose
Debug
Information
Warning
Error
Fatal

یک اینترفیس هم برای توابع async وجود داره که میتونید ازش استفاده کنید.

تا به اینجا هم تامین کننده های زیر برای لاگ کردن توی دات نت پیاده سازی شدن:


1 .Log4net
2. Logary
3. Loupe
4. NLog
5. Sentry
6. Serilog


با استفاده از این اینترفیس هر زمان که دوست داشتید میتونید پکیج تامین کننده لاگ خودتون رو با یک خط کد تغییر بدید بدون اینکه زیر ساخت پروژه ی شما دست بخوره.
سورس:
https://github.com/EasyMicroservices/Logger

@easymicroservice
@easymicroservices
@csharptips

#log
#logger
#csharp
#dotnet

ارث‌بری در رابط کاربری چگونه است؟ آیا قابلیت پیاده‌سازی دارد؟
ارث‌بری در رابط کاربری مانند برنامه‌نویسی نیست و پیاده‌سازی آن به‌مراتب دشوارتر است، چرا که ابزار‌های رابط کاربری هنوز در حال توسعه‌اند و به آن بلوغ نرسیده‌اند که بتوان روی آن‌ها معماری دقیق و کاملی را پیاده کرد.
امروز ما می‌خواهیم یک نمونه از ارث‌بری در رابط کاربری را به شما نشان دهیم تا ببینید که ما در Easy Microservices چگونه این موضوع را حل می‌کنیم.

تصور کنید که ما دو UI Kit قدرتمند MudBlazor و Radzen را در اختیار داریم. هر یک از این کامپوننت‌ها خصوصیات خود را دارند؛ به طور مثال یک دکمه در MudBlazor با نام MudButton و در Radzen با نام RadzenButton معرفی شده است و هر کدام ویژگی‌های خاص خود را دارند.

حال اگر به وابستگی‌ها بپردازیم، فرض کنید کل پروژه را با Radzen توسعه داده‌ایم و بعد متوجه شویم که پشتیبانی از RTL (متن چپ-به‌راست) را ندارد، دیگر چه عملی باید انجام داد؟ آیا باید وقت زیادی صرف کنیم تا کل پروژه را به MudBlazor تبدیل کنیم؟

راه‌حلی که ما ارائه کرده‌ایم به این ترتیب است که ما یک کنترل به نام EasyButton می‌سازیم و سپس آن را برای Radzen و MudBlazor پیاده‌سازی می‌کنیم، دقیقاً همان کاری که در ارث‌بری دو کلاس از یک interface انجام می‌دهیم.

در نتیجه، اگر سیاست‌مان تغییر کند، تنها کافی است که چند خط کد را تغییر دهیم و بین UI Kits جابه‌جا شویم.

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

https://github.com/EasyMicroservices/UI-Kits/

#inheritance
#csharp
#blazor
#microcomponent
#easymicroservices

@easymicroservice
@easymicroservices
@csharptips

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

کی گفته مایکروسرویس‌ها فقط اینطوری کار میکنن؟ استفاده از بروکرها یک پترن هست که خود استفاده از اونها هم استراتژی های مختلفی داره که یکی از اون‌ها باعث میشه که شما یک درخواست کاربر رو بفرستی و پردازش انجام بشه و بعدا پاسخ رو دریافت کنی. اما شما به همون روش که توی اپلیکیشن‌های مونولیت می‌تونی درخواست مستقیم بزنی و پاسخ رو به مشتری برگردونی توی مایکروسرویس‌ها هم به همین ترتیب پترن‌هایی در بروکر‌ها هست مثلا پترن Request/Replay که همین کار رو انجام میده.

از طرفی شما می‌تونید به روش‌های مختلف دیگه مثل Direct Message و ... توسط اگریگیتورها این قابلیت رو در میکروسرویس‌ها داشته باشید.

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

تنها ترس بیزنس‌ها باید این باشه که به سمت مایکروسرویس رفتن کار آسونی نیست و برای بیزنس‌های بزرگه که هدف ما توی Easy Microservices رفع این مشکل هست که شما در نهایت بتونی برای پروژه های بزرگ و پروژه های کوچیک به سمتش بری، شاید در اوایل اسمش رو نذاری که ما مایکروسرویس هستیم ولی برای تبدیلش به مایکروسرویس کافیه یه روز وقت بذاری و کدهاتو مایکروسرویسی کنی.

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

@easymicroservice
@easymicroservices
@csharptips

سلام.
با یک سورس جالب اومدم، همونطور که قولش رو داده بودم بهتون نمونه‌هایی می‌فرستم که با مطالعه‌ی سورس با نحوه‌ی کارکرد معماری بیشتر آشنا بشید.
یک بازی ساختم، بازی Avalon رو پیاده سازی کردم.
این سورس شامل بکند (سی شارپ Asp Core و EF Core) هست و شامل فرانت Maui که کراس پلتفرمه و میتونید روی اندروید و IOS و ویندوز اجراش کنید.
هم بکند از زیرساخت معماری Easy Microservices داره استفاده می‌کنه و هم فرانت به صورت میکرو کامپوننت توسعه داده شده. برای مثال شما توی فرانت رابط کاربری صفحات لاگین و ثبت نام رو نمی‌بینید و اینها به صورت یک کامپوننت به سورس اضافه شدن و مورد استفاده قرار گرفتن.

زیرساخت بکند از میکروسرویس‌های Authentication، Identity، WhiteLabels، Content و Avalon استفاده کرده. (اطلاعات نقش ها و دسترسی های یوزرها در Authentication مدیریت شده.)

سورس:
https://github.com/Ali-YousefiTelori/AvalonGame

@easymicroservice
@easymicroservices
@csharptips

یک نسخه قابل استفاده از بازی در اندروید.

دارم روی یک زیرساخت عجیب کار میکنم و توی تستهای اولیه‌ش هم جواب گرفتم.
به نظر میاد هنوز بحث بین اینکه کدوم معماری رو انتخاب کنیم داغه نه؟ مونولیت؟ ماژولار یا میکروسرویس یا ماکروسرویس؟
کاری که توی Easy Microservices کردیم اینطوری شد که دیگه مهم نیست کدومش رو انتخاب میکنی، هر زمان که بخوای میتونی روی معماری خودت با کمترین تغییرات سوییچ کنی!
چطوری کار میکنه؟
به جای اینکه از مونولیت و ماژولار بریم سمت مایکروسرویس، برعکس عمل کردیم. ابتدا مایکروسرویس ساختیم حالا زیرساختهای اصلی اونو عنوان ماژول بهش دادیم. اونوقت به عنوان پکیج اینارو میتونید در یک پروژه ی مونولیت نصب کنید با هم تلفیقشون کنید و معماری رو تغییر بدید. هم میتونید ماژولاری داشته باشید که دیتابیس هاش جدا باشن هم میتونید دیتابیس هارو یکی کنید.

@easymicroservice
@easymicroservices
@csharptips

#microservice
#monolith
#modular

چطوری؟
ما قبلا مفهوم ریپازیتوری و Command Query رو حذف کردیم بنابراین نگران کانفیلیت بین Context ها هم نمیتونیم باشیم!
زیرساخت های دیتابیسی طوری ساخته شدن که Schema از Relational (برای جزئیات بیشتر سوال کنید) تفکیک شده یعنی علاوه بر اینکه سوییچ بین دیتابیس NoSql و SQL رو براتون آسون میکنه، استفاده از کانفیگ‌های پیشفرض برای اینکه در یک ContextDb دیگه باهم کار کنن هم وجود داره. برای همین شما میتونید یک پروژه مایکروسرویس رو تبدیل به مونولیت کنید.
چالش ها:
1.دیتابیس ها در حالتی که یکی باشن باید مایگرشن جدا بخورن. در حال حاضر انتظار نداریم از مایگرشن های میکروسرویس ها بتونیم توی مونولیت استفاده کنیم، اما تمامی ساختارهای دیتابیس تا جای ممکن دست نمیخورن.

2.اگر کاستوم ریلیشن داشته باشید باید بیشتر از دو خط کد بزنید تا معماری رو تبدیل کنید! 😳😂
داریم سعی میکنیم از هلو هم راحت تر بره تو گلو!
حمایت.

این سورس به شما کمک میکنه تا آی پی هایی که درخواست اتصال به سرور شمارو میدن تا بالاخره بتونن لاگین بشن و سرور شما هک بشه رو بلاک میکنه.
اگر به event log های سیستم عاملتون برید شاهد درخواست هایی هستید که به سیستم عامل شما زده میشه ولی با خطای اشتباه بودن نام کاربری و رمز عبور مواجه میشه.
اگر سرور شما قبلا هک شده باشه رمز عبور شما توسط این سرور ها در دیتابیسشون ذخیره شده و استفاده مجدد از اون رمز عبور باعث هک مجدد سیستم عامل میشه.
فقط کافیه Role ای که توی فایروال سیستم عاملتون گذاشتید رو به این ابزار بدید تا تمامی آی پی هایی که به شما درخواست میدن رو بلاک کنه و بعدش دیگه این درخواست ها رو در Event Log ویندوز نخواهی دید.
سورس: سی شارپ
سیستم عامل: ویندوز

https://github.com/Ali-YousefiTelori/Firewall-Ip-Blocker

@easymicroservice
@easymicroservices
@csharptips

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

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

#حریم_خصوصی
#رمز_نگاری
#پسورد
#hash
#salt
#password
#privacypolicy

@easymicroservice
@easymicroservices
@csharptips

این سمو گوش کنید 😅