Easy Microservices

رعایت یا ساخت اصول در مهندسی نرم افزار به شما کمک میکنه تا بتونید توسعه‌ی نرم افزار رو نه فقط برای خودتون بلکه برای تیم‌های مختلف آسون کنید. من یه نمونه از این رو در تصویر براتون به نمایش گذاشتم که از یک سری اصول نام گذاری در سورس پروژه استفاده کردم و وقتی میخواستم برای Pipeline های Azure یک تمپلیت بسازم با کمترین زحمت تونستم اینکار رو انجام بدم. یعنی یک کار خوب توی تیم توسعه باعث راحتی کار توی تیم DevOps میشه. @easymicroservices @easymicroservice @csharptips #devops #azure #pipeline

رعایت یا ساخت اصول در مهندسی نرم افزار به شما کمک میکنه تا بتونید توسعه‌ی نرم افزار رو نه فقط برای خودتون بلکه برای تیم‌های مختلف آسون کنید. من یه نمونه از این رو در تصویر براتون به نمایش گذاشتم که از یک سری اصول نام گذاری در سورس پروژه استفاده کردم و وقتی میخواستم برای Pipeline های Azure یک تمپلیت بسازم با کمترین زحمت تونستم اینکار رو انجام بدم. یعنی یک کار خوب توی تیم توسعه باعث راحتی کار توی تیم DevOps میشه. @easymicroservices @easymicroservice @csharptips #devops #azure #pipeline

به حریم خصوصی کاربرانتون اهمیت بدید، شما ممکنه پسوردی که از کاربر دریافت می‌کنید رو برای امنیت اطلاعات و حریم خصوصی کاربر در دیتابیس خودتون رمزنگاری یکطرفه کنید، تا اینجا اوکی، در مرحله بعدی ممکنه از Salt هم استفاده کنید تا کار رو برای هکرها سخت کنید. تا اینجا هم درست. اما آیا پسوردی که کاربر توی وبسایت شما میزنه رو مستقیم از کلاینت به سمت سرور ارسال می‌کنید؟ خب چندتا سوال: من کاربر از کجا بدونم پسورد من رو جای دیگه‌ای ذخیره نمیکنی و ازشون استفاده نمیکنی؟ آیا بهتر نیست که خود شما هم ندونی که پسوردی که من استفاده میکنم چیه و پسورد منو از توی شبکه‌ی خودت رد نکنی و به سمت سرور ارسال نکنی؟ راهکار چیه؟ از یک Salt ثابت هم سمت کلاینت استفاده کنید و پسورد کاربر رو یکبار سمت کلاینت هش کنید و بعدش سمت سرور هرچقدر خواستید Salt و رمزنگاری انجام بدید، اما به خاطر حریم خصوصی کاربر قبل از اینکه اطلاعات رو به سمت سرور بفرستید، اونو سمت کلاینت هم یکبار رمزنگاری کنید. چرا اینکار رو میکنیم؟ ببینید من ممکنه از یک پسورد در چندین وبسایت استفاده کنم، اگر وبسایت‌ها، رمزی که من استفاده میکنم رو رمزنگاری یکطرفه نکنند، هکرها می‌تونند بفهمند رمز من چیه و از اون برای هک کردن اکانتهای من در دیگر وبسایت‌ها هم استفاده کنند. بنابراین لطفا همیشه رمزنگاری پسورد کاربر رودر سمت کلاینت یکبار اعمال کنید. درسته روشهایی وجود داره که شما پسورد ثابت برای وبسایت‌ها استفاده نکنید و بهتره که اینکار رو انجام بدید اما میدونیم که همه‌ی کاربران این رو نمیدونن یا از این روش استفاده نمی‌کنند. #حریم_خصوصی #رمز_نگاری #پسورد #hash #salt #password #privacypolicy @easymicroservice @easymicroservices @csharptips

