مواضيع متقدمة (Bonus)

#Event sourcing: الأحداث هي مصدر الحقيقةBonusEvent sourcing: events as the source of truth

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

لو لازم تعرف مش بس رصيد الطلب الحالي، لكن كمان كل انتقال حصل وإمتى وليه، event sourcing بيخزّن سلسلة events بدل استبدال الحالة الحالية. بنعيد بناء state من الأحداث، ونعمل projections للقراءة. ده مختلف عن audit log جنب جدول هو لسه مصدر الحقيقة.

ده C# sketch للـ replay فقط، مش event store جاهز؛ الـ append الحقيقي محتاج stream version وexpected-version check ذري.

public abstract record OrderEvent;
public sealed record OrderPlaced(decimal Total) : OrderEvent;
public sealed record OrderCancelled : OrderEvent;

public sealed class OrderState
{
    public decimal Total { get; private set; }
    public bool Cancelled { get; private set; }

    public void Apply(OrderEvent e) // (1)
    {
        switch (e)
        {
            case OrderPlaced placed: Total = placed.Total; break;
            case OrderCancelled: Cancelled = true; break;
        }
    }
}

var state = new OrderState();
foreach (var e in history) state.Apply(e); // (2): history is ordered OrderEvent data

هتدفع تكلفة schema evolution وupcasters، وprojection lag وإعادة البناء، وحذف بيانات شخصية من تاريخ طويل. ماتستخدموش لمجرد CRUD عادي أو علشان «الأحداث حديثة». event sourcing مش شرط لـ CQRS، والعكس صحيح.

#GraphQL في .NET مقابل RESTBonusGraphQL in .NET versus REST

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

لو تطبيق الموبايل والويب محتاجين أشكال مختلفة من نفس الداتا، GraphQL بيسمح للعميل يختار fields من schema typed. Hot Chocolate implementation للـ server في .NET. REST يفضل مناسب لعقود بسيطة وHTTP caching وأوامر business واضحة؛ الاختيار مش مسابقة مين أحدث.

# GraphQL operation against an illustrative store schema
query {
  order(id: "123") {
    id
    lines { quantity product { name } }
  }
}

كل resolver ممكن يعمل query، فيظهر N+1. DataLoader يجمع قراءات بالمفاتيح داخل نطاق الطلب، وprojection يحد الأعمدة. حط pagination وحدود للـ depth والـ cost، وطبّق authorization على الموارد والـ fields. أقل HTTP requests مش معناه أقل DB work. ماتشاركش DataLoader cache بين tenants. الـ schema دي مثال عقد، مش ملف C# مكتمل.

#Blazor render modes لمهندس backendBonusBlazor render modes for backend developers

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

Blazor Web App يقدر يختار مكان تنفيذ تفاعل components. ده قرار تشغيل وأمان وlatency، مش مجرد اختيار شكل الصفحة.

Auto مش نقل component شغالة من السيرفر للمتصفح في نص الجلسة. interactive modes بتدعم prerendering افتراضيًا؛ data loading ممكن يحصل في مرحلتين، فخطط للـ state ومنع side effects المكررة. الأسرار والـ authorization مكانهم السيرفر مهما كان الـ mode.

@* In a .razor component after enabling the mode in the Blazor host. *@
@using static Microsoft.AspNetCore.Components.Web.RenderMode
@rendermode InteractiveServer
<button @onclick="Increment">Items: @count</button>
@code {
    private int count;
    private void Increment() => count++;
}

#Actor model وMicrosoft OrleansBonusThe actor model and Microsoft Orleans

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

لو عندك state وسلوك لكل كيان، زي حجز أو عربة، الـ actor بيخلّي كل كيان يستقبل رسائل بدل threads تعدّل نفس الـ memory. Orleans بيقدّم virtual actors اسمها grains: هوية مستقرة وactivation يديرها runtime، وتوزيع على silos.

Client -> Grain reference (BookingId) -> active grain on a silo
                                         |
                                  explicit persistent state
Silo failure -> later activation elsewhere -> reload persisted state

الـ default scheduling بيسلسل requests للـ grain العادية؛ reentrancy وإعدادات التداخل بتغيّر الـ reasoning وبتحتاج فهم. ده مش transaction تلقائية بين كذا grain، ومش حفظ تلقائي لكل field. صمّم persistence وidempotency وtimeouts. كيان واحد عليه load عالي ممكن يبقى hot grain؛ Orleans مش بيحل مشكلة key واحد بإضافة servers بس. CRUD بسيط غالبًا أسهل من غير cluster إضافية.

#Dapr building blocksBonus

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

لما services بلغات مختلفة محتاجة invocation وpub/sub وstate، Dapr بيعرض APIs موحّدة قدام components بتوصل لمزوّدين مختلفين. في deployment شائع التطبيق بيكلم sidecar عبر HTTP أوgRPC. الـ broker والـ state store لسه موجودين وبتدير إعداداتهم.

الـ abstraction مش ضمان إن كل store يدعم نفس transactions أو consistency. اختبر component metadata والـ retries والـ DLQ والصلاحيات. تكلفة sidecar والتشغيل والتشخيص ممكن مايبقاش لها عائد في API واحدة بسيطة. Aspire للتنسيق المحلي وservice defaults؛ مش بديل تلقائي لـ Dapr runtime.

#Feature flags: فصل deploy عن releaseBonusFeature flags: separating deployment from release

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

