🔵 عنوان مقاله
PegoMock 4.3: A Powerful Yet Simple Mocking Framework

🟢 خلاصه مقاله:
**PegoMock 4.3 یک فریمورک mocking ساده اما قدرتمند است که با یک DSL خوانا نوشتن، خواندن و نگه‌داری تست‌ها را آسان می‌کند. هسته اصلی آن، زبانی است که به‌جای کدهای طولانی، نیت تست را شفاف بیان می‌کند. این ابزار از stubbing و argument matching پشتیبانی می‌کند؛ یعنی می‌توانید رفتار وابستگی‌های شبیه‌سازی‌شده را تعریف کنید و بر اساس الگوهای ورودی، انتظارها را دقیق و انعطاف‌پذیر تنظیم کنید. نتیجه، تست‌هایی شفاف، کم‌بوایلرپلیت و قابل اتکا برای تیم‌هاست.

#Testing #Mocking #DSL #UnitTesting #Stubbing #ArgumentMatching #TestAutomation

🟣لینک مقاله:
https://golangweekly.com/link/175072/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

کامپیوترها برای نگهداری و نمایش کاراکترهای یک متن از یه فضای یک بایتی (معادل هشت بیت 0 یا 1) استفاده میکردن
این میزان فضا توی کامپیوتر میتونه شامل 255 حالت مختلف بشه
کامپیوترها برای نشانه‌های گرامری، حروف انگلیسی و عدد از استاندارد اسکی (ASCII) استفاده میکردن
این استاندارد آمریکایی میاد برای هر کاراکتر یه معادل عددی تعریف میکنه
مثلا کاراکتر A در اسکی معادل عدد 65هست
قرار گرفتن این اعداد پشت سر هم در کامپیوتر یک متن رو میسازه

مشابه این استاندارد معادل عددی برای پشتیبانی از تمام زبان‌های دنیا به وجود اومد که یونیکد (Unicode) نام داره
کاراکترهای انگلیسی و اعداد انگلیسی توی یونیکد از همون اعداد استاندارد اسکی استفاده میکنن و در ادامه پشتیبانی از کاراکترهای بقیه زبان‌های دنیا بهش اضافه میشه

یونیکد در حال حاضر دارای چیزی حدود 297,000 معادل عددی برای کاراکترهای مختلف از زبان‌های مختلف، اموجی‌ها و ... هست
فضای یک بایتی برای پشتیبانی از این میزان حالت‌های مختلف کافی نیس
شما برای این جا دادن این میزان از حالت‌های مختلف به شکل بیت کامیپوتر به حداقل سه بایت نیاز دارین
سه بایت میتونه تا حدود 16 میلیون عدد مختلف رو برای شما نگه داری کنه

حالا شما برای نگهداری یک متن که شامل کاراکترهای
یونیکد هست نیاز دارین 3 بایت برای هر کاراکتر اختصاص بدین
کاراکترهای انگلیسی تو یونیکد تنها یک بایت هم براشون کافیه ولی اگه شما برای یه متن انگلیسی، هر کاراکتر رو سه بایت در نظر بگیرین عملا به ازای هر کاراکتر انگلیسی دو بایت فضا رو هدر دادین
مثلا تو یه متن با ده هزار کاراکتر،
یه چیزی حدود 20 کیلوبایت فضای کامپیوتر رو هدر دادین
چه وقتی میخاین ازش استفاده کنین و توی رم هست و چه وقتی که روی هارد دیسک برای استفاده در آینده ذخیره شده

اینجاست که UTF-8 میتونه کمک کنه

این استاندارد که توسط یونیکد تعریف شده به جای اینکه بیاد فضای 3 بایتی به هر کاراکتر
اختصاص بده، میاد از 7 بیت راست یک بایت برای کاراکترهای اسکی استفاده میکنه

و برای کاراکترهای بعدی علاوه بر خود کاراکتر، تعداد بایت مصرف شده برای اون کاراکتر هم داخل بایت اول ذخیره میکنه
یعنی 128 کاراکتر اول اسکی به شکل عادی ذخیره میشن بدون تغییر خاصی با فقط یک بایت فضا

ولی برای کاراکترهای بعدی میاد و داخل بایت اول مشخص میکنه چه میزان فضا برای کاراکتر استفاده شده

این میزان فضا از یک بایت تا چهاربایت میتونه متغیر باشه

حالا چه شکلی اینکارو میکنه
تو یه بایت برای 128 عدد اولیه اسکی، بیت چپ همیشه صفر هست

