Developer Advocate

در دنیای React، تفاوت ظریف و مهمی بین useMemo و useCallback وجود دارد که اغلب حتی توسعه‌دهندگان باتجربه، به‌درستی درک نمی‌کنند. بیایید کاربرد بهینه هرکدام را با ذکر مثال بررسی کنیم. 🔹 useMemo زمانی استفاده می‌شود که می‌خواهید نتیجه‌ی یک محاسبه پرهزینه را کش کنید تا فقط وقتی مقادیر وابسته تغییر کرد، مجدداً محاسبه شود. خروجی useMemo یک مقدار است (مثل یک آرایه، شیء، یا حتی یک مقدار عددی):

const expensiveValue = useMemo(() => {
  return calculateHeavy(input1, input2);
}, [input1, input2]);

در این مثال، فقط وقتی input1 یا input2 تغییر کند محاسبه مجدد انجام می‌شود؛ در غیر این صورت، مقدار کش‌شده بازمی‌گردد. --- 🔹 useCallback شاخصه‌ای مشابه دارد اما برای تابع‌ها استفاده می‌شود. اگر تابعی را به یک کامپوننت فرزند پاس می‌دهید، و نمی‌خواهید در هر render ریفرنسی جدید به آن تابع ایجاد شود (که می‌تواند باعث rerender بیهوده شود)، باید آن را با useCallback تلفیق کنید:

const handleClick = useCallback(() => {
  doSomething(param);
}, [param]);

در نتیجه، تا زمانی که param تغییر نکرده، ریفرنس handleClick ثابت باقی می‌ماند؛ این موضوع خصوصاً هنگام استفاده از React.memo یا به کامپوننت‌هایی که فقط تغییر ریفرنس آن‌ها موجب rerender می‌شود، اهمیت فوق‌العاده پیدا می‌کند. --- 🔸 جمع‌بندی عملی: - اگر نیاز به کش‌کردن نتیجه‌ی تابع دارید ➡️ useMemo - اگر می‌خواهید خود تابع را با ریفرنس ثابت نگه دارید ➡️ useCallback ترکیب صحیح این دو Hook در پروژه‌های پیچیده React، می‌تواند عملکرد اپلیکیشن را به‌ شکل چشمگیری بهبود بخشد و از اجرای بیهوده توابع و باز-رندرهای غیرضروری جلوگیری کند. 🧠 همیشه به وابستگی‌ها دقت کنید، زیرا وابستگی نادرست می‌تواند کَش را بی‌اثر کند! @DeveloperAdvocate 🥑

# رشد حرفه‌ای – مدیریت اولویت‌ها در مهندسی نرم‌افزار با ماتریس آیزنهاور یکی از چالش‌های اساسی تیم‌های مهندسی، غرق شدن در لیست بلند وظایف و از دست دادن تمرکز بر روی کارهای باارزش است. ماتریس آیزنهاور رویکردی مؤثر برای اولویت‌بندی بین «فوری/مهم» و «غیرفوری/غیرمهم» ارائه می‌دهد: ➡️ چهار ربع کاربردی برای مهندسان: ۱️⃣ مهم و فوری (Do) - رفع خطاهای بحرانی Production - واکنش سریع به رخدادهای امنیتی - پاسخگویی سریع به مشتریان کلان در شرایط SLA ۲️⃣ مهم و غیرفوری (Plan) - طراحی معماری جدید - بازنگری Performance بخش حیاتی - برنامه‌ریزی برای Migrationهای بزرگ یا Test Coverage ۳️⃣ فوری و غیرمهم (Delegate) - پاسخ به ایمیل‌های تکراری - انجام Code Reviewهای ساده - آپدیت داکیومنت‌های فرعی ۴️⃣ غیرفوری و غیرمهم (Eliminate) - بهبود داکیومنت‌های قدیمی که مصرفی ندارند - کار روی POCهای بی‌نتیجه - جلسات بدون هدف روشن --- 🔥 نکته عملی: در آغاز هر هفته، لیست تسک‌ها را ترسیم و در چهارچوب این ماتریس مرتب کنید. اجازه ندهید کارهای فوری اما بی‌اهمیت، زمان ارزشمند «حل مسائل بنیادین مهندسی» را ببلعند. --- برای اتوماسیون بیشتر، می‌توانید یک Enum و Extension Method در #CSharp بسازید تا حتی در Issue Tracker هم این دسته‌بندی را پیاده‌سازی کنید:

public enum EisenhowerQuadrant
{
    Do,
    Plan,
    Delegate,
    Eliminate
}

public static class EisenhowerExtensions
{
    public static EisenhowerQuadrant Classify(this TaskItem task)
    {
        // نمونه: شما باید منطق واقعی را طبق نوع و اهمیت تسک بنویسید!
        if (task.IsCritical && task.IsUrgent)
            return EisenhowerQuadrant.Do;
        if (task.IsCritical)
            return EisenhowerQuadrant.Plan;
        if (task.IsUrgent)
            return EisenhowerQuadrant.Delegate;
        return EisenhowerQuadrant.Eliminate;
    }
}

✨ اولویت‌بندی هوشمندانه، کلید رشد حرفه‌ای و توسعه تأثیرگذار محصول است. @DeveloperAdvocate 🥑

🚀 الگوی CQRS در دات‌نت: چرا باید Command و Query را جدا کنیم؟ وقتی صحبت از معماری پیشرفته در اپلیکیشن‌های enterprise محور با .NET می‌شود، پیاده‌سازی CQRS به‌ویژه در پروژه‌هایی با دیتابیس‌هایی مانند SQL Server یا PostgreSQL می‌تواند تحولی جدی در maintainability و scalability ایجاد کند. تفکیک Command و Query باعث می‌شود: - عملیات تغییر (write) و خواندن (read) را جدا و مستقل توسعه دهید - مدل‌های داده‌ای بهینه و متفاوت برای خواندن و نوشتن بسازید (مثلاً denormalized view برای Queryها) - اجرای اعتبارسنجی‌های متفاوت برای هر مسیر - scale کردن read/write به طور مستقل، به‌ویژه وقتی تعداد readها بسیار بیشتر است یک Handler ساده برای Command را ببینید:

public record UpdateUserCommand(Guid UserId, string NewEmail) : IRequest;

public class UpdateUserCommandHandler : IRequestHandler<UpdateUserCommand>
{
    private readonly UserDbContext _context;

    public UpdateUserCommandHandler(UserDbContext context)
    {
        _context = context;
    }

    public async Task<Unit> Handle(UpdateUserCommand request, CancellationToken cancellationToken)
    {
        var user = await _context.Users.FindAsync(new object[]{request.UserId}, cancellationToken);
        if (user == null)
            throw new NotFoundException();

        user.Email = request.NewEmail;
        await _context.SaveChangesAsync(cancellationToken);

        return Unit.Value;
    }
}

و یک Query Handler به‌صورت readonly:

public record GetUserByIdQuery(Guid UserId) : IRequest<UserDto>;

public class GetUserByIdQueryHandler : IRequestHandler<GetUserByIdQuery, UserDto>
{
    private readonly UserDbContext _context;