لو عايز تنشر الكود وتفتحه تدريجيًا، feature flag يحدد مين يشوف السلوك الجديد. Microsoft.FeatureManagement بيوفّر evaluation وfilters وvariants. الـ flag مش authorization؛ لسه افحص صلاحية المستخدم.

المثال service fragment بعد تسجيل services.AddFeatureManagement()، و features نوعه IVariantFeatureManager، ودوال rendering هي دوال التطبيق.

using Microsoft.FeatureManagement;

bool useNewCheckout = await features.IsEnabledAsync("NewCheckout"); // (1)
return useNewCheckout
    ? RenderNewCheckout()
    : RenderCurrentCheckout();                                     // (2)

لكل flag owner وسبب وموعد إزالة. راقب cohort وتأثيره، وخطط لسلوك آمن لو config مش متاحة. كثرة flags تزود عدد التركيبات اللي محتاجة اختبار.

#WebAssembly وWASI باختصارBonusWebAssembly and WASI briefly

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

WebAssembly صيغة تنفيذ portable بيشغّلها runtime، في المتصفح أو خارجه. مفيد لبعض plugins أو كود مشترك أو workloads محتاجة sandbox. WASI مجموعة interfaces للوصول لقدرات النظام من WebAssembly حسب host وإصدار الـ interface، مش نظام تشغيل كامل.

Compiled module -> Wasm runtime -> explicitly granted host capabilities
Browser host: browser APIs and interop rules
WASI host: supported WASI interfaces and configured capabilities
Check .NET toolchain, runtime, interface version and package compatibility.

Sandbox مش تصريح بإهمال التحديثات وحدود CPU والـ memory. ماتحطش secret في client bundle، وماتفترضش إن أي NuGet package أو أي ASP.NET Core app هتشتغل WASI من غير تعديل. تفاصيل دعم .NET وWASI بتتغير؛ افحص tooling المستهدف بدل وعد «شغّال في كل مكان».

#gRPC streaming وعمر الاتصالBonusgRPC streaming and connection lifetime

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

لو العميل محتاج progress متتابع أو stream من الأحداث، gRPC يدعم unary، وserver streaming، وclient streaming، وbidirectional streaming. العقد في proto والـ C# بيتولد منه. المثال server streaming محدود، مش durable event subscription.

syntax = "proto3";
option csharp_namespace = "Store.Contracts";
service Progress { rpc Watch (WatchRequest) returns (stream ProgressReply); }
message WatchRequest { string order_id = 1; }
message ProgressReply { int32 percent = 1; }

// In a Grpc.AspNetCore project with C# generated from the proto above.
using Grpc.Core;
using Store.Contracts;

public sealed class ProgressService : Progress.ProgressBase
{
    public override async Task Watch(WatchRequest request,
        IServerStreamWriter<ProgressReply> stream, ServerCallContext context)
    {
        for (int n = 0; n <= 100; n += 25)
        {
            context.CancellationToken.ThrowIfCancellationRequested(); // (1)
            await stream.WriteAsync(new ProgressReply { Percent = n }); // (2)
            await Task.Delay(100, context.CancellationToken);
        }
    }
}

راجع proxy timeouts وHTTP/2 support. المتصفح محتاج gRPC-Web أو بديل؛ gRPC-Web مش بيوفر client streaming وbidirectional streaming زي native gRPC. reconnect محتاج resume cursor وdedup لو فقد الأحداث غير مقبول؛ فتح اتصال تاني لوحده مش replay.

#YARP كـ reverse proxyBonusYARP as a reverse proxy

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

لو محتاج route جزء من الطلبات لخدمة جديدة والباقي لنظام قديم، YARP مكتبة reverse proxy داخل ASP.NET Core. route بتطابق الطلب، وcluster بتحدد destinations وسياسة توزيع. مفيد في migration تدريجي أو gateway مخصص، لكن تشغيله مسؤوليتك.

المثال لـ package Yarp.ReverseProxy مع section اسمها ReverseProxy فيها routes وclusters متحقّق منها؛ المقطع لوحده مش بيعرّف destination.

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddReverseProxy()
    .LoadFromConfig(builder.Configuration.GetSection("ReverseProxy")); // (1)
var app = builder.Build();
app.MapReverseProxy();                                               // (2)
app.Run();

راجع forwarded headers من proxies موثوقة فقط، والـ TLS والـ health checks والـ timeouts والـ request size، وtrace propagation. Reverse proxy مش service mesh أو WAF كامل تلقائيًا. لو managed gateway بيغطي المطلوب، custom proxy ممكن يزوّد عبء من غير فائدة.

#Hangfire وQuartz وTemporalBonusHangfire, Quartz and Temporal

اختياري بس بيفرق: مش هيتسأل فيه في كل انترفيو، بس معرفته بتعمّق فهمك وبتميّزك عن غيرك.

Task.Run داخل request مش job system: process ممكن يقف والـ scope يتقفل. اختار الأداة حسب هل محتاج job محفوظ، ولا scheduling غني، ولا workflow طويل بيستعيد تقدمه.

في Temporal حط I/O والـ side effects في activities. workflow بيرجع يتنفذ من history، فمتستخدمش clock أو randomness أو HTTP عشوائي فيه؛ استخدم SDK primitives. activities ممكن تعاد، فلازم idempotency. في كل الأدوات: راقب عمر أقدم job، والفشل والـ retries، واستخدم outbox لو لازم ربط enqueue بـ business transaction.