👨‍💻 در پروژه‌های سی‌شارپی، برای دسترسی به تنظیمات (configuration) به‌صورت strongly-typed، می‌تونیم از سه نوع interface استفاده کنیم (معمولاً از طریق DI)، که هرکدوم کاربرد خاص خودشون رو دارن:


IOptions<T> 
🔹 تنظیمات فقط یک‌بار در زمان راه‌اندازی برنامه خونده و کش می‌شن. 
🔹 مناسب برای تنظیماتی که در زمان اجرا تغییر نمی‌کنن (مثل کلیدهای API یا مقادیر ثابت).


IOptionsSnapshot<T> 
🔹 تنظیمات رو به‌صورت scoped دریافت می‌کنه (مثلاً در هر درخواست HTTP جدید). 
🔹 مناسب برای پروژه‌های وب که نیاز دارن در هر درخواست، آخرین تغییرات تنظیمات رو دریافت کنن.


IOptionsMonitor<T> 
🔹 تنظیمات رو به‌صورت singleton اما real-time ارائه می‌ده. 
🔹 امکان ثبت event برای زمانی که تنظیمات تغییر می‌کنن (OnChange) رو فراهم می‌کنه. 
🔹 مناسب برای سرویس‌های background یا سناریوهایی که نیاز به واکنش به تغییرات تنظیمات در لحظه دارن.

اطلاعات بیشتر:
learn.microsoft.com/en-us/dotnet/core/extensions/options

👀 چطور توی apiـهامون از درخواست‌های تکراری جلوگیری کنیم؟

سناریوی محتمل:
- کاربر قصد داره خریدی انجام بده و اتصال اینترنت ضعیفی داره
- روی دکمه‌ی «پرداخت» کلیک می‌کنه
- درخواست به سرور میره، پردازش می‌شه و پول از حساب کسر می‌شه
- اما ریسپانس به دلیل قطعی لحظه‌ای اینترنت به کاربر نمی‌رسه
- کاربر فکر می‌کنه دکمه کار نکرده و دوباره (یا چندبار) روی دکمه‌ی پرداخت کلیک می‌کنه
نتیجه: سرور شما تمام درخواست‌ها رو می‌گیره و هردفعه اعتبار رو کم می‌کنه.

✅ راه حل: کلید Idempotency
به زبان ساده، Idempotency یعنی «مهم نیست یک درخواست چندبار به سمت سرور ارسال می‌شه، نتیجه‌ی نهایی باید همیشه یکسان باشه و تغییر اضافه در سیستم ایجاد نکنه»

برای پیاده‌سازی این مورد در متدهای POST یا PATCH، می‌تونیم از یک شناسه‌ی یکتا و Idempotency Key استفاده کنیم.

⚙️ پیاده‌سازی: این فرآیند نیاز به همکاری بین کلاینت و بک‌اند داره؛ به عنوان مثال هر زمان که کاربر فرم‌ای رو پر می‌کنه، کلاینت باید یک UUID یا شناسه‌ی یکتا تولید کنه و اون رو در هدر درخواست قرار بده.
X-Idempotency-Key: 123e4567-e89b-12d3-a456-426614174020

نکته‌ی مهم این هست که اگر درخواست به هردلیلی fail شد و کلاینت خواست retry انجام بده، باید همون کلید قبلی ارسال شه.

در سمت سرور هم، باید ‌یک middleware یا مکانیزمی طراحی شه که قبل از رسیدن درخواست به Controller، وجود اون کلید رو چک کنه و درصورت وجود، ریسپانس اون رو مستقیما از Redis برگردونه و کدهای اصلی بیزنس رو اجرا نکنه.
اگر هم وجود نداشت که خب اجازه می‌ده کد اجرا شه و سپس نتیجه‌ی اون رو توی Redis یا هر مکانیزم کش دیگه‌ای ذخیره می‌کنه.

توی یکی از پروژه‌های فرانت‌اندی اخیر، قصد داشتم مثل همیشه از 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

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