    public GetUserByIdQueryHandler(UserDbContext context)
    {
        _context = context;
    }

    public async Task<UserDto> Handle(GetUserByIdQuery request, CancellationToken cancellationToken)
    {
        var user = await _context.Users
            .AsNoTracking()
            .Where(u => u.Id == request.UserId)
            .Select(u => new UserDto(u.Id, u.Email, u.Name))
            .FirstOrDefaultAsync(cancellationToken);

        if (user == null)
            throw new NotFoundException();

        return user;
    }
}

این ساختار + استفاده از MediatR و dependency injection در ASP.NET Core، منجر به codebase تمیز و قابل توسعه‌ای خواهد شد، به‌خصوص زمانی که پروژه‌های distributed یا microservices دارید یا حتی می‌خواهید روی یک دیتابیس مثل MongoDB حرکت کنید و eventually consistency و event sourcing را اضافه نمایید. 🧩 این جداسازی را از پروژه‌ی بعدی شروع کنید و سریعاً تاثیر فوق‌العاده آن را ببینید. @DeveloperAdvocate 🥑

در مسیر رشد حرفه‌ای، یکی از نقاط ضعف رایج بین توسعه‌دهندگان ارشد، کم‌اهمیت شمردن مستندسازی صحیح است؛ مخصوصاً زمانی که باید بهترین تجربه را برای استفاده‌کنندگان فراهم کنیم. مدل Diátaxis چهار نوع کلیدی محتوا را برای مستندسازی حرفه‌ای پیشنهاد می‌دهد: ۱. Tutorials (آموزش گام‌به‌گام): مسیر یادگیری عملی و واضح با مثال‌هایی از دنیای واقعی—مثل ساختن اولین ماژول با یک کتابخانه خاص. ۲. How-To Guides (راهنمای انجام وظیفه): دستورالعمل‌های دقیق "چگونه کاری را انجام دهم؟" که مشکل یا سناریوی مشخصی را حل می‌کند—برای مثال نحوه ثبت یک middleware شخصی در ASP.NET Core. ۳. Reference (مستندسازی مرجع): توضیح کامل و بی‌طرف ویژگی‌ها، APIها و پارامترها—مثلاً مستندات کلاس‌های اصلی یک سرویس. ۴. Explanation (توضیحات مفهومی): تبیین چرایی و مفاهیم زیربنایی—مثل تفاوت بین Dependency Injection و Service Locator. برای نمونه، فرض کنید یک متد Extension برای IEnumerable نوشتید و می‌خواهید همکارانتان سریع آن را بفهمند و به کار ببرند. به جای یک بخش «استفاده» ناقص، مستندسازی را به چهار دسته زیر تفکیک کنید:

/// <summary>
/// بررسی می‌کند که همه آیتم‌ها مقدار غیر null دارند.
/// </summary>
/// <param name="source">کلکسیون ورودی</param>
/// <returns>در صورت نبود هیچ مقدار null، درست برمی‌گرداند.</returns>
/// <example>
/// استفاده به‌صورت Linq:
/// var allNonNull = collection.AllNotNull();
/// </example>
/// <remarks>
/// این متد lazy evaluation را رعایت می‌کند و در اولین null عملیات متوقف می‌شود.
/// </remarks>
public static bool AllNotNull<T>(this IEnumerable<T> source) => source.All(x => x != null);

دفعه بعد که مستند می‌نویسید، Diátaxis را یادآور باشید: هر نیاز مخاطبتان را با دسته‌ای مجزا، واضح و قابل جستجو پاسخ دهید. این نگاه باعث می‌شود APIهای شما قابل‌استفاده‌تر و قابل‌اعتمادتر شوند و بار نگهداری تیم تا حد قابل توجهی کاهش یابد. @DeveloperAdvocate 🥑

🚀 React Server Components: استریم داده از سرور به کلاینت تقریباً همه ما به دریافت داده در سمت سرور عادت داریم، اما ترکیب React Server Components (RSC) با استریمینگ واقعاً پتانسیل‌های جدیدی باز می‌کند. فرض کنید داده‌های سنگینی دارید (مثلا لیست بلند کتاب‌ها از یک API)، و نمی‌خواهید کل داده را یک‌جا لود کنید بلکه می‌خواهید بخشی از UI فوراً رندر شده و مابقی به تدریج بیاید. با Next.js 13+ (و React 18+) می‌توانید از قابلیت استریمینگ SSR، همراه RSC، برای حداکثر کارایی استفاده کنید:

// app/books/page.jsx (یا هر route server component)
import { Suspense } from "react";
import BooksList from "./BooksList";

export default function Page() {
  return (
    <div>
      <h1>📚 لیست کتاب‌ها</h1>
      <Suspense fallback={<SkeletonBooks />}>
        <BooksList />
      </Suspense>
    </div>
  );
}

// BooksList.jsx (Server Component)
async function fetchBooks() {
  // فرض: fetch از یک API خارجی سنگین
  const res = await fetch("https://api.example.com/books", { cache: 'no-store' });
  return res.json();
}

export default async function BooksList() {
  const books = await fetchBooks();

  // به صورت SSR رندر می‌شود و می‌تواند صدها کتاب باشد
  return (
    <ul>
      {books.map(book => (
        <li key={book.id}>{book.title}</li>
      ))}
    </ul>
  );
}

// SkeletonBooks.jsx (Client Component for fallback)
export default function SkeletonBooks() {
  return <div>در حال بارگذاری لیست کتاب‌ها...</div>;
}

🔹 کلید معماری: - فقط Server Components مجاز به data fetching هستند (fetchBooks)، و استریمینگ زمانی به کار می‌آید که ترکیب Suspense + خط قطع داده (به‌واسطه تاخیر fetch) رخ دهد. - Next.js با استریم کردن بخشی از HTML تا آماده‌شدن داده اصلی، تجربه‌ی کاربری را بهینه می‌کند. - کامپوننت Skeleton در کلاینت اجرا می‌شود و به محض دریافت داده، به صورت استریم جایگزین می‌گردد. 💡 چطور این معماری را جدی بگیرید؟ در پروژه‌هایی با داده‌ی حجیم یا API کند، حتما از استریمینگ با Server Components استفاده کنید تا TTFB بسیار پایین و UX به مراتب بهتری داشته باشید. 🔗 سوال برای شما: تا چه حد از SSR استریمینگ در پروژه‌های خود استفاده کردید؟ تجربیات و ملاحظات معماری شما چیست؟ @DeveloperAdvocate 🥑

🔸 فرق بین Singleton، Scoped و Transient در Dependency Injection دات‌نت درک عمیق scope در DI دات‌نت، کلید خلق سرویس‌هایی مقیاس‌پذیر و کم‌خطاست. بیایید نگاه دقیق‌تری بیندازیم: ۱️⃣ Singleton سرویس تنها یک‌بار ساخته می‌شود و تا پایان حیات App (معمولاً WebHost) باقی می‌ماند. نکته: در اپ‌های ASP.NET Core، حتی اگر چندین درخواست موازی باشد، همه به همان instance وصل‌اند. مناسب برای: سرویس‌های Stateless یا cache/sharing جهانی (مانند HttpClientFactory). ۲️⃣ Scoped برای هر scope جدید یک instance ساخته می‌شود. در اپ‌های تحت وب (= هر HTTP Request)، instance یکتا در همان درخواست و بین سرویس‌های وابسته به هم share می‌شود، ولی بین درخواست‌ها مجزاست. مناسب برای: سرویس‌هایی مثل UnitOfWork، DbContext، لاگیک‌های per-request. ۳️⃣ Transient هر بار که DI container باید سرویس را resolve کند، یک instance جدید می‌سازد. مناسب برای: سرویس‌های stateful یا lightweight که نیاز به isolation کامل دارند. 🔹 مثالی ساده:

