توی یکی از پروژه‌های فرانت‌اندی اخیر، قصد داشتم مثل همیشه از swagger codegen استفاده کنم تا از مزایاش برای ارتباط راحت‌تر با api بهره‌مند شم (در ادامه میگم)‌، ولی خب از اون‌جایی فایل executableش یک فایل jar بود و نیاز به نصب جاوا داشت و منطقی نبود 😁 تصمیم گرفتم دنبال پکیج جایگزینی بگردم، که با Orval آشنا شدم.
حالا این چی‌کار می‌کنه و چرا باید ازش استفاده کرد؟

سناریوی دردناک و رایج:
تیم بک‌اند تغییری در خروجی API میده (مثلاً userName تبدیل می‌شه به fullName).

فرانت‌‌اند کار از این تغییر بی‌خبره یا فراموش می‌کنه اینترفیس‌های TypeScript رو آپدیت کنه.

پروژه بیلد می‌شه، اما توی مرورگر کاربر به خطای undefined می‌خوره و کرش می‌کنه!

جدا از این، نوشتن دستی Typeها و Interfaceها برای هر API وقت‌گیر و خسته‌کننده‌ست.

✅ راه حل: ابزار Orval به شما کمک می‌کنه به‌جای اینکه دستی کدهای ارتباط با API یا Schemaـها رو بنویسید، میاد و فایل Swagger/OpenAPI بک‌اند رو می‌خونه و تمام کدهای مورد نیاز فرانت‌‌اند (مثل هوک‌های React Query، کلاینت Axios و تایپ‌های TypeScript) رو به‌صورت خودکار و ساختاریافته تولید می‌کنه.

⚙️ چطوری کار می‌کنه؟ کافیه آدرس فایل swagger.json خروجی گرفته شده از ASP.NET (یا هر تکنولوژی دیگه‌ای) رو به Orval بدید.

نتیجه:

- تولید خودکار هوک‌ها: مثلاً به‌جای نوشتن دستی useQuery، خودش ()useGetUsers رو با تایپ دقیق ورودی و خروجی بهت میده.

- امن بودن تغییرات (Type Safety): اگر بک‌اند اسم فیلدی رو عوض کنه، کد فرانت‌‌اند دیگه بیلد نمی‌شه (Compile Error) و همون لحظه متوجه می‌شی، نه هنگام استفاده!

- هماهنگی ۱۰۰٪: فرانت‌‌اند همیشه با آخرین تغییرات داکیومنت بک‌‌اند سینک می‌مونه.

اطلاعات بیشتر:
github.com/orval-labs/orval

اینترنت برای امروز کافیه 😭

https://github.com/mmarinovic/tailwindsql

من که یادم رفت تبریک بگم 🍉 ولی این‌جا بمونه به یادگار.

دست از سر using (new HttpClient) بردارید 😁
توی دنیای دات‌نت، همیشه به ما یاد دادن که هر کلاسی که IDisposable رو پیاده‌سازی کرده، باید توی بلاک using استفاده بشه تا منابع‌ش بعد از انجام کار بلافاصله آزاد شه.
اما درمورد HttpClient یه استثنای بزرگ هست که خیلی از افراد هنوز درگیرش می‌شن.

سناریوی مشکل‌ساز:
شما کدی می‌نویسید که قراره یه API خارجی رو کال کنه. طبق عادت، اینطوری می‌نویسید:

using (var client = new HttpClient())
{
    var response = await client.GetAsync("https://api.example.com");
}

روی سیستم خودتون همه چیز عالی هست. پروژه می‌ره روی پروداکشن و زیر بار ترافیک قرار می‌گیره؛ اما ناگهان لاگ‌ها پر می‌شه از خطای SocketException و سرور عملاً از دسترس خارج می‌شه.

حالا چرا این اتفاق می‌افته؟
وقتی شما اینستنس کلاینت رو Dispose می‌کنید، آبجکت توی کد از بین میره، اما سیستم عامل پورت شبکه (Socket) متصل به اون رو تا چند دقیقه (به‌خاطر وضعیت TIME_WAIT در پروتکل TCP) باز نگه می‌داره.
اگر ترافیک بالا باشه، تمام پورت‌های سرور اشغال می‌شن و سیستم عامل دیگه پورتی نداره که به درخواست‌های جدید اختصاص بده (Socket Exhaustion).

✅ یکی از راه حل‌ها: استفاده از IHttpClientFactory
مایکروسافت از نسخه‌ی ۲.۱ دات‌نت core به بعد، یک راهکار استاندارد و تمیز براش ارائه کرد. به جای ساختن نمونه‌های جدید، باید مدیریت طول عمر HttpClient رو به فکتوری خودش بسپرید.

⚙️ پیاده‌سازی:
۱. اول توی فایل Program.cs سرویس‌اش رو رجیستر کنید:
builder.Services.AddHttpClient();
۲. حالا توی سرویس یا کنترلر خودتون، IHttpClientFactory رو اینجکت کنید:

public class MyService
{
    private readonly IHttpClientFactory _clientFactory;

    public MyService(IHttpClientFactory clientFactory)
    {
        _clientFactory = clientFactory;
    }

    public async Task GetData()
    {
        var client = _clientFactory.CreateClient();
        var response = await client.GetAsync("...");
    }
}

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

- پرفورمنس بالاتر: سربار ساختن مداوم کلاینت حذف می‌شه.

- مدیریت DNS: مشکل معروفِ "کش شدن DNS در HttpClientهای استاتیک" رو هم هندل می‌کنه.

ℹ️ البته که وقتی از IHttpClientFactory استفاده می‌کنید، فقط به ساختن کلاینت‌های عمومی محدود نیستید و می‌تونید کلاینت‌هایی بسازید که تنظیمات خاص خودشون رو داشته باشند یا حتی لاجیک درخواست رو در خودشون نگه دارن، که خب در این پست نمی‌گنجه. می‌تونید اینجا و اینجا درموردشون مطالعه کنید.

Use IHttpClientFactory to implement resilient HTTP requests