این سورس به شما کمک میکنه تا آی پی هایی که درخواست اتصال به سرور شمارو میدن تا بالاخره بتونن لاگین بشن و سرور شما هک بشه رو بلاک میکنه. اگر به event log های سیستم عاملتون برید شاهد درخواست هایی هستید که به سیستم عامل شما زده میشه ولی با خطای اشتباه بودن نام کاربری و رمز عبور مواجه میشه. اگر سرور شما قبلا هک شده باشه رمز عبور شما توسط این سرور ها در دیتابیسشون ذخیره شده و استفاده مجدد از اون رمز عبور باعث هک مجدد سیستم عامل میشه. فقط کافیه Role ای که توی فایروال سیستم عاملتون گذاشتید رو به این ابزار بدید تا تمامی آی پی هایی که به شما درخواست میدن رو بلاک کنه و بعدش دیگه این درخواست ها رو در Event Log ویندوز نخواهی دید. سورس: سی شارپ سیستم عامل: ویندوز https://github.com/Ali-YousefiTelori/Firewall-Ip-Blocker @easymicroservice @easymicroservices @csharptips

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

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

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

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

سلام. با یک سورس جالب اومدم، همونطور که قولش رو داده بودم بهتون نمونه‌هایی می‌فرستم که با مطالعه‌ی سورس با نحوه‌ی کارکرد معماری بیشتر آشنا بشید. یک بازی ساختم، بازی Avalon رو پیاده سازی کردم. این سورس شامل بکند (سی شارپ Asp Core و EF Core) هست و شامل فرانت Maui که کراس پلتفرمه و میتونید روی اندروید و IOS و ویندوز اجراش کنید. هم بکند از زیرساخت معماری Easy Microservices داره استفاده می‌کنه و هم فرانت به صورت میکرو کامپوننت توسعه داده شده. برای مثال شما توی فرانت رابط کاربری صفحات لاگین و ثبت نام رو نمی‌بینید و اینها به صورت یک کامپوننت به سورس اضافه شدن و مورد استفاده قرار گرفتن. زیرساخت بکند از میکروسرویس‌های Authentication، Identity، WhiteLabels، Content و Avalon استفاده کرده. (اطلاعات نقش ها و دسترسی های یوزرها در Authentication مدیریت شده.) سورس: https://github.com/Ali-YousefiTelori/AvalonGame @easymicroservice @easymicroservices @csharptips