services.AddSingleton<IMyService, MyService>(); // instance یکتا
services.AddScoped<IMyService, MyService>();    // instance در هر درخواست HTTP
services.AddTransient<IMyService, MyService>(); // instance جدید در هر resolve

⚡️ نکته حرفه‌ای: استفاده نادرست از scoped یا transient برای سرویس‌های با state اشتراکی می‌تواند به memory leak یا مشکلات threading منجر شود. همچنین، حواس‌تان باشد که injected سرویس‌های با scope وسیع‌تر در سرویس‌های با scope کوچکتر مجاز نیست (مثلاً: Singleton نمی‌تواند یک Scoped را inject کند)، وگرنه runtime exception خواهید گرفت. ✅ توصیه: همیشه بسته به نیاز سرویس،‌وسیع‌ترین scope ممکن را انتخاب نکنید؛ context و مصرف واقعی را در نظر بگیرید. For example، DbContext باید scoped باشد، نه singleton یا transient. @DeveloperAdvocate 🥑

🔹 یکی از ابزارهایی که بهره‌وری توسعه‌دهندگان .NET و JavaScript را به شکل چشمگیری افزایش می‌دهد، افزونه‌ی VS Code با نام “GitLens – Git supercharged” است. این افزونه تنها تاریخچه‌ی commitها را نمایش نمی‌دهد، بلکه عمق معماری تغییرات را به پروژه‌ی شما می‌آورد. چهار قابلیت که من به‌شدت برای تیم‌های حرفه‌ای توصیه می‌کنم: 1️⃣ Blame هوشمند در لحظه: وقتی مشغول refactor کردن یک متد پیچیده در کد C# یا TypeScript هستید، کافیست روی خط مدنظر قرار بگیرید تا نویسنده و شرح commit مربوط به همان خط را در عمل مشاهده کنید؛ این درک معماری تصمیمات قبلی را در لحظه ممکن می‌کند. 2️⃣ Code Lens برای پیمایش سریع: ماژول‌های دات‌نت بزرگ یا سرویس‌های میکروسرویس معمولاً چندین نفر توسعه‌دهنده دارند. GitLens مثل یک نقشه‌ی معماری لحظه‌ای عمل می‌کند و به شما می‌گوید چه کسی بیشترین تغییر را روی این فایل یا خط داده است و حتی دکمه‌ی پرش به Pull Request مرتبط را فراهم می‌کند. 3️⃣ Component-level History: تاریخچه تغییرات هر کلاس یا متد را می‌توانید در یک Timeline کاملاً مصور ببینید؛ این خصوصاً هنگام معیوب‌یابی (debugging) کد legacy و ردیابی علل تصمیم‌های معماری گذشته، کلیدِ موفقیت است. 4️⃣ Integration با Repoهای Remote: حتی اگر روی چندین رپوزیتوری git مختلف (GitHub, Azure DevOps, GitLab) کار می‌کنید، همه اطلاعات و تعامل‌ها مستقیماً در VS Code و بدون سوییچ به ترمینال یا صفحه وب ممکن است. نمونه: فرض کنیم در یک پروژه ASP.NET Core دارید متدی به نام CalculateDiscount را ردیابی می‌کنید:

public decimal CalculateDiscount(Customer customer)
{
    // ...
}

روی متد قرار بگیرید؛ چند کلیک کافیست تا هم نویسنده، هم منطق commit و هم تغییرات تاریخی آن متد را متمرکز ببینید ـ بی‌نیاز از ترک محیط، همه چیز در اختیار است. این تجربه “Context-driven coding” باعث می‌شود تصمیمات معماری نه بر مبنای حدس، بلکه مبتنی بر داده اتخاذ شوند — خصوصاً در تیم‌های distributed و پروژه‌های بلندمدت. 🔷 توسعه کد حرفه‌ای امروز، یعنی مدیریت تغییرات با هوشمندی و سرعت. اگر تابحال GitLens را با تمام قابلیت‌های سطح‌بالایش استفاده نکرده‌اید، امروز نقطه شروع خوبی است. @DeveloperAdvocate 🥑

🎯 مدلسازی داده در MongoDB برای سیستم سفارش غذا (Food Order System): راهنمایی عمیق فرض کنید می‌خواهیم یک سیستم سفارش آنلاین غذا (مانند SnappFood) با MongoDB مدل کنیم. هدف: بهینه‌سازی کوئری رایج مثل دریافت سفارش‌های اخیر کاربر و مشاهده آیتم‌ها به همراه وضعیت پرداخت. 🔹 موجودیت‌ها (Entities): - User - Order - Restaurant - MenuItem 🔻 استراتژی مدل‌سازی: Embedded vs Referenced در MongoDB، مدل داده‌تان باید متناسب با الگوی دسترسی و بیشتر در جهت Aggregate-centric باشد. برای این سناریو: - اطلاعات سفارش در کنار آیتم‌های آن باید سریع و اتمی قابل بازیابی باشد (optimization for read). - اطلاعات کاربر و رستوران، معمولاً تغییر نمی‌کند و اغلب توسط Reference ارجاع داده می‌شود تا Redundancy کاهش یابد. ◼️ ساختار دیتای سفارش:

{
  "_id": ObjectId("..."),
  "userId": ObjectId("..."),
  "restaurantId": ObjectId("..."),
  "orderDate": ISODate("2024-06-19T12:30:00Z"),
  "status": "PAID",
  "totalPrice": 450000,
  "items": [
    {
      "menuItemId": ObjectId("..."),
      "name": "برگر کلاسیک",
      "quantity": 2,
      "price": 150000
    },
    {
      "menuItemId": ObjectId("..."),
      "name": "سیب‌زمینی ویژه",
      "quantity": 1,
      "price": 50000
    }
  ],
  "payment": {
    "method": "Online",
    "transactionId": "xyz123",
    "paidAt": ISODate("2024-06-19T12:35:01Z")
  }
}

🔵 نکات مهم معماری: 1. Embedding Items: برای آیتم‌های سفارش، Embedding منطقی است، چون همیشه همراه سفارش بازیابی می‌شوند، اندازه داکیومنت به ندرت از ۱۶MB بیشتر خواهد شد. 2. Reference to User & Restaurant: صرفاً Id را ذخیره می‌کنیم تا نیاز به Update مکرر اطلاعات دموگرافیک کاربر یا رستوران را حذف کنیم. 3. Denormalization: برخی فیلدها مثل name هر MenuItem را Embed می‌کنیم (با اینکه قابل Reference است)، چون احتمال تغییر محصول در آینده کم است و اهمیت یکپارچگی گذشته بر جایگزینی برتری دارد. 🔶 بهره‌برداری از C# Client: در اغلب پروژه‌ها، با استفاده از ساختار POCO ها می‌توانید مدل را ساده پیاده‌سازی کنید:

public class Order
{
    [BsonId]
    public ObjectId Id { get; set; }
    [BsonElement("userId")]
    public ObjectId UserId { get; set; }
    [BsonElement("restaurantId")]
    public ObjectId RestaurantId { get; set; }
    [BsonElement("orderDate")]
    public DateTime OrderDate { get; set; }
    [BsonElement("status")]
    public string Status { get; set; }
    [BsonElement("totalPrice")]
    public int TotalPrice { get; set; }
    [BsonElement("items")]
    public List<OrderItem> Items { get; set; }
    [BsonElement("payment")]
    public PaymentInfo Payment { get; set; }
}

public class OrderItem
{
    [BsonElement("menuItemId")]
    public ObjectId MenuItemId { get; set; }
    [BsonElement("name")]
    public string Name { get; set; }
    [BsonElement("quantity")]
    public int Quantity { get; set; }
    [BsonElement("price")]
    public int Price { get; set; }
}

public class PaymentInfo
{
    [BsonElement("method")]
    public string Method { get; set; }
    [BsonElement("transactionId")]
    public string TransactionId { get; set; }
    [BsonElement("paidAt")]
    public DateTime PaidAt { get; set; }
}

🧩 بهینه‌سازی‌ کلیدی - بر روی userId و orderDate ایندکس ترکیبی بسازید تا کوئری سفارشات اخیر یک کاربر فوق‌سریع شود. - چنان‌چه فیلدهای embedded رشد غیر قابل کنترل داشت، Sharding یا محدودسازی آیتم‌های Embed شده را ارزیابی کنید. ⚡️ کلید موفقیت در مدل‌سازی MongoDB: data that is accessed together, should be stored together! از aggregate-centric thinking غافل نشوید. @DeveloperAdvocate 🥑

🎯 تفاوت WebSocket و SSE (Server-Sent Events) در فرن‌اند: دو پیاده‌سازی کاربردی در .NET هر دو تکنولوژی برای Push از سرور به کلاینت عالی‌اند، اما انتخاب صحیح بسته به نیاز شما دارد. WebSocket ارتباط دوطرفه و مبتنی بر سوکت را فراهم می‌کند؛ SSE یک راه حل ساده و یکطرفه با HTTP است. در اینجا نمونه کد سرور هر دو با ASP.NET Core 8+ را می‌بینید (dev-friendly و قابل توسعه برای استفاده production): --- 🔥 WebSocket در ASP.NET Core

// Startup.cs یا Program.cs
app.UseWebSockets();

app.Map("/ws", async context =>
{
    if (context.WebSockets.IsWebSocketRequest)
    {
        using var webSocket = await context.WebSockets.AcceptWebSocketAsync();
        var buffer = new byte[1024 * 4];

        while (webSocket.State == WebSocketState.Open)
        {
            // دریافت پیام از کلاینت
            var result = await webSocket.ReceiveAsync(new ArraySegment<byte>(buffer), CancellationToken.None);

            if (result.MessageType == WebSocketMessageType.Text)
            {
                var receivedMessage = Encoding.UTF8.GetString(buffer, 0, result.Count);
                var responseMessage = $"Echo: {receivedMessage}";

                // ارسال پاسخ به کلاینت
                var responseBuffer = Encoding.UTF8.GetBytes(responseMessage);
                await webSocket.SendAsync(
                    new ArraySegment<byte>(responseBuffer),
                    WebSocketMessageType.Text,
                    true,
                    CancellationToken.None);
            }
            else if (result.MessageType == WebSocketMessageType.Close)
            {
                await webSocket.CloseAsync(WebSocketCloseStatus.NormalClosure, "Closed by server", CancellationToken.None);
            }
        }
    }
    else
    {
        context.Response.StatusCode = 400;
    }
});

--- ⚡️ Server-Sent Events (SSE) در ASP.NET Core

// Startup.cs یا Program.cs
app.Map("/sse", async context =>
{
    context.Response.Headers.Add("Content-Type", "text/event-stream");
    context.Response.Headers.Add("Cache-Control", "no-cache");
    var counter = 0;

    while (!context.RequestAborted.IsCancellationRequested)
    {
        var data = $"data: Message #{counter++} at {DateTime.UtcNow:O}\n\n";
        await context.Response.WriteAsync(data);
        await context.Response.Body.FlushAsync();

        await Task.Delay(1000); // ارسال پیام هر ۱ ثانیه
    }
});

--- برای frontend، در WebSocket از new WebSocket(url) و در SSE از new EventSource(url) استفاده کنید. ✅ WebSocket مناسب چت یا اپلیکیشن‌هایی است که به ارسال و دریافت همزمان پیام نیاز دارند ✅ SSE برای اطلاع‌رسانی ساده، تحلیل داده‌های زنده یا ارسال Log عالی است انتخاب درست ابزار، گامی مهم در معماری پایدار 🚀 @DeveloperAdvocate 🥑

اگر نیاز به کنترل همزمان دسترسی چندین ترد به یک منبع در #C دارید، کدام را انتخاب می‌کنید: Mutex یا SemaphoreSlim؟ تفاوت‌های کلیدی آن‌ها را زیر ذره‌بین ببینید: 🔸 Mutex - مناسب برای سناریوهایی که واقعاً به انحصار کامل (mutual exclusion) نیاز است—یعنی تنها یک ترد (یا حتی یک پروسه دیگر) اجازه ورود دارد. - سینک بین‌پردازشی: میوتکس می‌تواند بین چندین فرایند (process) به اشتراک گذاشته شود (inter-process). - عملکرد کندتر به دلیل تعامل با کرنل و overhead بین‌پردازشی. - مثال استفاده:

using (var mutex = new Mutex(false, "Global\\MyAppResource"))
{
    if (mutex.WaitOne(TimeSpan.FromSeconds(10)))
    {
        try
        {
            // دسترسی انحصاری به منبع
        }
        finally
        {
            mutex.ReleaseMutex();
        }
    }
}

🔸 SemaphoreSlim - کنترل همزمان چند ترد تا سقف مشخص روی یک منبع (مثلاً ۳ ترد همزمان). - فقط درون یک پروسه کار می‌کند (inter-thread)، هیچ‌گونه اشتراک بیرونی. - بسیار سبک‌تر و سریع‌تر از میوتکس (کاملاً user-mode مگر در شرایط کمیاب). - async-friendly — مناسب برای کل async/await مبتنی بر Task:

private static readonly SemaphoreSlim semaphore = new SemaphoreSlim(3);

async Task UseResourceAsync()
{
    await semaphore.WaitAsync();
    try
    {
        // استفاده همزمان تا سقف ۳ ترد
    }
    finally
    {
        semaphore.Release();
    }
}