اما وقتی بیت چپ یک میشه یعنی با یه کاراکتر UTF8 طرف هستیم

همونطور که گفتم هر کاراکتر توی UTF-8 میتونه از یک بایت تا چهاربایت متغیر باشه

کامپیوتر چطور اینو تشخیص میده؟

بیت‌های 1 اولِ بایت رو میشماره تا به عدد 0 صفر برسه
یعنی اگه بایت اول با عدد باینری 110 شروع بشه، یعنی دوبایت فضا استفاده شده
اگه 1110 باشه سه بایت و ...

تو UTF-8 فضای بیت‌های بایت اول بین خود کاراکتر و تعداد بایت تقسیم میشه و متغیره

اما تو بایت‌های دوم و سوم و چهارم همیشه شش تا بیت راست برای خود کاراکتر استفاده میشه و دو بیت دیگه برای هندل کردن ارور تو utf-8 استفاده میشه
امیدوارم تونسته باشم با دانش ناقص خودم شما رو در مورد این انکدینگ رایج دنیای کامپیوتر آشنا کرده باشم

توضیحات دقیق‌تر:
https://en.wikipedia.org/wiki/UTF-8

سایت استفاده شده برای تست بایت UTF-8:
https://utf8-playground.netlify.app/


| <Amir/>

🔵 عنوان مقاله
Failsafe: Fault Tolerance, Resilience Patterns & Policies

🟢 خلاصه مقاله:
Failsafe یک کتابخانه برای ساخت اپلیکیشن‌های fault-tolerant است که به شما امکان می‌دهد کدهای حساس را با مجموعه‌ای از سیاست‌های تاب‌آور مانند Retry، CircuitBreaker، RateLimiter، Timeout و Fallback بپوشانید. این سیاست‌ها قابل ترکیب‌اند و بدون تغییر منطق کسب‌وکار، حفاظت‌های چندلایه ایجاد می‌کنند.

در نسخه‌های اخیر، دو قابلیت کلیدی اضافه شده است: نخست، usage tracking برای اعمال عدالت و جلوگیری از اثر “noisy neighbor” از طریق پایش مصرف و اجرای محدودیت‌ها یا سهمیه‌ها. دوم، execution budgets برای تعیین سقف کلی هزینه اعمال تاب‌آوری—مثل مجموع retries یا hedges—در سطح یک فراخوانی، جریان کاری یا کل سیستم. این بودجه‌ها مانع از افراط در بازیابی می‌شوند و تعادلی بین نرخ موفقیت، تأخیر، هزینه و SLOها برقرار می‌کنند.

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

#FaultTolerance #Resilience #Failsafe #Retry #CircuitBreaker #RateLimiter #Timeout #Fallback

🟣لینک مقاله:
https://golangweekly.com/link/175069/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

پاول دورُف: حاضرَم بمیرم، ولی آزادی و امنیت کاربران رو نفروشم!

در گفت‌وگوی عمیق با «لِکس فریدمن»، بنیان‌گذار تلگرام از فلسفهٔ زندگی، حریم خصوصی، بیت‌کوین و مقاومتش در برابر فشار دولت‌ها گفت.
> 🗣

«من ترجیح می‌دم بمیرم و تمام داراییم رو از دست بدهم تا اینکه اطلاعات کاربران رو به هر دولتی تحویل بدم.
آزادی و امنیت داده‌ها، خط قرمز من و تلگرامه.»

🔒

او تأکید کرد تلگرام هیچ‌وقت “در پشتی” برای دولت‌ها باز نکرده و در برابر فشار روسیه و ایران برای دسترسی به اطلاعات یا سانسور مقاومت کرده است.
>

«در روسیه و ایران بارها تلاش شد ما رو مجبور به همکاری کنن. ولی ما مقاومت کردیم چون اگر یک‌بار کوتاه بیای، دیگه آزادی واقعی وجود نداره.»

📱 ۷ اصل فکری و مدیریتی پاول دورُف (بر اساس مصاحبه):

1️⃣ آزادی و اخلاق بالاتر از هر سود مالی — او می‌گوید حاضر است تمام دارایی‌اش را از دست بدهد تا آزادی بیان و امنیت کاربران حفظ شود.

2️⃣ مینیمالیسم و انضباط شخصی — سبک زندگی‌اش ساده، بدون الکل، قهوه یا حواس‌پرتی است؛ تمرکز کامل روی مأموریت و نظم ذهنی.