چرا خیلی‌ها فکر می‌کنن میکروسرویس‌ها کند هستند؟ من از یکی از بچه ها پرسیدم گفتم که پروژه‌ی ERP خودتون رو به سمت مایکروسرویس هم می‌برین؟ گفت بیزنس ما این رو نمی‌خواد، ما نمی‌خوایم مشتری‌هامون صبر کنن تا یک عملیات پست صحنه انجام بشه و بعد ایونت بده به کاربر که بوم کارت انجام شد بفرما، ما می‌خوایم کاربر در لحظه کاری که درخواست میکنه رو دریافت کنه. کی گفته مایکروسرویس‌ها فقط اینطوری کار میکنن؟ استفاده از بروکرها یک پترن هست که خود استفاده از اونها هم استراتژی های مختلفی داره که یکی از اون‌ها باعث میشه که شما یک درخواست کاربر رو بفرستی و پردازش انجام بشه و بعدا پاسخ رو دریافت کنی. اما شما به همون روش که توی اپلیکیشن‌های مونولیت می‌تونی درخواست مستقیم بزنی و پاسخ رو به مشتری برگردونی توی مایکروسرویس‌ها هم به همین ترتیب پترن‌هایی در بروکر‌ها هست مثلا پترن Request/Replay که همین کار رو انجام میده. از طرفی شما می‌تونید به روش‌های مختلف دیگه مثل Direct Message و ... توسط اگریگیتورها این قابلیت رو در میکروسرویس‌ها داشته باشید. اما اگر سوال اینجاست که در هر صورت اینکار کندتر از مونولیت هست پاسخ اینه در میکروسرویس روش‌های دیگه ای وجود داره که شما پرفورمنس بسیار بالاتری نسبت به مونولیت داشته باشی برای مثال شما می‌تونی در مایکروسرویس ها از ماژول‌ها استفاده کنی که مستقیم به دیتابیس دسترسی دارن و خود مایکروسرویس مخصوص اون ماژول هم داره از اون ماژول استفاده میکنه. منظور اینه روش ها برای رفع نیازهای شما زیاد هست و محدودیتی از این بابت وجود نداره این بستگی داره که خواسته‌ی شما چی باشه. تنها ترس بیزنس‌ها باید این باشه که به سمت مایکروسرویس رفتن کار آسونی نیست و برای بیزنس‌های بزرگه که هدف ما توی Easy Microservices رفع این مشکل هست که شما در نهایت بتونی برای پروژه های بزرگ و پروژه های کوچیک به سمتش بری، شاید در اوایل اسمش رو نذاری که ما مایکروسرویس هستیم ولی برای تبدیلش به مایکروسرویس کافیه یه روز وقت بذاری و کدهاتو مایکروسرویسی کنی. معماری ما اینطوریه که بسته به اسکیل پروژه‌ی شما ساختارها شکسته میشن، ما قبلا ساختارها رو براتون شکستیم و فقط کافیه که استفادشون کنید. برای همین آسون میشه و دیگه مهم نیست شما مونولیت هستی یا مایکروسرویس، هر وقت بخوای میتونی کل مایکروسرویس‌هاتو مونولیت کنی، هر وقت خواستی میتونی مجدد همشو مایکروسرویس کنی یا هردوشو داشته باشی تا دیگه دعوایی بین اینکه کدوم بهتره نباشه. @easymicroservice @easymicroservices @csharptips

ارث‌بری در رابط کاربری چگونه است؟ آیا قابلیت پیاده‌سازی دارد؟ ارث‌بری در رابط کاربری مانند برنامه‌نویسی نیست و پیاده‌سازی آن به‌مراتب دشوارتر است، چرا که ابزار‌های رابط کاربری هنوز در حال توسعه‌اند و به آن بلوغ نرسیده‌اند که بتوان روی آن‌ها معماری دقیق و کاملی را پیاده کرد. امروز ما می‌خواهیم یک نمونه از ارث‌بری در رابط کاربری را به شما نشان دهیم تا ببینید که ما در 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

پکیج 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

چرا باید از پترن MVVM توی میکروکامپوننت‌ها استفاده کنیم؟ مزیت این پترن روی معماری میکروکامپوننت چیه؟ همانطور که در تصویر می‌بینید ما به ازای رابط کاربری برای هر کامپوننت بهتره که فقط یک View Model داشته باشیم. View Model شامل بیزینس لاجیک یا به عبارتی Code Behind شما می‌شن. فرض کنید من یک میکرو کامپوننت میزنم که قراره فقط صفحه‌ی لاگین رو پوشش بده. طراحی، پیاده سازی UI ممکنه توی سه تا بیزنس زیر متفاوت باشه: 1.دسکتاپ 2.وب 3.موبایل 4.پنل آیا به ازای هر کدوم از این رابط کاربری ها باید یکبار بیزینس لاجیک ها و Api call ها رو پیاده سازی کنم؟ خیر. برای همین ما یک لایه به نام View Model میسازیم تا تمامی UI ها از اون رابط کاربری استفاده کنند. اینطوری رابط کاربری از لاجیک کاملا جداسازی شده و وابستگی بینشون از بین میره و توسعه سریعتر و خطایابی آسون‌تر از همه مهمتر تست نویسی رو آسونتر میکنیم. @easymicroservice @easymicroservices @csharptips #microcomponent #میکروکامپوننت #میکروفرانت #microfrontend