✅ خلاصه کاربرد: - اگر فقط انحصار کامل (۱ ترد) نیاز دارید و احتمالاً بین پروسه‌ها: Mutex - اگر کنترل تعداد (n>1) ترد در یک پروسه مهم است و Async بودن حیاتی است: SemaphoreSlim #CSharp #Threading #Concurrency #Architecture @DeveloperAdvocate 🥑

🎯 نکته کلیدی برای نوشتن Dockerfile اپلیکیشن‌های .NET: استفاده از چند مرحله‌ای (multi-stage builds) جهت کوچک‌سازی تصویر نهایی و بهبود امنیت یکی از بهترین روش‌ها در داکرایز کردن اپلیکیشن‌های دات‌نت استفاده از الگوی multi-stage build است. این کار موجب می‌شود image نهایی فقط شامل باینری‌های لازم برای اجرا باشد، در حالی که ابزارها و وابستگی‌های زائد نظیر SDK، از نسخه نهایی حذف می‌شود. الگویی حرفه‌ای و قابل تعمیم:

# مرحله build: فقط برای کامپایل پروژه
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app/publish --no-restore

# مرحله runtime: فقط شامل باینری اجرایی و کتابخانه‌های مورد نیاز
FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine AS final
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "YourAppName.dll"]

مزیت‌های کلید این رویکرد: - حجم کمتر image (مثلا به جای ۷۰۰ مگابایت، <۱۰۰ مگابایت) - حمله‌پذیری کمتر (سطح حمله کوچکتر) - تمیز و قابل بازتولید برای هر محیط 🔍 توصیه: برای پروژه‌های حساس امنیتی، از تصاویر Base رسمیِ Alpine Linux در مرحله runtime استفاده کنید؛ سطح آسیب‌پذیری آنها نسبتا پایین‌تر است و اپدیت‌های سریعتری دارد. #Docker #DotNet #BestPractices #Architecture @DeveloperAdvocate 🥑

⚡️ تحلیل خودکار Canary Release با متریک‌ها: نگاهی عمیق برای معماران DevOps در استراتژی‌های انتشار پیشرونده (Progressive Delivery)، انتشار کاناری (Canary Release) به شما امکان می‌دهد نسخه‌ی جدید را به بخشی از ترافیک ارسال کنید و رفتار سیستم را با نسخه قدیمی مقایسه نمایید. اما چطور این تحلیل را به‌صورت خودکار و مبتنی‌بر داده انجام دهیم؟ ۱. تعریف معیارها (Baseline Metrics): ابتدا باید متریک‌های کلیدی مثل latency، error rate و throughput را برای هر دو نسخه جمع‌آوری کنید. این داده‌ها معمولاً توسط ابزارهایی مثل Prometheus و Grafana جمع می‌شوند. ۲. سنجش سلامت کاناری: ابزاری مثل Kayenta (وابسته به Spinnaker) یا سرویس‌های سفارشی می‌توانند داده‌های متریک دو نسخه را مقایسه کنند. تکنیک رایج، مقایسه آماری با sliding window است. خروجی این تحلیل اغلب امتیازی بین ۰ تا ۱ است: - اگر امتیاز پایین‌تر از threshold تعریف‌شده باشد (مثلاً ۰.۸)، rollout معلق یا بازگشت (rollback) انجام می‌شود. ۳. اتوماسیون در لایه CI/CD: معمولاً pipeline به شکل زیر عمل می‌کند:

// Pseudo-pipeline for automated canary analysis
Deploy(Canary);
Wait(MinimumTraffic);
Score = RunMetricAnalysis(Baseline, Canary);
if (Score < Threshold)
{
    Rollback(Canary);
    NotifyTeam("Canary failed, rolled back.");
}
else
{
    PromoteToProduction(Canary);
}

۴. یک‌پارچگی با ابزارهای زیرساخت: - Prometheus: جمع‌آوری metrics. - Kayenta: تحلیل آماری و decision making. - Spinnaker/Azure DevOps Pipelines/GitHub Actions: اجرای اتوماتیک مراحل rollout و بازگشت. ۵. Best Practice: معیارهای موفقیت باید “SLO-driven” باشند، نه صرفاً تابع لاگ خطا یا latency خام؛ مثلاً درصد درخواست‌هایی که ظرف ۹۵پرسانتایل تا ۲۰۰ms پاسخ می‌گیرند = ۹۹٪. این رویکرد امکان می‌دهد مهارت DevOps را فراتر از manual testing برده و با تصمیم‌گیری Autopilot، ریسک انتشار را به‌شدت کاهش دهید. #DevOps #CanaryRelease #Metrics #Automation @DeveloperAdvocate 🥑

✴️ تفاوت Isolation Level های Repeatable Read و Serializable — سناریوی عملی برای معماران دیتا تصور کنید ما در حال توسعه‌ی یک سیستم رزرو بلیط هستیم و یک جدول به نام "Tickets" داریم. دو نفر به صورت همزمان می‌خواهند برای رویداد A بلیط رزرو کنند. یک query باقی‌مانده ظرفیت را محاسبه و سپس تراکنش را ثبت می‌کند. ▪️ Repeatable Read: در این سطح، یک تراکنش وقتی رکوردی را می‌خواند، در طول تراکنش همان داده را خواهد دید (= Phantom Read رخ نمی‌دهد)، اما می‌تواند رکوردهای جدیدی که توسط سایر تراکنش‌ها افزوده شده باشند را بیند (Phantom Rows را "در اکثر سیستم‌ها" درست محافظت نمی‌کند).

// تراکنش اول (T1)
BEGIN TRANSACTION
SELECT COUNT(*) FROM Tickets WHERE EventId = 1 AND Status = 'Reserved'  // فرضاً 98
-- کاربر دوم بین این دو Query بلیت رزرو می‌کند
INSERT INTO Tickets (EventId, Status) VALUES (1, 'Reserved')  // تداخلی به وجود نمی‌آید
COMMIT

▪️ Serializable: سختگیرانه‌ترین سطح ایزولیشن. انگار همه‌ی تراکنش‌ها پیاپی اجرا شده‌اند. اگر تراکنش اول شمارش رکوردها را انجام دهد، هیچ تراکنش دیگری نمی‌تواند بین این بازه رکورد مشابه ایجاد یا تغییر دهد تا زمانی که T1 به پایان برسد — احتمالاً تراکنش دوم بلوکه یا Rollback می‌شود.

// تراکنش اول (T1)
BEGIN TRANSACTION
SELECT COUNT(*) FROM Tickets WHERE EventId = 1 AND Status = 'Reserved'  // 98
-- هر تلاشی برای INSERT/UPDATE روی EventId=1 و Status='Reserved' تا پایان این تراکنش یا بلوکه می‌شود یا شکست می‌خورد
COMMIT

🔹 جمع‌بندی عملی: - Repeatable Read برای خواندن داده‌های موجود عالی است، اما Phantom Reads را روی ردیف‌های جدید نمی‌تواند به طور کامل دفع کند. - Serializable مطمئن‌ترین سطح است، اما کارایی را قربانی می‌کند؛ مخصوصاً در سناریوهای high contention (مثل فروش بلیط). ⚡ اگر atomicity کامل روی مجموعه‌ای از ردیف‌ها نیاز دارید (مثل سیستم‌های حسابداری یا موجودی)، همیشه به Serializable فکر کنید — حتی اگر گران تمام شود. #IsolationLevels #DatabaseDesign #Concurrency #dotnet @DeveloperAdvocate 🥑