3️⃣ تیم کوچک، تأثیر بزرگ — معتقد است تیم‌های بزرگ بهره‌وری را می‌کُشند؛ موفقیت تلگرام حاصل اعتماد به چند نابغهٔ منضبط است.

4️⃣ مقاومت در برابر سانسور و در پشتی — هیچ دولت یا شرکتی حق کنترل یا شنود تلگرام را ندارد. رمزنگاری و طراحی MTProto را «دیوار آزادی دیجیتال» می‌نامد.

5️⃣ پول و قدرت ابزارند، نه هدف — او از مدل‌های انحصاری و کمیسیون‌های اپل و گوگل انتقاد می‌کند و تأکید دارد که ثروت نباید آزادی را محدود کند.

6️⃣ باور به فناوری آزاد مثل بیت‌کوین — بیت‌کوین را «نمادِ کاهش نیاز به اعتماد به واسطه‌ها و آزادی مالی» می‌داند؛ از پروژه TON به‌عنوان زیربنای اقتصاد آزاد تلگرام یاد می‌کند.

7️⃣ نگاه فلسفی به زندگی و مرگ — از کافکا، شوپنهاور و «جاودانگی کوانتومی» می‌گوید؛ باور دارد انسان باید بدون ترس از مرگ، بر پایهٔ ارزش‌های خودش زندگی کند.

📄 دستور cat در لینوکس
✅ کلمه‌ی cat مخفف concatenate هست، یعنی به هم چسباندن.

✨کار اصلی این دستور نمایش محتوا و یا اتصال چند فایل متنی به هم است.
اپشن‌های متداول:

cat a.txt  نمایش
cat a.txt b.txt  چند فایل با هم
cat > c.txt ایجاد فایل
cat >> file.txt اضافه کردن
cat a.txt b.txt > c.txt ترکیب
cat -n file.txt شماره گذاری
cat -v file.txt نمایش غیرقابل چاپ

⚙️ آپشن‌های پرکاربرد
-n → شماره‌گذاری همه خطو
-b → شماره‌گذاری فقط خطوط غیرخالی
-s → حذف خطوط خالی تکراری
-E → نمایش $ در انتهای هر خط
-T → نمایش تب‌ها به شکل ^I
-A → ترکیب همه (نمایش همه کاراکترهای خاص)

🔥 پیشنهاد مهرداد لینوکسی😎
میتوانید از bat به جای cat استفاده کنید و در شل cat را alias کنید
رنگی است و خروجی مرتب تری داره

alias cat="batcat"

ابزار tac (راهنمایی سایت گنو اینجا) عکس این دستور است
#دیوار_لینوکس
@MehrdadLinuxchannel
#Linux #لینوکس
#linux_command

در این دوره، می‌کوشیم سری به سرآغازهای داستان بزنیم، و با نگاهی به بعضی آثار ماندگار تاریخ ادبیات داستانی، به پیدایش رمان در جهان جدید برسیم. هرچند تلاش می‌کنیم در طی دوره، از آراء و نظرات متفکران و نویسندگان مهم و مؤثر بهره ببریم، اما مسیر حرکت‌مان را محدود به نظریه‌ی ادبی نخواهیم کرد، و می‌کوشیم از لابه‌لای خطوط خود قصه‌ها، به رازورمز و تحول‌شان بپردازیم. درانتها، با نگاهی به تحولات تاریخی و اجتماعی، خواهیم دید چگونه سروکلّه‌ی رمان پیدا می‌شود، و نظریه‌ی رمان مقصد نهایی ما خواهد بود.

در صورت تمایل برای شرکت در این دوره، به شناسه‌ی زیر پیام دهید 👇🏻
@Neemalavi


@hezaartoomag

یه استفاده که من اخیرا از git hook کردم ابن بود که مطمین بشم کامیت مسیج های یه سری پروژه خاص، یه فرمت خاصی رو رعایت میکنن. برای این کار از هوک commit-msg استفاده کردم. این هوک هم میاد قبل از این که واقعا کامیت صورت بگیره اجرا میشه و کامیت مسیج رو دریافت می‌کنه. در نهایت با کمک exit code میتونید مشخص کنید که کامیت مورد تایید هست یا باید ریجکت بشه.

کدی که من نوشتم:

#!/bin/bash
commit_regex='some regex'
error_msg="Aborting commit."
if ! grep -E "$commit_regex" "$1"; then    echo "$error_msg" >&2
  exit 1
