بلاگ

بعد از timeout، فراخواننده نمی‌داند عملیات موفق بوده یا نه. Idempotency اجازه می‌دهد همان عملیات را دوباره درخواست کند، بدون اینکه اثر موردنظر در کسب‌وکار دوباره اعمال شود؛ حتی اگر تأیید موفقیت به او نرسیده باشد.

یک worker ساده در C#، کلید ثابت، ذخیره‌ی نتیجه و رسیدگی به درخواست‌های تکراری را نشان می‌دهد؛ با محدودیت‌های روشن در هم‌زمانی، راه‌اندازی مجدد، نگهداری سوابق و اثرهای خارج از برنامه.

مسیر متدی را دنبال می‌کنیم که به پاسخ HTTP نیاز دارد: درخواست را شروع می‌کند، متن پاسخ را می‌گیرد و آن را به نتیجه تبدیل می‌کند. تسک درخواست HTTP و تسک خود متد، هرکدام بخش متفاوتی از این کار را نشان می‌دهند.

می‌بینیم await هنگام انتظار چه می‌کند، خطا و لغو چگونه به فراخواننده می‌رسند و متد پس از آماده شدن پاسخ کجا ادامه پیدا می‌کند.

مخزن خواندن جدا کمک می‌کند داده را برای یک صفحه یا گزارش و نه برای نیازهای مدل نوشتن شکل دهیم. این کار می‌تواند join‌های پرهزینه را کم کند و ظرفیت خواندن را مستقل افزایش دهد.

در عوض، یک مسئله‌ی همگام‌سازی به وجود می‌آید. ممکن است داده‌ی خواندنی قدیمی باشد و نمایش باید بتواند به‌طور امن بازیابی شود و برنامه باید روشن کند کاربر پس از ارسال یک command چه چیزی می‌بیند.

CQRS لازم نیست از همان روز اول با دو پایگاه‌داده و چند سرویس شروع شود. می‌توان مسیر command و مسیر query را در همان برنامه و پایگاه‌داده جدا کرد، چون کارشان واقعاً یکی نیست.

مسیر command از تغییر محافظت می‌کند و مسیر query پاسخ مناسب فراخواننده را می‌سازد. این انتخاب تراکنش و خواندن فوری را نگه می‌دارد، اما مقیاس‌پذیری مستقل خواندن را به دست نمی‌دهد.

یک DTO تغییرکرده فقط می‌گوید وضعیت چه شده است، نه اینکه کاربر دقیقاً چه کاری خواسته. وقتی تغییر به مجوز، دلیل یا قانون‌های دیگر گره می‌خورد، این تفاوت مهم می‌شود.

command با نام روشن، مثل `DeactivateInventoryItem`، هدف کاربر را مستقیم به برنامه می‌رساند. بعد اعتبارسنجی، مجوزدهی و قواعد همان عمل در یک نقطه می‌مانند.

برای تغییر نام نمایشی یا یک تنظیم ساده، CRUD کاملاً کافی است. مسئله از جایی شروع می‌شود که تغییر چند فیلد، یک تصمیم کسب‌وکار با مجوز، دلیل و پیامدهای خودش را پنهان می‌کند.

این نوشته نشان می‌دهد چرا گاهی باید به‌جای فرستادن یک DTO تغییرکرده، خود عمل را نام ببریم. CQS و CQRS برای همین نقطه‌اند، نه برای پیچیده کردن هر update معمولی.

async، concurrency و parallelism شبیه هم به نظر می‌رسند، اما به سه مسئله‌ی متفاوت جواب می‌دهند. اولی درباره‌ی انتظار است، دومی درباره‌ی پیش بردن چند کار، و سومی درباره‌ی تقسیم محاسبه میان هسته‌ها.

وقتی این تفاوت را روشن کنیم، انتخاب ساده‌تر می‌شود. برای انتظار I/O سراغ async می‌رویم؛ برای محاسبه‌ی سنگین CPU فقط وقتی parallelism لازم است که واقعاً اندازه‌گیری گلوگاه را نشان دهد.

بخش زیادی از کار برنامه، منتظر ماندن برای شبکه، پایگاه‌داده یا فایل است؛ کارهایی که زمان تمام شدنشان دست برنامه نیست. async نمی‌گذارد این انتظار، رابط کاربری یا رسیدگی به درخواست‌های دیگر را متوقف کند.

تأخیر شبکه یا پایگاه‌داده با async ناپدید نمی‌شود. تفاوت در این است که برنامه هنگام انتظار بی‌کار نمی‌ماند و می‌تواند سراغ کاری برود که همین حالا آماده‌ی انجام است.

برنچ‌های محلی بعد از merge شدن Pull Request‌ها، حذف remote یا پایان یک آزمایش کوتاه روی سیستم می‌مانند. این نوشته سه راه پاک‌سازی را برای این وضعیت‌ها کنار هم می‌گذارد.

هر دستور سطح خطر خودش را دارد. پیش از حذف اجباری، باید بدانید برنچ چه وضعی دارد و آیا تغییرهایش جای دیگری وارد شده‌اند یا نه.

برای این بلاگ به CMS یا پایگاه‌داده نیاز نداشتم. محتوا در Markdown می‌ماند و Node.js و TypeScript آن را با قالب‌های قابل ویرایش به HTML استاتیک تبدیل می‌کنند.

این ساختار برای سایتی مناسب است که یک نفر محتوا را ویرایش می‌کند. جفت‌شدن فارسی و انگلیسی، مسیرها، RSS و نمودارها هم در فرایند ساخت ایجاد می‌شوند، نه با یک سرور همیشه‌روشن.