Monorepo vs. Polyrepo: معماری ریپازیتوری برای تیم‌های درحال رشد بحث مونورپو (Monorepo) و پلی‌ریپو (Polyrepo) مدت‌هاست داغ است؛ اما برای تیم‌های در حال رشد، هر انتخابی ابعاد استراتژیک عمیقی دارد. بیایید مزایا و چالش‌های هر رویکرد را لمس کنیم: 🔶 Monorepo — تمامی پروژه‌ها در یک ریپازیتوری - مزایا: - Visibility و Discoverability: دسترسی یکپارچه به همه کدها و تغییرات سراسری. - Refactoring نامحدود: تغییرات کراس‌کاتینگ مثل API contractها یا shared utilityها را با یک PR پیش می‌برید. - Dependency Management سهل: نسخه‌بندی و سازگاری دسترسی محور است و لایبرری‌های اصلی همیشه آپدیت هستند. - Atomic Changes: قابلیت roll-out یا roll-back همزمان چند سرویس و کتابخانه به‌سادگی ممکن است. - معایب: - Scalability SCM: ابزار Git روی ریپازیتوری حجیم ممکن است کند شود (به‌ویژه با history و تعداد فایل بالا). - Context Overload: هر دولوپر با انبوهی از پروژه‌هایی که الزاماً به آن‌ها ربطی ندارد مواجه است. - CI/CD Complexity: buildهای غیرهوشمند می‌توانند منجر به pipelineهای کند و resource-intensive شوند. 🔷 Polyrepo — هر پروژه یا سرویس، یک ریپازیتوری - مزایا: - Isolation: تیم‌ها کنترل کامل روی ورژن‌دهی و پروسه‌ی انتشار هر سرویس یا lib را دارند. - Permissioning: مدیریت دسترسی ریزدانه‌ای ساده‌تر است؛ به سادگی می‌توان با دسترسی‌های تفکیکی کار کرد. - Tooling سریع: عملیات Git و pipelineها خیلی سریع‌تر و سبک‌تر هستند. - معایب: - Dependency Hell: هماهنگ نگه‌داشتن shared utils یا contractها طاقت‌فرساست و احتمال نسخه‌بندی ناسازگار بالاست. - Refactoringهای سراسری سخت: هر تغییر بزرگ در API باید بین چندین ریپو sync و release شود. - Discoverability پایین: نویگیت کردن بین ریپوها و یادگیری اکوسیستم وقتگیر و مستعد دوباره‌کاریست. 📌 نکته معماری: برای تیم‌های .NET‌ای که با داکر و سرویس‌های مایکروسرویس کار می‌کنند، Monorepo با Split Build Pipeline و استفاده از ابزارهایی مثل Nx، Lage یا حتی custom MSBuild scripting فوق‌العاده جواب می‌دهد. کافیست به هر پروژه‌ی جداگانه، CI/CD پارتیشن‌یافته اختصاص دهید تا نقطه‌ضعف performance حل گردد.

// نمونه تعریف .NET Solution Monorepo با چند پروژه
// my-monorepo/
//     src/
//         ServiceA/ServiceA.csproj
//         ServiceB/ServiceB.csproj
//         Shared/Shared.csproj
//     MySolution.sln

// رفرنس‌دهی داخلی:
<ProjectReference Include="..\Shared\Shared.csproj" />

در حالی که Polyrepo برای سازمان‌های چندتیمی با ownership و عمر پروژه‌های نامرتبط مناسب‌تر است، Monorepo برای تیم‌های با codebase tightly coupled و refactoring سنگین، انعطاف و سرعت بیشتری ایجاد می‌کند. در نهایت: انتخاب به معماری تیم، maturity tooling، و آینده پروژه برمی‌گردد. 👩‍💻👨‍💻 @DeveloperAdvocate 🥑

⚡️ مقایسه‌ی gRPC و REST در معماری مایکروسرویس‌ها یکی از تصمیمات مهم هنگام طراحی سیستم‌های مایکروسرویس، انتخاب پروتکل ارتباطی بین سرویس‌هاست: REST یا gRPC؟ هر کدام نقاط قوت و ضعف خاص خود را دارند و انتخاب صحیح آن‌ها به زمینه‌ی پروژه بستگی دارد. 🔹 REST مزیت REST در پیاده‌سازی ساده، خوانایی بالا و اکوسیستم وسیع است. REST مبتنی بر HTTP/1.1 است و داده‌ها معمولاً به صورت JSON رد و بدل می‌شوند، که خواندن آن حتی با curl و ابزارهای ساده ممکن است. REST به دلیل Stateless بودن به سادگی مقیاس‌پذیر است و برای ارتباط با کلاینت‌های مختلف (موبایل، وب، یا حتی اکوسیستم‌های ناهمگون) انتخاب ایده‌آلی است. 🔸 gRPC gRPC از پروتکل HTTP/2 و serialization مبتنی بر Protobuf بهره می‌گیرد که سرعت و کارایی چشمگیری را به همراه دارد. مزایای کلیدی gRPC: - Streaming دو طرفه (Bi-directional)، ایده‌آل برای real-time و ارتباط‌های طولانی‌مدت. - قرارداد قوی مبتنی بر Interface (IDL)، که امکان تولید خودکار کدهای کلاینت/سرور را فراهم می‌کند و خطایابی را کاهش می‌دهد. - پرفورمنس فوق‌العاده، به ویژه برای تماس‌های زیاد و کوتاه بین سرویس‌ها. ✅ چه زمانی کدام را انتخاب کنیم؟ - اگر سرویس‌هایتان در یک اکوسیستم کنترل‌شده (.NET، Java، Go و ...) و با نیاز به پرفورمنس، استریمینگ یا تماس‌های فراوان هستند، gRPC انتخاب بهتری است. به خصوص برای ارتباط داخلی بین مایکروسرویس‌ها (Service-to-Service). - اگر به سازگاری با انواع کلاینت‌ها (فرانت‌اند وب، موبایل، یا third-party) فکر می‌کنید و نیاز به دیباگ ساده و مشاهده‌ی ترافیک توسط توسعه‌دهندگان دارید، REST همچنان بهترین انتخاب است. 👩‍💻 به سناریوی ترکیبی فکر کنید: بسیاری معماری‌ها امروزه gRPC را برای ارتباط داخلی سرویس‌ها و REST/HTTP API را برای اکسپوز کردن قابلیت‌ها به دنیای بیرونی استفاده می‌کنند. برای درک بهتر تفاوت Signature متد در gRPC و REST، نمونه‌ کد زیر را ببینید:

// gRPC Service Definition - Protobuf
service PaymentService {
  rpc ProcessPayment (PaymentRequest) returns (PaymentResponse);
}

// RESTful Controller in ASP.NET Core
[HttpPost("api/payment/process")]
public ActionResult<PaymentResponse> ProcessPayment([FromBody] PaymentRequest request) {
    // ...
}

