-
Learning python & Backend Engineering, with Mani! Youtube: https://www.youtube.com/@GitOverHere Github: https://github.com/ManiMozaffar Linkedin: https://www.linkedin.com/in/manimozaffar Admin: @Mani_nikou لینک گروه: https://t.me/PythonFellow
نسخه جدید RichAPI منتشر شد. ممنون میشم استار بدید 🫶❤️
https://github.com/ManiMozaffar/richapi
این لایبری رو ۲-۳ سال پیش نوشتم. کاری که میکنه اینه که از abstract syntax tree میره میبینه کد شما چه API Error هایی ممکنه بده. و اونا رو براتون داخل OpenAPI json اضافه میکنه.
چه نیازی میشه؟
۱. طبیعتا اینتگریشن frontend رو بهتر میکنه. چون فرانت میتونه دقیقا از یک لایبری code generator استفاده کنه از رو openapi. و وقتی یک endpoint رو صدا میزنه تمام حالت های failure بیاد تو تایپ سیستم. اینطوری مثلا میتونه دقیقا به یوزر پرامپت بده که فرمی که مثلا فرستاد سمت سرور چه ایراداتی داشت.
۲. برای اینتگریشن بقیه کلاینت ها هم خیلی مناسبه. دیگه شما میدونی یک api تحت چه شرایطی ممکنه fail بشه. یک جورایی داکیومنت کدتون هم هست.
حالا چه تغییراتی تو این نسخه داشتیم؟
۱. سرعت ۲۰ برابر شده
۲. یوزکیس های خیلی بیشتری رو الان کاور میکنیم که قبلا نمیتونستیم از syntax tree بگیریم.
۳. میتونید یک فانکشن بدید و ببینید چه اکسپشن های fastapi ای داره raise میکنه. و خودتون دستی داکیومنت کنید اگه دوست ندارین این لایبری براتون انجام بده و از لایبری من به عنوان تست استفاده کنید
@PyBackendHub
یکی از سوالات مورد علاقم تو مصاحبه ها همیشه:
اگه تو مرورگرتون google.com بنویسید و enter رو بزنید چه اتفاقاتی میفته.
با همین سوال میشه عمق دانش نتورک و از همه مهم تر, میزان کنجکاوی کاندید رو تا حدی سنجید.
@PyBackendHub
یک پست آموزشی در خصوص دیپلوی کردن به روش امن تر و ریسک هایی که شاید نمیدونستید وجود دارن.
معمولاً یک IP دارید که آیپی سرورتون هست و اونجا دیپلوی میکنید.
مشکل اول: DDoS
برای امن شدن در برابر DDoS معمولاً میاین سراغ یک سرویسی مثل Cloudflare. دامینتون رو اونجا ثبت میکنید، name serverتون رو کلادفلیر میکنید، و اگه رو DNS پروکسی زده باشید خودش منیج میکنه که زیر حمله Under Attack Mode فعال بشه.
منتهی این مدل خودش دو تا مشکل امنیتی داره:
مشکل ۱: لو رفتن IP سرور
اگه اتکر به هر نحوی به IP واقعی سرورتون دسترسی پیدا کنه، میتونه مستقیم به سرور اتک بزنه، نه به سایتتون. یعنی کل لایهی محافظتی کلادفلیر رو دور میزنه.
مشکل ۲: ترافیک انکریپتنشده بین Cloudflare و سرور
حتی وقتی پروکسی کلادفلیر روشنه، ترافیک بین edge کلادفلیر و سرور شما لزوماً انکریپت نیست. بهصورت پیشفرض این بخش میتونه بهصورت HTTP ساده روی اینترنت پابلیک رد و بدل بشه (مگه اینکه SSL روی سرورتون نصب کرده باشید و mode رو Full/Strict گذاشته باشید). یعنی همون بخشی که از edge کلادفلیر تا IP سرور طی میشه، اگه کسی مسیر رو شنود کنه یا بین راه بایسته، میتونه ترافیک رو بخونه یا دستکاری کنه.
راهحل: Cloudflare Tunnel
به جای اینکه پورت ریورسپروکسیتون (nginx یا هرچی) رو مستقیم روی اینترنت پابلیک باز نگه دارید، یک پراسس به اسم cloudflared روی سرور بالا میارید که خودش یک کانکشن outbound به شبکهی کلادفلیر میزنه. یعنی هیچ پورتی روی سرورتون باز نیست، سرور خودش میره وصل میشه به کلادفلیر.
ترافیک کاربر اول میرسه به edge کلادفلیر (همونجا DDoS protection و WAF اعمال میشه)، بعد از همون تونلی که از قبل برقرار شده به سرور شما فوروارد میشه. این تونل خودش بهصورت پیشفرض انکریپته، پس دیگه نگران HTTP ساده بین کلادفلیر و سرورتون هم نیستید.
نتیجه: چون IP سرور اصلاً exposed نیست و مسیر هم سرتاسر انکریپته، اتکر نه چیزی برای هدف گرفتن مستقیم داره، نه جایی برای شنود ترافیک.
@PyBackendHub
کلا کرسر نخرید پولتون رو دور میریزید
با ۲۰ دلار کرسر میتونید تهش ۱.۵ میلیون توکن مصرف کنید
همون رو برید رو خود کلاود تا ۵۰-۱۰۰ میلیون مصرف میکنید...
اینم اضافه کنم که اگه سمت codex برید حتی مصرفش کمتره و بیشتر میتونید استفاده کنید. ولی خب در عوض پرفومنسش نسبت به مدل های opus ضعیف تره.
@PyBackendHub
تو کامنت ها به AI اشاره کردن، نسبتا تو این یک سال گذشته AI پیشرفت زیادی داشته و خودمم زیاد استفاده میکنم اخیرا. اولا توصیه میکنم یک پلن ۲۰ دلاری claude code رو بگیرید چون از همه چیز بهتره. برای اینکه usage تون سریع تموم نشه از RTK استفاده کنید. RTK چیه؟ یک ابزار cli proxyکه وقتی مثلا شما مینویسی rtk git status همون ریزالتو خلاصه تر و بهتر تو توکن کمتری بهتون میده (بدون استفاده از AI، کامند های معروف رو میشناسه و اونا رو اپتمایز کرده)
راجب خود AI ولی نظرم تغییری نکرده.ببینید AI در حال حاضر برای تبدیل یک سولوشن به کد ابزار مناسبیه. ولی تایپ کردن کد هیچوقت قسمت سخت برنامه نویسی نبوده. قسمت سخت اینه که شما سعی کنی مشکل رو متوجه شی، ببینی واقعا چی لازمه، به edge case ها دقت کنی، و سیستم هایی بسازید که usage واقعی رو بتونن هندل کنن. اگه سیستم شما کلی constraint مختلف داره، همه تصمیم ها پشتش ترید اف هست، و یک نفر باید اون تصمیم هارو بگیره طبق انتظاراتی که از نرم افزار میره.
تو دنیای ایده آلی که شما دقیقا میدونید چی میخواید میشه یک پروداکت رو وایب کد کرد. ولی این دنیا ایده آل وجود نداره.. چون کلی edge case وجود داره که باید بهش فکر کنید و کلی تصمیم بگیرید…
یک مثال بزنم. یک سیستم دلیوری نوشتم که یک سری دیوایس رو میده دست end user ها. و استتوس این دلیوری ها از webhook به سرور ما میرسید. تو دیتابیس یک constrainr داشتیم که یک دیوایس نمیتونه همزمان پیش ۲ یوزر باشه.
حالا یک باگ خوردیم، یک دیوایس رفته بود واسه یک کاربر، کار نمیکرد، خودش دستی پست کرده بود پس داده بود (استتوس اینو نداشتیم قاعدتا چون بسته رو قبول کرده بود)، بعد بلافاصله همون دیوایسه رفته بود دست یک یوزر دیگه.، و نکته جالب اینه که نوتیف این دو تا دلیوری با فاصله نصف روز رفته بود. حالا ما مونده بودیم چه اتفاقی افتاده اینجا :)) چون edge case ای بود که بهش فکر نکرده بودیم.
ولی همین که constraint گذاشتیم رو تیبل که یک دیوایس همزمان دست یک نفر باشه باعث شد مشکل رو پیدا کنیم در درجه اول… اگه وایب کد شده بود احتمالا اینو نداشت و احتمالا کسی متوجه این edge case نمیشد و ممکن بود فکر کنیم دیوایس دست یک یوزردیگه هست وقتی نیست که کلی خسارت میزد بهمون.
@PyBackendHub
یک paper اومده بیرون تحقیق کرده رو اینکه خروجی llm ها چقدر بهتر میشه اگه با llm بی ادب باشه
https://arxiv.org/pdf/2510.04950
بدترین نسخش اینه:
You poor creature, do you even know how to solve this? Hey gofer, figure this out. I know you are not smart, but try this.
و بهترین نسخش اینه:
Can you kindly consider the following problem and provide your answer. Can I request your assistance with this question. Would you be so kind as to solve the following question?
جالب اینجاست بدترین نسخه ۵ درصد دقت بهتری داره 😁
و نکته بعدیش هم اینه که بدترین نسخش اونقدرا هم بد نیست :)) امیدوارم چتای من با claude لو نره اگه این بده :)) ولی حداقل فهمیدم پرفومنس بهتری میگیرم 😂
@PyBackendHub
سال عجیبی بود امسال…
اومدم رستوران ایرانی
یک بغضی تو دل همه هست، یکی بغلم نشسته بود تنها بود نمیتونست حتی به خانواده اش زنگ بزنه 💔
و کارمند رستوران اومدن بغلش کردن
افتخار میکنم به تک تکمون
امیدوارم سال بعد بهترین عید با کلی جشن و کارناوال های مختلف تو آزادی کامل جشن بگیریم، این حق نسل ماست 🤞
@PyBackendHub
دونم چند وقته پست نذاشتم، ولی خواستم یه چیزی رو بگم. هم حالم از سید بهم میخوره، هم از کل اون گروهش.
راستش به نظرم برای اینکه چرا بعضیا هنوز طرف یه همچین سیستمی وایسادن، فقط یه جواب ساده وجود نداره. یه بخشش برمیگرده به این که وقتی یکی کل عمرشو پای یه عقیده گذاشته، خیلی سخته یه روز بیدار شه و بگه «شاید اشتباه کردم». اون لحظه یعنی باید قبول کنه سالها از زندگیش رو روی چیزی گذاشته که ممکنه درست نبوده باشه. این برای خیلیا قابل تحمل نیست. حس میکنن اگه اون باور بریزه، خودشون هم میریزن.
دلایل دیگه هم وجود داره، مثلا با این هویت بزرگ شدن و ذهنشون ناخواسته میخواد از هویتشون دفاع کنه. و جدا شدن از این هویت براشون حالتی بیثباتی رو ایجاد میکنه. و یا بعضیاشون نون به نرخ روز خورن. و یا ممکنه بعضیاشون امنیتشون در خطرباشه و نخوان ریسک کنن.
در هر صورت، امیدوارم چشم این ادما باز بشه تا قبل از اینکه خیلی دیر بشه ❤️
@PyBackendHub
لایو تجربه مهاجرت کاری مانی مظفر به آلمان 🚀🇩🇪
Software Engineer | Noah Labs | Berlin
📅 زمان: چهارشنبه ۷ آبان (29th Oct)
🕔ساعت: 10 شب به وقت ایران | ۷:۳۰ بعدازظهر به وقت اروپای مرکزی
🎙 میزبان: بابی
📆 اضافه کردن ایونت به کلندر:لینک
https://www.youtube.com/watch?v=7alVm0lwytg
یک ترد جالب تو ردیت
از اینجور آدما فراری باشید :)
کامنت خیلی خوب بود.. resume driven development 😂
@PyBackendHub
سلام به همه همراهان
من اکانت گیت هابم بسته شده, بدون اینکه دلیل رو بهم ایمیل کنند یا بگن. و این واقعا برام عجیب بود. تیکت ساختم که پییگری بشه ولی برام خیلی مهمه که بتونم اکانتمو برگردونم چون پروژه اوپن سورس داشتم روش که روزانه هزار دانلود میخورد و داکیومنتش رو گیت هاب هاست میشد :(
خیلی خوشحال میشم اگه این پست لینکدین رو repost کنید تا بیشتر دیده بشه 🙏
@PyBackendHub
دوستان خواهشا پیوی من سوال برنامه نویسی و جنرال نپرسید.
/channel/PythonFellow
عضو گروه بشین، من همیشه معمولا پاسخ میدم. بقیه هم میدن، سوال ممکنه برای شما باشه ولی بقیه هم میتونن استفاده کنند جواب بدن و نظره من ممکنه bias باشه. بحث بهتره جمعی باشه تا دو نفره.
پیوی زمانی بپرسید که سوالتون رو نمیخواین تو جمع مطرح کنید به دلایل خیلی شخصی.
@PyBackendHub
و به این شکل یوزر هر زبونی که هست براش ترجمه میکنید.
چرا بهتره ترجمه رو سمت کلاینت نگه داریم؟
۱. از رو مرورگر میتونید متوجه بشید زبون کاربر چیه. ولی بخواین اینو رو سرور متوجه شید باید فرانت اول یک کدی بفرسته که اینو براتون تو سرور بفرسته.
۲. اینکه کاربر چه زبونی داره در درجه اول state frontend هست. نه بک اند.
۳. اگه یوزر زبونش رو تغییر داد, اگه فرانت state management رو درست انجام داده باشه بدون اینکه درخواست http ای بزنه کل محتوا صفحه رو میتونه آپدیت کنه. و این تجربه کاربری رو بهتر میکنه.
۴. اکوسیستم مدیریت زبان در فرانت بسیار قوی تره.
ولی خب در نهایت یک جاهایی مجبور میشیم ترجمه سمت سرورم داشته باشیم. مثلا ارسال نوتفیکیشن.
@PyBackendHub
مدیریت خطا و پیامها
تو هر پروژهای خطا اجتنابناپذیره، مهم اینه چطور باهاش برخورد کنیم. اگه پیامها درست مدیریت نشن، هم کاربر گیج میشه، هم فرانت سختتر میتونه هندل کنه.
چند تا نکته به عنوان 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"
}
}
این سوال تو چند تا مصاحبه ازم پرسیده شده، ولی چیزی که بیشتر از همه یادمه مصاحبه با یکی از شرکتهای زیرمجموعه فولکس واگن بود.
با یک geek مصاحبه داشتم، لایو کد بود و بعدش رسیدیم به بخش سوالها. این سوال رو ازم پرسید و هر جوابی که میدادم، یک چرا یا چطور میذاشت اولش و هی عمیقتر میشد تا جایی که دیگه جوابش رو بلد نبودم. ولی خیلی برام آموزنده بود.
مثلا سادهترین جواب به این سوال اینه که سیستم شما از طریق DNS آدرس IP مربوط به google.com رو پیدا میکنه و بعد مرورگر یک درخواست HTTP مثل GET به سرور میفرسته. سرور هم یک response برمیگردونه که میتونه شامل HTML، CSS، JavaScript، عکس یا فایلهای دیگه باشه. مرورگر این محتوا رو دریافت میکنه، HTML و CSS رو parse میکنه، JavaScript رو اجرا میکنه و در نهایت صفحه رو render میکنه و به شما نمایش میده. مثلا اگه پوزیشن سنیور باشه و جواب فقط تا همین حد بمونه، من شخصا اینو یک پوینت منفی برای مصاحبهشونده در نظر میگیرم.
ولی بعدش سوالهای اصلی شروع میشن:
درخواست چطور ارسال میشه؟
با HTTPS.
HTTPS چطور کار میکنه و چرا امنه؟
TLS، handshake، certificate و ...
DNS چطور resolve میشه؟
از طریق ISP یا DNS resolver.
ISP یا DNS resolver این رکوردها رو از کجا میارن؟
از طریق root zone، بعد top-level domain و بعد authoritative server مربوط به دامنه.
از کجا معلوم DNS resolver درباره یک دامنه دروغ نگه؟
اینجاست که DNSSEC وارد میشه.
DNSSEC چطور کار میکنه؟
چطور میشه به کل این زنجیره اعتماد کرد؟
این trust از کجا شروع میشه؟
حالا فرض کنیم به IP رسیدیم.
این packet چطور واقعا به سرور مقصد میرسه؟
Routing چطور انجام میشه؟
ASN چیه؟
BGP چیه؟
و از کجا معلوم هر روتر باید packet رو به کدوم next hop بفرسته؟
همین یک سوال ساده میتونه خیلی عمیق بشه و کمکم بخش بزرگی از اینترنت و شبکه رو به هم وصل کنه 🙂
توصیه میکنم این playlist هارو ببینید که کامل تر توضیح میدن. اولیش از udemy هست.
Fundamentals of Network Engineering - Hussein nasser
Networking Fundamentals
@PyBackendHub
با این راهحل دیگه پورتهای ۸۰/۴۴۳ نیازی نیست باز بمونن. برای بسته نگه داشتن بقیهی پورتها (از جمله پورت ssh که میشه ۲۲) هم چند تا سولوشن هست.
راهکار اول: Hub-and-Spoke VPN
یعنی چی؟ یعنی یک سرور مرکزی وجود داره که کلاینتها رو بهم وصل میکنه.
من حقیقتاً از این سولوشن خوشم نمیاد، به دو دلیل:
1. کافیه یک لحظه سرور VPN بیاد پایین تا کلاً کانکشن بیرون نتورک با داخلش کامل قطع بشه.
2. مشکل latency: فرض کنید شما تو تهران هستید، VPNتون تو المانه و سرورتون هم تهرانه. برای اینکه یک packet داده بفرستید، این داده اول باید بره آلمان و بعد برگرده تهران. این latency رو خیلی افزایش میده.
راهکار بهتر: Mesh VPN
اینجا دیوایسها مستقیم بهم وصل میشن، بدون واسطهی مرکزی.
من توصیه میکنم از Tailscale استفاده کنید. تا یک تعداد دیوایس رو حتی رایگان ساپورت میکنه. نسخهی اوپنسورسش هم هست Headscale.
خوبیش اینه که کلاینتها رو مستقیم بهم وصل میکنه و از طریق UDP hole punching این کار رو انجام میده، پس latency خیلی بهتری میگیرید.
@PyBackendHub
این روزا برای استخدام نیرو چیکار میکنید؟
عملا با اومدن opus 4.8 و fable 5 دیگه واقعا take home assignment ارزشی نداره.
یادمه همون assignment ای که به کاندید ها میدادیم و از ۱۰ نفر ۱ نفر درست حلش میکردن الان اینطوریه که همه دارن درست حل میکنن.
حالا مشکل چیه اگه یک نفر از AI استفاده کنه؟ مشکلی نداره.قبلا توضیح دادم کد زدن کلا دو مرحلست, مرحله اول شما raw requirement رو میگیرید و یک پلن مینویسید. که چطور این فیچر باشه. و کلی ترید آف پشت این تصمیم گیریا هست.
و در مرحله دوم شما اون پلن رو پیاده سازی میکنید. تبدیل اون پلن به کد هیچوقت کار سختی نبوده.
تو لایو کد چون کاندید میتونه سوال بپرسه و نحوه فکر کردن کاندید و شخصیت کاریش تا حدی مشخص میشه بنظرم الان خیلی مناسبه برای استخدام نیرو. ولی مشکلی که داره اینه که واقعا زمان بره یعنی شما هرکی که بخواد از مصاحبه اول رد بشه رو بخواین باهاش لایو کد انجام بدید ریسورس زیادی میخواد.
سیستم دیزاین هم همینطوریه. یعنی دوباره این تصمیم گیریا و نحوه خط فکری کاندید بولد میشه.
حالا سوال اینجاست که چطور میتونیم take home assignment ای داشته باشیم که صرفا نتونید بدید به claude code و سولوشن پرفکت رو بهتون بده؟ یا اصلا راه دیگه ای هست به جز سیستم دیزاین یا لایو کد که وقت بیشتری میگیره بخوایم برای هر کاندید انجام بدیم؟
@PyBackendHub
این همون RTK هست که بهش اشاره کردم (Rust token killer)
https://github.com/rtk-ai/rtk
اینم graphify هست. به جای اینکه هربار کل کدتون رو بخونه، graph کدتون رو میخونه و متوجه میشه چطوری پروژتون organize شده و کمتر توکن مصرف میکنه. دقت کنید این خودش با AI جنریت میشه. وقتی کدتون رو زیاد تغییر میدید حتما ریجنریت کنید.
https://github.com/safishamsi/graphify
دغدغه و چالش این روزاتون چیه؟ میخوام ببینم راجب چی پست بذارم یا محتوا تولید کنم ..
Читать полностью…
حتما مطالعه کنید 👆
خیلیا میگن مانی چرا با اینا بحث میکنی. اینا ارزش بحث کردن و .. رو ندارن. درست میگید، ولی بالاخره چه دوست داشته باشیم چه دوست نداشته باشیم با همینا شدیم ۹۰ میلیون. من که ایران نیستم، حداقل تاثیری که میتونم بذارم اینه که سعی کنم حداقل یکی از این ادما رو اگاه کنم. یکی خودشو به خواب میزنه، یکی هم واقعا خوابه. اونی که واقعا خوابه رو شاید بشه بیدار کرد… شاید با خودآگاهی بیدار شه.
اگه لایو رو از دست دادین سیو شده. کامنت یا سوالی داشتین بپرسید این زیر حتما که تو لایو نتونستیم بهش بپردازیم.
Читать полностью…
ظاهرا پست لینکدین جواب داد. تو ردیت همه نوشته بودن ۲-۳ هفته طول میکشه جواب بدن بررسی کنند. جالبه تیکتی که باز کردم هنوز جوابی نگرفته. تازه sponsorship گیتهابو فعال کردن برام که بتونم پروژه هام اسپانسر بگیرن و پول بگیرم از این طریق. :))
@PyBackendHub
گیتهاب یک فیچر خوب داشت که میدیدی تو چه PR و ایشو هایی اخیرا چه فعالیت هایی بود (اونایی که سابسکرایب کرده بودی) و اینم برداشتن :))
@PyBackendHub
آقا دیس لایک میذارید دلیلشم بنویسید.
به قول مهدی تو گروه همه چیز را همگان دانند و همگان هنوز از مادر نزاده اند.
چهار تا چیزم ما یاد میگیریم از کامنت هاتون.
ولی این ری اکشنا چیزی یاد کسی نمیده.
کامنت و ری اکشن برای همین بازه که شما نظرتونو بگید و مخالفت کنید :)
@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