fi
این فایل باید به این اسم سیو بشه: commit-msg توی پوشه hooks اون ریپوزیتوری.


اما حالا برای این که این اسکریپت رو همه جا تکرار نکنم چیکار کردم؟ اومدم از core hooks استفاده کردم. به این شکل میتونم بگم پوشه هوک دیفالت برای همه پروره‌ها یکی باشه و نیاز نیست برم داخل هر پروژه تک تک چک کنم.

کامندی که استفاده کردم اینه:
git config core.hooksPath

و نهایتا کانفیگ گیت اینطوری میشه:
[core]
hooksPath = /path/to/hooks/dir


اما اینجا هنوز یه تیکه گمشده دیگه هست. با این تغییراتی که من دادم این فرمت برای همه‌ی پروژه ها روی سیستمم اعمال شد ولی من اینو نمی‌خوام، بلکه می‌خوام فقط توی پروژه خاصی خاصی اعمال بشه. کاری که میکنم استفاده از conditional config توی گیته. قضیه اینطوریه که یه فایل کانفیگ ثانویه می‌سازم که این کانفیگ توش نوشته شده و توی کانفیگ اصلی میگم includeif: یعنی فقط وقتی این کانفیگ رو اعمال کن که پوشه گیت من داخل یکی از این پوشه ها بود یا داخل مسیری بود که این پترن رو داشت.

منابع:
https://git-scm.com/docs/githooks
و
https://dev.to/chaz8080/git-smart-streamlining-your-workflow-with-the-prepare-commit-msg-hook-432p
و
https://medium.com/@mrjink/using-includeif-to-manage-your-git-identities-bcc99447b04b


و اگه خواستید دقیقش رو توی dotfile م ببینید:

https://github.com/rsharifnasab/dotfiles/blob/2b3ba235c300e8a5dbec53a7a84dde350ca372af/configs/.config/git/config#L51
و
https://github.com/rsharifnasab/dotfiles/blob/37f0812046ef9eceb7c3e18ff0e9fb6b30843828/configs/.config/git/snapp#L9

تایپ‌های شایسته و ناشایسته
https://the-dr-lazy.github.io/incompetent-types

Maktabkhoone GIT tutorial progress
███████████░░░░░░░░░ [55%]

Maktabkhoone GIT tutorial progress
███████████░░░░░░░░░ [55%]

قانون بروکس می‌گه : اضافه کردن نیروی انسانی به یک پروژه نرم‌افزاری عقب‌افتاده، باعث می‌شود بیشتر عقب بیفتد.

@Linuxor

پیش به سوی بدبختی

شرکت Bitnami که ابزار و کانتینر برای وب مثلا وردپرس، PHP و Node.js دیتابیسای معروف مثل Postgress و Mysql می‌سازه کف‌گیرش به ته دیگ خورده و محصولات و کانتینر هاشو داره پولی می‌کنه.

البته با تگ latest می‌تونید نسخه توسعه رو pull کنید ولی برای پروداکشن مناسب نیست.


@Linuxor

به تازگی یه پروژه ای رو دیدم به اسم node-hooker که سازندش اومده از هوک های wordpress الهام گرفته و یه چیزی شبیه به اونارو برای ران تایم node نوشته
استفاده ازش میتونه وابستگی بخش های مختلف رو کمتر کنه و این امکان رو بده که باهاش یه معماری پلاگین محور بتونیم پیاده کنیم
اگه علاقه مند بودین یه سری به این پروژه بزنین.

https://mamedul.github.io/node-hooker/

@DevTwitter | <Ali Nazari/>

مولانا | دیوان شمس | رباعیات | رباعی شمارهٔ ۹۷۷

از روز قیامت جهان سوز بترس
وز ناوک انتقام دلدوز بترس
ای در شب حرص خفته در خواب دراز
صبح اجلت رسید از روز بترس

#مولانا | گنجور
📍@iipoem

🔵 عنوان مقاله
3 Critical TTL Patterns for In-Memory Caching