🔍 عمیق‌تر بروید: - آیا latency یا حجم داده اهمیت دارد؟ gRPC. - آیا interoperability و لزوم باز بودن API مهم است؟ REST. - آیا به قابلیت‌های پیشرفته مثل deadlines، cancelation و streaming نیاز دارید؟ gRPC. انتخاب آگاهانه شما می‌تواند اکوسیستم شما را سال‌ها جلو بیاندازد. 👊 @DeveloperAdvocate 🥑

🎯 الگوی Producer/Consumer به سبک مدرن با System.Threading.Channels در .NET، کانال‌ها (Channels) راه‌حلی قدرتمند برای مدل‌سازی گردش داده بین Producer و Consumer به شکل thread-safe، async، و با بازدهی بالا ارائه می‌دهند. این تکنیک جایگزینی مدرن برای BlockingCollection و Queue قدیمی است و از اجرای متقارن و مبتنی بر async/await پشتیبانی می‌کند. در این مثال پیشرفته: - Producer داده‌ها را به صورت async می‌نویسد و کانال پس از اتمام کار بسته می‌شود. - چندین Consumer موازی (با Task.Run) داده‌ها را مصرف می‌کنند و عملیات I/O شبیه‌سازی‌شده دارند. - channel از نوع bounded است تا حافظه و فشار تولیدکننده کنترل شود.

using System.Threading.Channels;

var channel = Channel.CreateBounded<int>(
    new BoundedChannelOptions(capacity: 100)
    {
        FullMode = BoundedChannelFullMode.Wait
    });

async Task ProducerAsync(ChannelWriter<int> writer, int count)
{
    for (int i = 0; i < count; i++)
    {
        await writer.WriteAsync(i);
        // اعمال منطق تولید (مثلاً delay برای شبیه‌سازی عملیات)
    }
    writer.Complete();
}

async Task ConsumerAsync(ChannelReader<int> reader, int consumerId)
{
    await foreach (var item in reader.ReadAllAsync())
    {
        // عملیات مصرف (مثلاً delay برای شبیه‌سازی I/O)
        Console.WriteLine($"Consumer {consumerId}: {item}");
    }
}

const int ProducerCount = 1000;
const int ConsumerCount = 4;

var consumers = Enumerable.Range(0, ConsumerCount)
    .Select(id => ConsumerAsync(channel.Reader, id))
    .ToArray();

await ProducerAsync(channel.Writer, ProducerCount);
await Task.WhenAll(consumers);

⏱ نکات حرفه‌ای: - از Complete برای پایان تولید داده و سیگنال دادن به همه consumers استفاده کنید. - ReadAllAsync تا زمانی که کانال باز است و داده وجود دارد ادامه می‌دهد—نیازی به مدیریت lock یا signaling نیست. - با مدیریت ظرفیت (BoundedChannel)، می‌توانید backpressure را به صورت طبیعی و کارآمد پیاده‌سازی کنید. - مصرف و تولید async به طور کامل scale می‌شود و از thread starvation جلوگیری می‌کند. 🔹 Channels انتخاب فوق‌العاده‌ای برای معماری‌های event-driven، pipelineهای پردازش، و هر جایی است که نیاز به decoupling بین producer و consumer به صورت امن و مقیاس‌پذیر باشد. @DeveloperAdvocate 🥑

تبدیل یک اپلیکیشن React به یک PWA واقعی، صرفاً با نصب یک پکیج شروع نمی‌شود؛ نیازمند پوشش دقیق چند مؤلفه کلیدی است: 1️⃣ Service Worker هستهٔ قابلیت آفلاین بودن: یک اسکریپت جاوااسکریپت که درخواست‌ها را رهگیری و کش می‌کند. در React معمولا با registerServiceWorker یا integration با Workbox انجام می‌شود. 2️⃣ Web App Manifest یک فایل JSON (manifest.json) که متادیتا را شامل نام، آیکن، رنگ‌ها، و نمایش splash screen و روش اجرای app تعیین می‌کند. تعریف صحیح display, theme_color و آیکون‌های چند سایزی الزامی است. 3️⃣ HTTPS اجباری است؛ Service Worker فقط روی HTTPS عمل می‌کند (به جز حالت localhost). 4️⃣ Responsive Design UI باید adaptive باشد و روی هر device عالی کار کند—تابعیت از Mobile-first و breakpoints مناسب ضروری است. 5️⃣ Cachable Static Assets استراتژی‌های cache (مثلاً Precache یا Runtime Cache) باید دقیقاً تعریف شوند. مدیریت invalidate کردن کش‌ها برای به‌روزرسانی seamless مهم است. 6️⃣ App Shell Model زمان initial load، بخش shell (UI اصلی) باید سریع cache و render شود تا حس native را القا کند. 7️⃣ Push Notification (اختیاری، اما recommended) PWAها می‌توانند به‌صورت native push notification ارسال کنند—نیازمند Permission Handling و integration با Service Worker. در پروژه‌های جدی، پیکربندی webpack (یا Vite یا Create React App)، Workbox custom config و monitor کردن رویدادهای Service Worker (onUpdate, onSuccess) را دست‌کم نگیرید. بررسی کنید که Progressive Enhancement محقق می‌شود: بدون JS، اپ شما همچنان حداقل render شود. ➖ حین توسعه، ابزارهایی مثل Lighthouse و PWACompat می‌توانند کمک کنند تا رفتار native بهینه شود. ➖ برای پاک‌سازی cacheها و مدیریت versioning، کاملاً برنامه دقیق داشته باشید؛ race conditionهای عجیبی ممکن است رخ دهد. یک چک‌لیست معماری PWA برای React: - Service Worker config - manifest.json کافی و دقیق - استراتژی cache شفاف - HTTPS everywhere - Responsive layout تضمینی - قابلیت offline-first واقعی - App iconها و splash screenهای کامل - تست جامعی با Lighthouse (score بالای ۹۵، هدف ایده‌آل!) یک نمونه manifest ساده:

