Developer Advocate
Відкрити в Telegram
1 035
Підписники
Немає даних24 години
Немає даних7 днів
-130 днів
Архів дописів
1 035
🎨 SVG Animations & Interactive SVGs: سطح جدیدی از طراحی در UI
در عصر طراحی مدرن، SVG نه تنها برای نمایش تصاویر و آیکونها، بلکه برای ساخت انیمیشنهای پویا و واکنشگرا در UI کاربردی بینظیر شده است. یکی از رویکردهای حرفهای، تلفیق SVG با کتابخانههای JavaScript یا تعامل مستقیم با DOM در تعاملات پیچیده است. اما با .NET، چطور میتوان انیمیشنهای SVG به شیوهای maintainable و performant ایجاد کرد؟
فرض کنید یک UI دارید که باید براساس رویداد کاربر (مثل کلیک یا hover) اجزای یک SVG را بهصورت داینامیک انیمیت کنید. بهترین گزینه ترکیب SVG و Blazor (WebAssembly) است:
1️⃣ ادغام SVG در Blazor:
کد SVG میتواند مستقیماً داخل Razor component قرار گیرد و با @bind یا event handlerهای Blazor، اجزای آن را واکنشگرا کرد.
2️⃣ کنترل انیمیشن از C#:
با استفاده از JS interop، میتوان از C#، انیمیشن SVG را در سطح elementهای منفرد مدیریت کرد. به مثال زیر توجه کنید:
@page "/svg-animate"
@inject IJSRuntime JS
<svg width="120" height="120">
<circle id="animatedCircle" cx="60" cy="60" r="50" stroke="teal" stroke-width="4" fill="none" />
</svg>
<button @onclick="AnimateCircle">انیمیت کن</button>
@code {
private async Task AnimateCircle()
{
await JS.InvokeVoidAsync("startSvgAnimation");
}
}
wwwroot/index.html یا فایل JS جدا):
function startSvgAnimation() {
const circle = document.getElementById('animatedCircle');
circle.style.transition = 'stroke-dashoffset 1.2s cubic-bezier(0.4,0,0.2,1)';
circle.style.strokeDasharray = 314;
circle.style.strokeDashoffset = 314;
setTimeout(() => {
circle.style.strokeDashoffset = 0;
}, 100);
}
window.startSvgAnimation = startSvgAnimation;
onclick یا onmouseover) را روی اجزای SVG بگذارید و بدون صفحهبندی مجدد UI به راحتی تعاملات پیچیده را هندل کنید.
مطالعه بیشتر با جزئیات تخصصی:
Animating SVG with Web Animations API (CSS-Tricks)
Advanced JavaScript/TypeScript
@DeveloperAdvocate 🥑1 035
چارچوب Diátaxis برای مستندسازی فنی: چگونه باید ساختار بدهیم؟
احتمالاً برای شما هم پیش آمده که تیم را با داکیومنتهایی روبرو کنید که اطلاعات را مخلوط یا بهشدت پراکنده ارائه میدهند—نتیجه؟ تیم گیج، ناکارآمد، و داکیومنتی که هیچوقت بهروزرسانی نمیشود. چارچوب Diátaxis برای حل دقیق همین مشکل ارائه شده: این چارچوب چهار گونه مستندات را تفکیک و برای هرکدام هدف و فرم جداگانهای تعریف میکند:
۱. Tutorial (آموزش گامبهگام): سناریوهای آموزشی با هدف یادگیری تدریجی، مخصوصاً برای مخاطب تازهکار با یک قابلیت خاص. مثال: نوشتن یک User Manager ساده به کمک ASP.NET Core Identity.
۲. How-To Guide (راهنمای انجام وظیفه): دستورالعملهای حل یک مسئله/وظیفه خاص، مختصر، اجراپذیر و بدون پرداختن به جزئیات غیرلازم. مثال: «چگونه JWT Token را در ASP.NET Core احراز هویت کنیم؟»
۳. Explanation (توضیح مفاهیم): ارائه مفاهیم پایه، پاسخ به چراییها، و انتقال دانش عمیق پیرامون سازوکارها. مثال: چرا Serilog در این معماری Event-based مؤثرتر از Log4Net است؟
۴. Reference (مستند مرجع): اطلاعات دقیق و جامع درباره API، واسطها، تنظیمات یا پیکربندیها. مثال: جدول کاملی از Middlewareهای ASP.NET Core همراه با پارامترها و رفتارها.
یک نمونه ساختار در مستندسازی فارسی پروژه (با مثال C#):
// How-To: استفاده از CancellationToken در سرویسهای Background
public class Worker : BackgroundService
{
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
while (!stoppingToken.IsCancellationRequested)
{
//...
await Task.Delay(1000, stoppingToken);
}
}
}
1 035
🔹 Micro-Frontends: استراتژیهای تقسیمبندی فرانتاند در معماریهای مدرن
تجزیه فرانتاند به ماژولهای مستقل (Micro-Frontends) راهکاری الهامگرفته از Microservices برای کاهش وابستگیها و افزایش مقیاسپذیری است. در معماریهای بزرگ، تیمها میتوانند هر قطعه از UI را با تکنولوژی دلخواه، مسیر استقرار جداگانه و حتی چرخه توسعه مستقل بسازند. اما سوال کلیدی: چگونه تقسیمبندی انجام دهیم تا هم عملکرد عالی بماند و هم انسجام تجربه کاربری حفظ شود؟
### 📦 ۱. Module Federation (Webpack 5)
Module Federation امکان بهاشتراکگذاری runtime ماژولها بین اپلیکیشنها را به صورت داینامیک میدهد. بدون نیاز به Rebuild کامل، هر میکروفرانت میتواند مستقل توسعه و دیپلوی شود و تنها در صورت نیاز بارگذاری گردد.
// فرض مثال: مصرف ماژول Micro-Frontend از اپلیکیشن remote در یک host
const RemoteButton = React.lazy(() => import("remoteApp/Button"));
// ترکیب ماژول لوکال با Remotes
export const Page = () => (
<div>
<LocalComponent />
<Suspense fallback="...">
<RemoteButton />
</Suspense>
</div>
);
// ساخت یک Web Component ساده
class HelloWorld extends HTMLElement {
connectedCallback() {
this.innerHTML = "<b>Hello Micro-Frontends!</b>";
}
}
window.customElements.define('hello-world', HelloWorld);
// استفاده در هر پروژهای:
<hello-world></hello-world>
1 035
🔥 OWASP Top 10 (2024): عمیقتر از همیشه — آسیبپذیریها و راهکارها برای .NET/React
در نسخه ۲۰۲۴، OWASP Top 10 نهتنها فهرست آسیبپذیریها را بهروز کرده، بلکه با وسواس بیشتری رفتارهای مخرب در معماری مدرن (SPA، API-first و میکروسرویسها) را هدف گرفته است. بیایید با تمرکز بر تهدیدهای رایج در اکوسیستمهای .NET و React، چند نکته طلایی را مرور کنیم:
1️⃣ A01:2024-Broken Access Control
بسیاری هنوز به اشتباه فقط به ویژگی
[Authorize] بسنده میکنند. اما دسترسی نباید فقط سطح Controller باشد! همیشه دسترسیها را در Service Layer هم enforce کنید:
// کنترل سطح دسترسی داخل Service Layer
public Task<Account> GetAccountAsync(Guid id, UserContext user)
{
var account = _repo.Get(id);
if (account.OwnerId != user.UserId && !user.HasRole("Admin"))
throw new UnauthorizedAccessException();
return account;
}
Cryptography.AesGcm هنوز از هش ساده یا الگوریتمهای ازمدافتاده استفاده کنید، با یک ریسک جدی روبهرو هستید. پس:
- همیشه دیتای حساس را با کلیدهای منحصربهفرد و الگوریتمهای مدرن رمز کنید.
- کلیدها را در Azure KeyVault نگهداری کنید نه appsettings.
3️⃣ A08:2024-Software and Data Integrity Failures
وابستگیهای ناایمن (npm install بدون audit) یا استفاده از بستههای NuGet غیر تاییدشده = افزایش حملات Supply Chain.
- حتماً اجرای CI/CD را با اجرای dotnet list package --vulnerable و npm audit --production مکمل کنید.
- در React، مراقب تزریقپذیری کد در کامپوننتهای شخص ثالث باشید.
4️⃣ A03:2024-Injection Attacks (SQLi/NoSQLi/XSS)
در ASP.NET Core همیشه از EF Core با پارامتر استفاده کنید و Dynamic SQL ننویسید.
در React هنگام dangerouslySetInnerHTML یا Third-party HTML rendering، sanitization را فراموش نکنید—پکیج لکهگیری شده مانند dompurify را استفاده کنید.
🔍 منبع پیشنهادی (برای درک عمیقتر و راهکارهای عملی):
Securing ASP.NET Core Applications (Microsoft Learn)
⏩ این چهار نقطه شروع، مسیر Architecture مدرن و امنتر را میسازند. آیا شما هم در کد روزانهتان این الگوها را رعایت میکنید؟
Application Security (AppSec)
@DeveloperAdvocate 🥑1 035
🔍 استراتژیهای آرشیو و پاکسازی دادههای حجیم در سیستمهای عملیاتی
با رشد نمایی دیتا در سیستمهای Enterprise، نگرانیهای جدی پیرامون کارایی دیتابیس، هزینه ذخیرهسازی و رعایت الزامات قانونی مثل GDPR به وجود میآید. راهکارهای موثر معماری برای مدیریت دادههای تاریخی شامل دو مؤلفه کلیدیاند: آرشیو (Archiving) و پاکسازی (Purging).
📦 آرشیو (Archiving):
انتقال دادههای قدیمی به یک محل ذخیرهسازی long-term (مثلاً Azure Blob، جدول آرشیو یا حتی Data Lake)، این دادهها باید ایندکس مجزای خود را داشته باشند. در پروژههای .NET غالباً رویکرد زیر توصیه میشود:
- تعریف موجودیتهای نسخه Archive در EF Core یا Dapper
- انتقال دادهها با TransactionScoped jobها (مثلاً سرویس Hangfire)
- رمزنگاری و کنترل دسترسی لایه Archive مطابق سیاستهای Security
🧹 پاکسازی (Purging):
حذف فیزیکی دادههای منقضیشده بر مبنای Retention Policy (مثلاً: دادههای تراکنش قدیمیتر از ۵ سال). اهمیت تست SQL Plan و Database Locks در این فرآیند بسیار بالاست تا حداقل اختلال ایجاد شود.
نمونه کد - انتقال دادهٔ تاریخی در ابعاد بالا:
using (var transaction = await dbContext.Database.BeginTransactionAsync())
{
var oldOrders = await dbContext.Orders
.Where(o => o.CreatedAt < archiveThreshold)
.Take(batchSize)
.ToListAsync();
var archivedOrders = oldOrders.Select(MapToArchiveEntity).ToList();
dbContext.ArchivedOrders.AddRange(archivedOrders);
dbContext.Orders.RemoveRange(oldOrders);
await dbContext.SaveChangesAsync();
await transaction.CommitAsync();
}
1 035
🔹 استراتژیهای Multi-Region Deployment در داتنت: تابآوری و کارایی بدون مرز
پیادهسازی اپلیکیشنهای داتنت بهصورت Multi-Region، شاهکلیدی برای دستیابی به High Availability، Disaster Recovery کارآمد و Latency پایین برای کاربران جهانی است. اما این معماری جذاب، چالشهای فنی عمیقی به همراه دارد:
۱️⃣ جداسازی لایهها و Stateless بودن سرویسها: سرویسهای Stateless بهترین گزینه برای چند منطقهای کردن هستند. وابستگیهای State باید حداقل و ترجیحاً در دیتابیس توزیعشده یا Persisted External Cache قرار بگیرد.
۲️⃣ Replication دیتا: انتخاب رویکرد مناسب (Active-Active vs. Active-Passive) برای دیتا بسیار حیاتی است. مثلا Azure Cosmos DB با قابلیت Multi-Region Write و Replication خود، کمک بزرگیست؛ اما نیازمند سیاستهای Conflict Resolution.
۳️⃣ Routing هوشمند: تعیین Region بر اساس GeoIP، Latency یا Health Check سرویسها باید در لایه Load Balancer یا DNS (مثلاً Azure Traffic Manager یا AWS Route 53) پیاده شود.
// نمونه چک Health از Regionهای مختلف
public async Task<bool> IsHealthyRegionAsync(string regionEndpoint)
{
using (var httpClient = new HttpClient())
{
httpClient.Timeout = TimeSpan.FromSeconds(2);
var response = await httpClient.GetAsync($"{regionEndpoint}/health");
return response.IsSuccessStatusCode;
}
}
1 035
برای دستیابی به حداکثر کارایی در ASP.NET Core، سه محور کلیدی را باید جدی بگیریم: پیکربندی Kestrel، کش پاسخ، و فشردهسازی پاسخها. هرکدام از اینها قابلیت تبدیل یک اپلیکیشن متوسط به یک سرویس بسیار سریع و مقیاسپذیر را دارند.
🔶 تنظیم Kestrel برای پرفورمنس عالی
Kestrel بهصورت پیشفرض سریع است، اما با کانفیگ دقیقتر، نرخ درخواست/پاسخ را چند برابر افزایش میدهیم. مثلاً حداکثر تعداد کانکشن و تصحیح تنظیمات buffer:
// Program.cs
webBuilder.ConfigureKestrel(serverOptions =>
{
serverOptions.Limits.MaxConcurrentConnections = 10000; // بسته به ظرفیت سرور
serverOptions.Limits.MaxRequestBodySize = 10 * 1024 * 1024; // 10 MB
serverOptions.Limits.MaxRequestBufferSize = 1 * 1024 * 1024; // 1 MB
serverOptions.Limits.MaxResponseBufferSize = 1 * 1024 * 1024; // 1 MB
// و دیگر گزینهها بسته به نیاز شما
});
ResponseCaching را فعال و هدرهای استاندارد را درست ارسال کنید:
// Startup.cs یا Program.cs - برای Service Registration
services.AddResponseCaching();
// Middleware برای فعالسازی
app.UseResponseCaching();
// در اکشن کنترلر:
[ResponseCache(Duration = 60, Location = ResponseCacheLocation.Any, NoStore = false)]
public IActionResult Get()
{
// ...
}
// Startup.cs یا Program.cs
services.AddResponseCompression(options =>
{
options.EnableForHttps = true;
options.Providers.Add<BrotliCompressionProvider>();
options.Providers.Add<GzipCompressionProvider>();
options.MimeTypes = ResponseCompressionDefaults.MimeTypes.Concat(
new[] { "image/svg+xml" });
});
// تنظیم سطح فشردهسازی Brotli (بهترین نسبت):
services.Configure<BrotliCompressionProviderOptions>(options =>
{
options.Level = System.IO.Compression.CompressionLevel.Optimal;
});
1 035
در معماریهای مدرن، پیادهسازی Circuit Breaker تنها آغاز راه است؛ چالش واقعی زمانی آغاز میشود که بخواهیم این الگو را بهصورت داینامیک، با مانیتورینگ real-time و بدون نیاز به دیپلوی مجدد، مدیریت کنیم. بیایید نگاهی عمیقتر به Circuit Breaker در داتنت – با تمرکز بر Polly – بیندازیم:
✅ پیکربندی داینامیک Circuit Breaker با IOptionsSnapshot
در این مثال، تنظیمات Circuit Breaker از appsettings.json لود میشود و در زمان اجرا بدون دیپلوی مجدد قابل تغییر است:
// appsettings.json
{
"CircuitBreaker": {
"ExceptionsAllowedBeforeBreaking": 5,
"DurationOfBreakSeconds": 30
}
}
public class CircuitBreakerSettings
{
public int ExceptionsAllowedBeforeBreaking { get; set; }
public int DurationOfBreakSeconds { get; set; }
}
services.Configure<CircuitBreakerSettings>(Configuration.GetSection("CircuitBreaker"));
var cbSettings = provider.GetRequiredService<IOptionsSnapshot<CircuitBreakerSettings>>();
// هنگام نیاز به Policy جدید (مثلاً per request)
var settings = cbSettings.Value;
var policy = Policy
.Handle<Exception>()
.CircuitBreakerAsync(
handledEventsAllowedBeforeBreaking: settings.ExceptionsAllowedBeforeBreaking,
durationOfBreak: TimeSpan.FromSeconds(settings.DurationOfBreakSeconds));
var policy = Policy
.Handle<Exception>()
.CircuitBreakerAsync(
5,
TimeSpan.FromSeconds(30),
onBreak: (ex, duration, context) => {
_logger.LogWarning("Circuit Broken! Reason: {Message}, Duration: {Duration}", ex.Message, duration);
// کاستوم متریک یا ارسال به سرویس مانیتورینگ
},
onReset: context => {
_logger.LogInformation("Circuit Reset.");
},
onHalfOpen: () => {
_logger.LogInformation("Circuit is Half-Open. Testing...");
});
1 035
در پروژههایی با دیتاست عظیم، مدیریت دادههای تاریخی و حجم رو به رشد جداول عملیاتی تبدیل به چالشی جدی میشود. راهبرد «آرشیوسازی و پاکسازی (Archiving & Purging)» میتواند هم عملکرد دیتابیس را بهبود بخشد، هم به انطباق با الزامات رگولاتوری کمک کند.
راهبردهای کلیدی:
- نشانهگذاری دادههای آرشیوی: برای هر رکورد، ستونی مثل
ArchivedAt یا IsArchived تعریف کنید. این امکان میدهد دادهها به راحتی قابل انتقال یا حذف باشند.
- جداسازی فیزیکی: دادههای تاریخی را به Table مجزا یا حتی Database مجزا منتقل کنید. مثلاً اطلاعات مربوط به تراکنشهای بیش از ۵ سال قبل به جدول دیگری آرشیو شوند.
- استفاده از Partitioning: SQL Server Partition Tables ابزاری قدرتمند برای مدیریت دادههای بزرگ است. پارتیشنبندی بر اساس زمان ایجاد رکورد یا سایر شاخصها، Query عملکردیتر و پاکسازی سریعتر ارائه میدهد:
-- مثال تعریف پارتیشن بر اساس فیلد CreatedDate
CREATE PARTITION FUNCTION TransDateRange (datetime)
AS RANGE LEFT FOR VALUES ('2021-01-01', '2022-01-01', '2023-01-01');
// حذف تدریجی دادههای قدیمیتر از 5 سال
while (true)
{
var oldRecords = db.Transactions
.Where(tx => tx.CreatedAt < thresholdDate)
.Take(10000)
.ToList();
if(oldRecords.Count == 0) break;
db.Transactions.RemoveRange(oldRecords);
db.SaveChanges();
}
1 035
🚨 حمله Dependency Confusion: زنجیره تامین خود را مصون کنید!
یکی از تهدیدهای نوظهور برای پروژههایی که از فیدهای خصوصی NuGet استفاده میکنند، حمله Dependency Confusion است. در این حمله، مهاجم نسخهای مخرب و عمومی با همان نام یکی از پکیجهای داخلی شما (مثلاً
MyCompany.Logging) را روی ریجستریهای عمومی مانند nuget.org منتشر میکند. اگر ترتیب فیدها یا پیکربندی پروژه نادرست باشد، در هنگام restore ممکن است نسخه مخرب بجای نسخه امن داخلی دریافت شود.
🔑 نکات کلیدی برای مقابله:
- ترتیب فیدها را در NuGet.config طوری تنظیم کنید که فید خصوصی قبل از فید عمومی باشد.
- بهجای Allow، از Source Mapping جدید در NuGet 5.9+ بهره بگیرید تا هر namespace فقط از یک سورس خاص دریافت شود.
- نامگذاری پکیجهای داخلی را منحصر به فردتر انجام دهید (مثلاً با prefix سازمان).
- پکیجهای داخلی را روی ریجستری عمومی ثبت نکنید، حتی بهصورت private.
- ذهنیت "trust but verify"؛ هرگز به نسخههای جدید بدون بررسی Exact Version اجازه ورود ندهید.
نمونهای از Source Mapping:
<packageSourceMapping>
<packageSource key="PrivateFeed">
<pattern>MyCompany.*</pattern>
</packageSource>
<packageSource key="nuget.org">
<pattern>Newtonsoft.*</pattern>
<pattern>NUnit</pattern>
</packageSource>
</packageSourceMapping>
// اطمینان از دریافت نسخه مورد انتظار پکیج
<PackageReference Include="MyCompany.Logging" Version="1.2.3" PrivateAssets="all" />
1 035
👨💻 استراتژیهای پیشرفته مدیریت خطا در سرویسها و کلاینتها
در اپلیکیشنهای enterprise، طراحی robust برای مدیریت خطا حیاتی است. ترکیب Global Error Handlers، Middleware و Retry Policyها نهتنها مانع بروز خطاهای ناشناخته میشود، بلکه تجربه کاربری را هم بهبود میبخشد.
🔸 Global Error Handler در ASP.NET Core
با تعریف یک middleware مرکزی، میتوانید هر گونه exception کنترلنشده را لاگ و پاسخ مناسب تولید کنید:
app.UseExceptionHandler(errorApp =>
{
errorApp.Run(async context =>
{
context.Response.StatusCode = 500;
context.Response.ContentType = "application/json";
var exceptionHandlerPathFeature =
context.Features.Get<IExceptionHandlerPathFeature>();
var result = JsonSerializer.Serialize(new {
error = "Unexpected error",
detail = exceptionHandlerPathFeature?.Error.Message,
});
await context.Response.WriteAsync(result);
});
});
public class CustomErrorHandlingMiddleware
{
private readonly RequestDelegate _next;
public CustomErrorHandlingMiddleware(RequestDelegate next) => _next = next;
public async Task Invoke(HttpContext context)
{
try
{
await _next(context);
}
catch (ValidationException ex)
{
context.Response.StatusCode = 400;
await context.Response.WriteAsync("Validation Failed");
}
catch (NotFoundException)
{
context.Response.StatusCode = 404;
await context.Response.WriteAsync("Resource Not Found");
}
catch (Exception)
{
context.Response.StatusCode = 500;
await context.Response.WriteAsync("Internal Error");
}
}
}
var retryPolicy = Policy
.Handle<HttpRequestException>()
.OrResult<HttpResponseMessage>(r => (int)r.StatusCode >= 500)
.WaitAndRetryAsync(3, retryAttempt =>
TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)));
var response = await retryPolicy.ExecuteAsync(() =>
httpClient.GetAsync("https://api.example.com/data"));
1 035
مدیریت ارتباط با مدیران و رهبران تیم، مهارتی حیاتی اما کمتر بحثشده برای معماران نرمافزار است. «مدیریت بالا» فقط گزارش وضعیت پروژهها نیست؛ بلکه هنر رساندن بینشهای عمیق فنی، شفاف ساختن ریسکها، و هدایت تصمیمات راهبردی است. به جای صرفاً ارائه دادهها، داستان بسازید: مسئله، راهحلهای محتمل، هزینهها و اثرات. برای تاثیرگذاری بیشتر، شواهد ملموس ارائه دهید—مثلاً KPI فنی، دیاگرام معماری، یا حتی پروتوتایپهای ساده.
در مواجهه با مباحث تاثیرگذار (مانند Technical Debt یا مدیریت ریسک)، قالب پیشنهادی زیر میتواند کمک کند:
public record ArchitecturalDecision(
string Summary,
string[] Alternatives,
string Recommendation,
string[] Risks,
string[] ImpactedTeams
);
var decision = new ArchitecturalDecision(
Summary: "انتقال بخشی از بیزنس لاجیک از Monolith به Service جدید",
Alternatives: new[] { "حفظ ساختار فعلی", "بازنویسی کامل ماژول", "Service کردن قطعه پرریسک" },
Recommendation: "اجرای Service فقط برای قطعه پرریسک در گام نخست",
Risks: new[] { "افزایش Latency ارتباط داخلی", "پیچیدگی دیپلویمنت" },
ImpactedTeams: new[] { "DevOps", "Front-End", "QA" }
);
1 035
در معماری مدرن، ادغام اپلیکیشنهای ASP.NET Core با message brokerها مثل Kafka و RabbitMQ نهتنها قابلیت مقیاسپذیری سیستم را افزایش میدهد، بلکه مبنایی برای ساخت سرویسهای ایونتمحور فراهم میکند. چند نکتهی کلیدی برای این نوع ادغام:
🔸 Dependency Injection و Scoped Consumers
در ASP.NET Core، باید کانسومرها را به صورت scoped ثبت کنید؛ زیرا اغلب وابسته به DbContext یا سرویسهای مشابه هستند، اما connection به broker باید singleton باشد. مثلاً در RabbitMQ:
services.AddSingleton<IConnectionFactory>(sp => new ConnectionFactory {
Uri = new Uri("amqp://guest:guest@localhost")
});
services.AddScoped<IMessageHandler, MyMessageHandler>();
public class RabbitMqListener : BackgroundService
{
private readonly IModel _channel;
private readonly IServiceProvider _provider;
public RabbitMqListener(IModel channel, IServiceProvider provider)
{
_channel = channel;
_provider = provider;
}
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
var consumer = new EventingBasicConsumer(_channel);
consumer.Received += async (sender, ea) =>
{
using var scope = _provider.CreateScope();
var handler = scope.ServiceProvider.GetRequiredService<IMessageHandler>();
await handler.Handle(Encoding.UTF8.GetString(ea.Body.ToArray()));
};
_channel.BasicConsume(queue: "sampleQueue", autoAck: true, consumer: consumer);
await Task.CompletedTask;
}
}
1 035
🟢 Compensating Transactions: راهکاری حرفهای برای بازگرداندن هماهنگی دادهها در سیستمهای توزیعشده
زمانی که عملیات distributed در سیستمهای microservices یا معماریهای دادهمحور اجرا میشود، عدم وجود transaction مرکزی (مانند ACID در دیتابیسها) میتواند به ناسازگاری دادهها منجر شود. اینجاست که الگوی Compensating Transaction بهعنوان مکانیزمی برای rollback هوشمند وارد بازی میشود.
این الگو با تعریف عمل معکوس (و نه الزاماً بازگشت کامل) برای هر عملیات بحرانی، امکان بازگردانی سیستم به وضعیت قابل قبولی حتی پس از شکست عملیاتها را فراهم میسازد. مثلاً اگر رزرو بلیت هواپیما انجام شده اما پرداخت ناموفق باشد، باید یک عملیات "لغو رزرو" را به عنوان تراکنش جبرانی اجرا کنیم.
در .NET معمولاً این الگو را با استفاده از event-driven patterns (مثل saga یا outbox) پیادهسازی میکنیم. نمونه سادهای از یک تراکنش جبرانی در C# برای لغو سفارش:
public class OrderService
{
private readonly IPaymentService _paymentService;
private readonly IInventoryService _inventoryService;
public async Task PlaceOrderAsync(Order order)
{
try
{
await _inventoryService.ReserveAsync(order.Items);
await _paymentService.ChargeAsync(order.PaymentInfo);
}
catch (Exception)
{
await CompensateAsync(order);
throw;
}
}
private async Task CompensateAsync(Order order)
{
await _inventoryService.ReleaseAsync(order.Items);
// سایر اقدامات جبرانی مانند ارسال پیام لغو
}
}
1 035
شکلدهی Adapter Pattern برای انتگراسیون سرویسهای خارجی در معماری میکروسرویس، میتواند پایداری و توسعهپذیری اکوسیستم شما را بهشکل معناداری بهبود دهد. استفاده از آداپترها باعث میشود هم وابستگی به تغییرات سرویسهای خارجی را به حداقل برسانید و هم کد سرویس شما تمیز، تستپذیر و ایزوله باقی بماند.
فرض کنید باید با یک سرویس پرداخت خارجی (مثلاً Stripe) تعامل کنید. بهجای Scatter کردن کدهای HTTP و Map کردن مدلهای خارجی در سراسر سرویسها، این تعامل را توسط یک Adapter انتزاع و ایزوله کنید. برای مثال:
public interface IPaymentService
{
Task<PaymentResult> ChargeAsync(PaymentRequest request, CancellationToken ct = default);
}
public class StripePaymentAdapter : IPaymentService
{
private readonly StripeClient _stripeClient;
public StripePaymentAdapter(StripeClient stripeClient)
{
_stripeClient = stripeClient;
}
public async Task<PaymentResult> ChargeAsync(PaymentRequest request, CancellationToken ct = default)
{
var stripeResult = await _stripeClient.ChargeAsync(MapToStripeRequest(request), ct);
return MapFromStripeResult(stripeResult);
}
// Mapping helpers here...
}
1 035
در پروژههای React/Next.js، بینالمللیسازی (i18n) فقط ترجمه رشتهها نیست؛ معماری صحیح جهت مدیریت زبانها و مسیریابی بخش بسیار مهمی از ماجراست و اشتباه در این حوزه معمولا به scalability پایین یا UX ضعیف منجر میشود.
الگوی پیشنهادی: ابتدا زبان فعال را بخشی از URL کنید (مثلاً
/fa/، /en/). توصیه میشود این کار را با استفاده از قابلیت built-in i18n routing در Next.js انجام دهید تا تمام صفحات و API Routeها این schema را رعایت کنند. به مثال زیر توجه کنید:
// next.config.js
module.exports = {
i18n: {
locales: ['en', 'fa'],
defaultLocale: 'en',
localeDetection: true,
},
}
import { useTranslation } from 'next-i18next';
function Welcome() {
const { t } = useTranslation('common'); // Namespace 'common'
return <h1>{t('welcome_message')}</h1>;
}
// pages/_app.js
import { appWithTranslation } from 'next-i18next';
function MyApp({ Component, pageProps }) {
return <Component {...pageProps} />;
}
export default appWithTranslation(MyApp);
// middleware.js (Next.js 12+ Middleware)
import { NextRequest, NextResponse } from 'next/server';
export function middleware(req) {
const preferredLang = req.headers.get('accept-language')?.split(',')[0] || 'en';
// Redirect logic...
}
1 035
مدیریت امن اسرار در CI/CD با Azure Key Vault و HashiCorp Vault
در دنیای DevOps مدرن، لو رفتن secrets مثل connection string، API key و گواهیها حتی بهاندازهی یک اجرای pipeline میتواند خسارت جدی وارد کند. دو راهکار حرفهای برای محافظت و تزریق پویا این دادهها در pipelineها، استفاده از Azure Key Vault و HashiCorp Vault است. بیایید نقطههای کلیدی و چند الگوی پیشنهادی را بررسی کنیم:
۱️⃣ عدم ذخیرهی secrets در repos یا pipeline variables
هرگز secrets را مستقیماً در YAML یا GUI pipelineها و حتی متغیرهای محیطی global نگه ندارید. رمزها باید همواره خارج از scope source code و pipelineها و در vaultها قرار بگیرند.
۲️⃣ ادغام با Azure Key Vault در Azure DevOps Pipeline
Azure Key Vault به طور builtin در Azure Pipelines پشتیبانی میشود. کافیست با Service Principal احراز هویت کنید و secrets را فقط در جایی که واقعا لازم است Retrieve کنید. مثال step تعریف متغیر از Key Vault:
- task: AzureKeyVault@2
inputs:
connectedServiceName: 'My-Connection'
keyVaultName: 'MyVault'
secretsFilter: 'SqlConnectionString,AppSecret'
- script: |
echo $(SqlConnectionString)
- name: Read secrets from Vault
uses: hashicorp/vault-action@v2.4.0
with:
method: oidc
url: ${{ secrets.VAULT_ADDR }}
secrets: |
secret/data/prod/sql password | DB_PASSWORD;
secret/data/prod/api key | API_KEY;
// Microsoft.Extensions.Configuration.AzureKeyVault
var config = new ConfigurationBuilder()
.AddAzureKeyVault(new Uri("https://<your-key-vault-name>.vault.azure.net/"),
new DefaultAzureCredential())
.Build();
string secret = config["SqlConnectionString"];
1 035
معماری پاک (Clean Architecture) مفهومی فراتر از یک الگوی چندلایه است؛ تمرکز اصلی آن جداسازی منطق کسبوکار از وابستگیهای زیرساخت، سادهسازی تست و پایداری معماری در برابر تغییرات فناوری است. قلب این معماری اصل Dependency Rule است: وابستگیها باید فقط از بیرون به سمت هسته حرکت کنند، نه برعکس.
### لایهها و وابستگیها:
1. Domain (Entities): مدل سطح بالا و قوانین اصلی کسبوکار.
2. Application: موارد استفاده (Use Cases) که رفتار اپلیکیشن را تعریف میکنند؛ هنوز وابستگی به دیتابیس یا UI ندارند.
3. Infrastructure: پیادهسازیهای دیتابیس، سرویسهای جانبی و APIها.
4. Presentation: وب، API یا UI.
### نمونهای از برقراری وابستگی معکوس (Dependency Inversion):
در Domain اینترفیسها تعریف میشوند و در Infrastructure پیادهسازی میشوند. Application فقط با اینترفیس کار میکند.
// Domain Layer
public interface ICustomerRepository
{
Customer GetById(Guid id);
void Save(Customer customer);
}
// Application Layer
public class RegisterCustomerUseCase
{
private readonly ICustomerRepository _repository;
public RegisterCustomerUseCase(ICustomerRepository repository)
{
_repository = repository;
}
public void Execute(string name)
{
var customer = new Customer { Id = Guid.NewGuid(), Name = name };
_repository.Save(customer);
}
}
// Infrastructure Layer
public class SqlCustomerRepository : ICustomerRepository
{
// فرض بر این SQL DbContext قبلاً تعریف شده است
public Customer GetById(Guid id) { /* ... */ }
public void Save(Customer customer) { /* ... */ }
}
1 035
مقایسه CSS-in-JS با Utility-First CSS (مانند Tailwind CSS) این روزها برای اکثر تیمهای Frontend (چه React و چه .NET Blazor) به یک دغدغه روزانه بدل شده است. انتخاب صحیح، مستقیماً بر مقیاسپذیری، سرعت توسعه و نگهداری کد شما تأثیر میگذارد.
🔷 CSS-in-JS (به ویژه در محیطهایی مثل React یا Blazor) امکان تعریف استایلها به صورت داینامیک و Scoped در کنار منطق کامپوننت را فراهم میکند. این مزیت بزرگ در پروژههای صفحهمحور و دارای وضعیت بالای UI بسیار حیاتی است. مثالی از تعریف استایل داینامیک در Blazor:
@code {
private bool isActive = true;
private string ButtonStyle =>
isActive ? "background: #3182ce; color: white;" : "background: #e2e8f0; color: #2d3748;";
}
<button style="@ButtonStyle">Stateful Button</button>
flex, mt-3, ...) در همان HTML markup، استایل دقیق را مشخص میکند.
مزایا:
- سریعترین تجربه توسعه برای تیمهای بزرگ (به ویژه در پروژههای با تکرار بصری بالا)
- سازگاری عالی با سیستم Design System و Design Tokens
- کاهش تولید CSS اضافی (از طریق Purge)
معایب:
- Bloat کد HTML (افزایش تعداد کلاسها در markup)
- جداسازی کمتر منطق و ظاهر (افزایش coupling در صورت استایلهای داینامیک پیچیده)
- یادگیری اولیه زیادتر نسبت به CSS سنتی
🔎 جمعبندی معماری:
در پروژههای مقیاسپذیر و داینامیک با تعاملات پیچیده (مثل SPAهای پیشرفته یا فرمهای دولتی در Blazor)، رویکرد CSS-in-JS یا scoped CSS بیشتر توصیه میشود. اما در پروژههایی با طراحی ثابت و بزرگ (مانند Portalها)، Utility-First به دلیل افزایش سرعت و حفظ یکپارچگی UI، معمولاً بهینهتر است.
مطالعهی فنی عمیقتر:
https://martinfowler.com/articles/css-in-js.html
Advanced JavaScript/TypeScript
@DeveloperAdvocate 🥑1 035
✨ Service Workerها: معماری آفلاین-فرست و همگامسازی پسزمینه برای وباپلیکیشنها
اگر تجربه ساخت PWA یا اپلیکیشنهای مدرن را دارید، اهمیت Service Workerها را میدانید: فراهمکردن تجربهی کاربری بدون قطعی حتی در شرایط اتصال ضعیف.
🔹 ذخیرهسازی هوشمند درخواستها در صورت قطع ارتباط:
Service Worker میتواند درخواستهای بحرانی (مانند POSTها) را در IndexedDB ذخیره کند تا پس از بازگشت اینترنت آنها را به سرور ارسال کند (Background Sync). یک الگوی رایج در سطح production:
1. وقتی کاربر دادهای را ذخیره میکند و connection قطع است، آن را در IndexedDB قرار دهید.
2. Service Worker رویداد
sync را listen میکند و با برقراری اینترنت، درخواستهای معوق را از IndexedDB میخواند و submit میکند.
یک پیادهسازی ساده در Service Worker:
self.addEventListener('sync', event => {
if (event.tag === 'sync-outbox') {
event.waitUntil(sendOutboxToServer());
}
});
async function sendOutboxToServer() {
const outbox = await loadOutboxFromIndexedDB();
for (const item of outbox) {
await fetch('/api/tasks', {
method: 'POST',
body: JSON.stringify(item),
headers: {'Content-Type': 'application/json'}
});
await removeFromOutbox(item.id);
}
}