🟢 خلاصه مقاله:
این مقاله سه الگوی کلیدی TTL برای کش درون‌حافظه‌ای را توضیح می‌دهد و نشان می‌دهد چگونه انتخاب درست میان تازگی داده، کارایی و پایداری را ممکن می‌کند. الگوی اول، TTL ثابت است: هر مقدار پس از مدت مشخص منقضی می‌شود؛ ساده و قابل‌پیش‌بینی است، اما نزدیک انقضا می‌تواند داده قدیمی ارائه کند و پس از انقضا به «thundering herd» منجر شود مگر اینکه با jitter و هم‌گرایی درخواست‌ها مدیریت شود. الگوی دوم، TTL لغزشی است: هر دسترسی عمر آیتم را تمدید می‌کند، برای کلیدهای پرترافیک عالی است اما بدون «حداکثر عمر» ممکن است بعضی مقادیر عملاً هرگز تازه‌سازی نشوند. الگوی سوم، stale-while-revalidate (و refresh-ahead) است: مقدار کمی کهنه فوراً سرو می‌شود و تازه‌سازی در پس‌زمینه انجام می‌گیرد؛ با single-flight از هجوم درخواست‌های همسان جلوگیری می‌کند و در صورت خطا می‌توان با stale-if-error موقتاً از آخرین مقدار سالم استفاده کرد. در عمل ترکیب این الگوها—به‌همراه TTLهای متفاوت برای هر کلید، jitter، backoff و رصد دقیق نرخ hit/miss—به تعادل بهینه می‌انجامد. نویسنده برای نمایش پیاده‌سازی‌های عملی از کتابخانه Hot در اکوسیستم Go بهره می‌گیرد تا استفاده از این الگوها ساده و کارا شود.

#Caching #TTL #InMemoryCache #Go #Golang #StaleWhileRevalidate #Performance #CacheStampede

🟣لینک مقاله:
https://golangweekly.com/link/175058/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

مدیریت خطا و پیام‌ها

تو هر پروژه‌ای خطا اجتناب‌ناپذیره، مهم اینه چطور باهاش برخورد کنیم. اگه پیام‌ها درست مدیریت نشن، هم کاربر گیج میشه، هم فرانت سخت‌تر می‌تونه هندل کنه.

چند تا نکته به عنوان best practice:

- برای خطاها یه ساختار مشخص داشته باش تا فرانت بتونه راحت تشخیص بده با چه شرایطی طرفه.
- پیام برای کاربر باید ساده و قابل فهم باشه، نه پر از اصطلاحات فنی.
- جزئیات فنی و لاگ‌ها رو نگه دار برای بک‌اند و تیم فنی، نه برای کاربر.
- همیشه از پیام‌های عمومی برای خطاهای پیش‌بینی‌نشده استفاده کن (مثل "مشکلی پیش اومده، دوباره امتحان کن").
- خطاها رو دسته‌بندی کن (مثلاً خطای کاربر، خطای سرور، خطای دسترسی) تا بتونی راحت‌تر مدیریت کنی.

از مهمترین شرایطی که باید یک توسعه دهنده بک اند در API لحاظ کنه Custom Exception Handler هستش تا بتونه خطا ها رو با یک فرمت مناسب و یک دست پاسخ بده و این موضوع بر اساس کمپانی های مختلف متفاوت هستش ولی می تونین الگوی مناسبی رو از درونشون پیدا کنین.

مثلا داشتن کلید error در پیام و همچنین در ادامه status کد خطای اتفاق افتاده و همچنین جدا سازی detail و message که در یکی خطای توسعه و دیگری پیام قابل نمایش به کاربر قرار میگیره. در بعضی شرایط ممکنه حتی timestamp و اطلاعات بیشتری هم درج بشه مثلا code یا type که ممکنه شماره خطای خاص و یا کلید واژه مربوطه برای ردگیری خطای سریعتر باشه.

دیده میشه گاهی وقتا آدرس و یا حتی ورودی ها رو هم در بعضی سرویس ها نشون میدن که به نظرم جاش توی ریسپانس نیست و باید توی لاگ ها باشه و با این حال بعضی سرویس ها ارائه میدن.


نمونه Response مناسب برای خطا ها

{
  "error": {
    "status": 404,
    "code": "OBJECT_NOT_FOUND",
    "message": "آبجکت مورد نظر یافت نشد",
    "detail": "Object matching query does not exist.",
    "timestamp": "2025-10-03T12:30:45Z"
  }
}

رفرنس ها:
- https://zuplo.com/learning-center/best-practices-for-api-error-handling
- https://api7.ai/learning-center/api-101/error-handling-apis
- https://nordicapis.com/5-real-world-examples-of-great-api-error-messages/
- https://www.baeldung.com/rest-api-error-handling-best-practices


📢 @thealibigdeli_channel

#api_design
#api