{
  "name": "My React PWA",
  "short_name": "ReactPWA",
  "start_url": ".",
  "display": "standalone",
  "theme_color": "#0d47a1",
  "background_color": "#fff",
  "icons": [
    {
      "src": "icons/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "icons/icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ]
}

با اجرای این چک‌لیست، React اپ شما به یک PWA کاملاً مدرن و مورداعتماد برای کاربران تبدیل می‌شود. @DeveloperAdvocate 🥑

🔹 مقایسه فنی: IHostedService در برابر BackgroundService برای تسک‌های طولانی در .NET اگر سرویس‌های بک‌گراندی با طول عمر بالا می‌سازید، احتمالاً با این دو مفهوم در ASP.NET Core یا هر اپلیکیشن .NET Generic Host روبه‌رو شده‌اید: ۱️⃣ IHostedService این اینترفیس پایه‌ای است و شامل دو متد کلیدی ست: - StartAsync(CancellationToken cancellationToken) - StopAsync(CancellationToken cancellationToken) ایده این است که زمان بالا آمدن هاست، متد StartAsync و زمان خاموشی، StopAsync فراخوانی شود. باید منطق تهدیدی (مثل ساخت Task و مدیریت lifecycle آن) را خودتان مدیریت کنید:

public class CustomWorker : IHostedService
{
    private Task? _backgroundTask;
    private CancellationTokenSource? _cts;

    public Task StartAsync(CancellationToken stoppingToken)
    {
        _cts = CancellationTokenSource.CreateLinkedTokenSource(stoppingToken);
        _backgroundTask = Task.Run(() => RunAsync(_cts.Token));
        return Task.CompletedTask;
    }

    private async Task RunAsync(CancellationToken token)
    {
        while (!token.IsCancellationRequested)
        {
            // کار طولانی شما اینجاست
            await Task.Delay(1000, token);
        }
    }

    public async Task StopAsync(CancellationToken cancellationToken)
    {
        if (_cts != null)
        {
            _cts.Cancel();
            if (_backgroundTask != null)
                await _backgroundTask;
        }
    }
}

۲️⃣ BackgroundService این کلاس انتزاعی روی IHostedService قرار گرفته و با پیاده‌سازی ساده‌تر Thread Lifecycle Management، بر روی یک Task دائماً اجراشونده تمرکز دارد. کافی است متد انتزاعی ExecuteAsync(CancellationToken stoppingToken) را Override کنید:

public class TimedWorker : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            // منطق پردازش پیوسته
            await Task.Delay(1000, stoppingToken);
        }
    }
}

✅ جمع‌بندی معماری: - اگر فقط قصد اجرای یک Loop یا پردازش دائمی را دارید، BackgroundService خواناتر، امن‌تر و مناسب‌تر است؛ نگرانی‌های cancellation و مدیریت خطا را کمتر می‌کند. - اگر بخواهید کنترل کامل lifecycle و اجرای چندین وظیفه موازی یا رویداد-محور داشته باشید (یا مثلاً توقف/شروع مجزا برای هر تسک)، IHostedService را به صورت دستی مدیریت کنید. - به صورت پیش‌فرض، BackgroundService انتخاب بهینه برای ۹۰٪ نیازهای سرویس‌های همیشه‌فعال اپلیکیشن‌های مدرن است. 🔍 آیا شما تجربه خاصی با این دو الگو داشته‌اید؟ تجربه یا کد جالب خودتان را کامنت کنید! @DeveloperAdvocate 🥑

🎯 #پرفورمنس #پایپ‌لاینز #netcore 🔹 IO با عملکرد بالا در .NET: آشنایی با System.IO.Pipelines در اپلیکیشن‌های شبکه‌ای مدرن (مثل Proxyها یا gRPC)، مدیریت بافرهای بزرگ و فرایند خواندن/نوشتن با کمترین latency حیاتی است. API‌ سنّتی Stream بر مبنای خواندن و نوشتن byte است که منجر به کپی‌های اضافه، GC Pressure و مدیریت ناکارآمد حافظه می‌شود. 🔸 راهکار: استفاده از System.IO.Pipelines Pipeline abstraction اجازه می‌دهد حافظه را مستقیم و chunk-based مدیریت کنید، بدون کپی اضافه. این مدل Split/Join را آسان می‌کند و Latency را به شدت کاهش می‌دهد. یک نمونه ساده برای خواندن از Socket با Minimal Allocation:

using System.IO.Pipelines;
using System.Net.Sockets;

async Task ProcessSocketAsync(Socket socket, CancellationToken token)
{
    var pipe = new Pipe();
    _ = FillPipeAsync(socket, pipe.Writer, token);
    await ReadPipeAsync(pipe.Reader, token);
}

async Task FillPipeAsync(Socket socket, PipeWriter writer, CancellationToken token)
{
    while (!token.IsCancellationRequested)
    {
        Memory<byte> memory = writer.GetMemory(4096);
        int bytes = await socket.ReceiveAsync(memory, SocketFlags.None, token);
        if (bytes == 0) break;
        writer.Advance(bytes);
        var result = await writer.FlushAsync(token);
        if (result.IsCompleted) break;
    }
    writer.Complete();
}

async Task ReadPipeAsync(PipeReader reader, CancellationToken token)
{
    while (true)
    {
        var result = await reader.ReadAsync(token);
        ReadOnlySequence<byte> buffer = result.Buffer;

        // پردازش Optimized روی buffer (مثلاً Parsing protocol)
        foreach (var segment in buffer)
        {
            // segment.Span را استفاده کنید (Zero-Copy!)
        }

        reader.AdvanceTo(buffer.End);
        if (result.IsCompleted) break;
    }
    reader.Complete();
}

🔍 نکته کلیدی: - با استفاده از Span/Memory روی PipeReader، هیچ کپی اضافه‌ای نداریم. - IO و Parsers را decouple می‌کنید. - Backpressure خودکار پیاده‌سازی می‌شود؛ یعنی مصرف‌کننده بافر را آزاد نکرده باشد، تولیدکننده کند می‌شود. 💡 System.IO.Pipelines ستون فقرات high-performance serverهای .NET (مثلاً Kestrel) است؛ اگر روی شبکه کار می‌کنید، این abstraction را عمیقاً بشناسید و از آن استفاده کنید! @DeveloperAdvocate 🥑

اسکالینگ افقی (Horizontal Scaling) و عمودی (Vertical Scaling) دو رویکرد کلیدی برای افزایش ظرفیت سیستم‌ها هستند. 🔸 Vertical Scaling (Scale-Up): در این مدل تنها با ارتقاء منابع سرور (CPU، RAM، Disk) ظرفیت را بالا می‌بریم. برای مثال، اگر یک VM در Azure دارید، کافی است از سایز D2 به D8 ارتقاء دهید. این کار بدون تغییر معماری نرم‌افزار امکان‌پذیر است ولی همیشه محدود به سقف سخت‌افزار باقی می‌مانید و Failover را سخت‌تر می‌کند. 🔸 Horizontal Scaling (Scale-Out): در این مدل به‌جای تقویت یک سرور، چندین نمونه مستقل اضافه می‌شوند. مثلا در AWS با افزایش Instance های EC2 در پشت یک Load Balancer یا در Azure App Service با Scale Out instanceها مواجه هستید. این رویکرد با معماری‌های مبتنی بر Cloud-Native (مانند Microservices) بسیار سازگار است. برای مثال، در Azure Kubernetes Service با افزایش Replica ها تعداد Podها را بالا می‌برید تا ترافیک بیشتری سرویس دهید. ❗ نکته کلیدی: بدون طراحی State مناسب (State Management/Stateless)، Scale-Out واقعی ممکن نیست. مثلا Session را در Redis ذخیره کنید یا State را در دیتابیس توزیع‌شده نگه دارید.

// افزایش ظرفیت با Scale-Out در App Service
var client = new WebSiteManagementClient(credentials);
await client.WebApps.UpdateAsync(resourceGroup, appName, new Site() {
    SiteConfig = new SiteConfig() {
        NumberOfWorkers = 5 // افزایش instanceها
    }
});

در معماریهای مدرن، همیشه به سمت افقی‌سازی فکر کنید؛ چرا که ظرفیت و افزونگی به شکل طبیعی و قابل مانیتورینگ افزایش پیدا می‌کند. @DeveloperAdvocate 🥑