کمپانی IBM امروز یک سری مدل جدید Granite 4.0 رو منتشر کرده، جدیدترین سری مدل‌های LLM کوچیکش!
این مدل‌ها توی کارای agentic (مثل فراخوانی ابزار)، تحلیل اسناد، RAG و کلی چیز دیگه واقعاً خیلی خوبند. مدل Micro (3.4B) (یک مدل با ۳.۴ میلیارد پارامتر!) حتی می‌تونه ۱۰۰٪ به صورت لوکال توی مرورگرتون روی WebGPU اجرا بشه، با کمک Transformers.js!

https://huggingface.co/spaces/ibm-granite/Granite-4.0-WebGPU

@DevTwitter | <Mehdi Allahyari/>

و به این شکل یوزر هر زبونی که هست براش ترجمه میکنید.

چرا بهتره ترجمه رو سمت کلاینت نگه داریم؟

۱. از رو مرورگر میتونید متوجه بشید زبون کاربر چیه. ولی بخواین اینو رو سرور متوجه شید باید فرانت اول یک کدی بفرسته که اینو براتون تو سرور بفرسته.

۲. اینکه کاربر چه زبونی داره در درجه اول state frontend هست. نه بک اند.

۳. اگه یوزر زبونش رو تغییر داد, اگه فرانت state management رو درست انجام داده باشه بدون اینکه درخواست http ای بزنه کل محتوا صفحه رو میتونه آپدیت کنه. و این تجربه کاربری رو بهتر میکنه.

۴. اکوسیستم مدیریت زبان در فرانت بسیار قوی تره.

ولی خب در نهایت یک جاهایی مجبور میشیم ترجمه سمت سرورم داشته باشیم. مثلا ارسال نوتفیکیشن.

@PyBackendHub

این پستو دیدم تقریبا هر Rest standard ای بود توش رعایت نشده :))

در خصوص ارور و integration داشتن خوب با فرانت اند؛

۱. همیشه سعی کنید از HTTP STATUS استفاده کنید. اگه ۲۰۰ میدین یعنی ریسپانس موفقیت آمیز بوده، حالا هرچی که اسمشو موفقیت آمیز میذارید. چون تقریبا تمام ابزار های telemetry (چه بک اند چه فرانت) بر مبنا همین کار میکنه. اینکه شما http status code رو بذارید تو بادی کار بسیار اشتباه و غلطی هست. استاندارد های http رو دور زدید.

۲. فرانتی که نمیدونه کی به سرور درخواست داده، دولوپر نیست. صرفا یک LLM ای هست با دسترسی به git. یک تایمی ارسال میشه از سمت سرور به کلاینت. حالا اگه این تایم استمپ زمان اتمام درخواسته بازم برای کلاینت مهم نیست که شما بخوای رو سرور بذاری. برای کلاینت مهم اینه که درخواست رو کی دریافت کرده که میدونه.

۳. اینکه شما پیام ترجمه شده رو سمت سرور نگه دارید یک اشتباه دیگست. code کافیه. داکیومنت شما باید تو OpenAPI برای ارور ها باید schema داشته باشه که فرانت بدونه چه ارور هایی ممکنه بیاد. اینطوری اگه فرانت از ابزار های code auto generate استفاده کنه (که مثلا schema openapi رو میگیرن و کلاینت میسازن خودشون) اون ارور هارو هم میبینه و تو تایپ سیستمش میاد. میتونه اونا رو حالا به هر زبونی که کاربر هست بهش نشون بده. میتونه هرجوری بخواد ترجمه کنه. OBJECT_NOT_FOUND هم به شدت کلید اشتباهیه. چون معلوم نیست کدوم آبجکت not found عه. درستش اینه مثلا BookNotFound.‌که فرانت بتونه ترجمه کنه.

اگه خیلی فرانت بخوای قشنگ کارو در بیاره (تو سورس کد خودم اینکارو کردم) یک هوک نوشتم useError. این هوک اگه ریسپانس ۲۰۰نباشه ریسپانس رو میگیره. و کدش رو مپ میکنه به زبون یوزر و ترجمه میکنه و بهش نمایش میده. اگه کدی هم وجود نداشت (مثلا اروری که واقعا catch نشده بود) اون موقع فال بک میشه به اینکه خطایی در سرور رخ داده و نمیدونم این خطا چیه :)‌. این هوک من, به شما هم ErrorMessage رو میده. هم یک کال بکی میده که از react-toastify استفاده کرده و ارور رو toast میکنه برای شما.

پس هم میتونی بنویسی

const { errorMessage } = useError()
errorMessage(response)

و هم

const { toastError} = useError()
toastError(response)

@PyBackendHub