pybackendhub | Unsorted

Telegram-канал pybackendhub - Python BackendHub

-

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

Subscribe to a channel

Python BackendHub

یک ماه از قطع شدن اینترنت گذشت!

Читать полностью…

Python BackendHub

حتما مطالعه کنید 👆
خیلیا میگن مانی چرا با اینا بحث میکنی. اینا ارزش بحث کردن و .. رو ندارن. درست میگید، ولی بالاخره چه دوست داشته باشیم چه دوست نداشته باشیم با همینا شدیم ۹۰ میلیون. من که ایران نیستم، حداقل تاثیری که میتونم بذارم اینه که سعی کنم حداقل یکی از این ادما رو اگاه کنم. یکی خودشو به خواب میزنه، یکی هم واقعا خوابه. اونی که واقعا خوابه رو شاید بشه بیدار کرد… شاید با خودآگاهی بیدار شه.

Читать полностью…

Python BackendHub

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

Читать полностью…

Python BackendHub

وضعیت وایب کدر ها:

@PyBackendHub

Читать полностью…

Python BackendHub

ظاهرا پست لینکدین جواب داد. تو ردیت همه نوشته بودن ۲-۳ هفته طول میکشه جواب بدن بررسی کنند. جالبه تیکتی که باز کردم هنوز جوابی نگرفته. تازه sponsorship گیتهابو فعال کردن برام که بتونم پروژه هام اسپانسر بگیرن و پول بگیرم از این طریق. :))
@PyBackendHub

Читать полностью…

Python BackendHub

گیتهاب یک فیچر خوب داشت که میدیدی تو چه PR و ایشو هایی اخیرا چه فعالیت هایی بود (اونایی که سابسکرایب کرده بودی) و اینم برداشتن :))

@PyBackendHub

Читать полностью…

Python BackendHub

فکت :))
@PyBackendHub

Читать полностью…

Python BackendHub

آقا دیس لایک میذارید دلیلشم بنویسید.
به قول مهدی تو گروه همه چیز را همگان دانند و همگان هنوز از مادر نزاده اند.
چهار تا چیزم ما یاد میگیریم از کامنت هاتون.
ولی این ری اکشنا چیزی یاد کسی نمیده.

کامنت و ری اکشن برای همین بازه که شما نظرتونو بگید و مخالفت کنید :)

@PyBackendHub

Читать полностью…

Python BackendHub

این پستو دیدم تقریبا هر 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

Читать полностью…

Python BackendHub

چشما رو باید شست هروقتی کد اینارو نگاه میکنی :))
البته خدایی کم کم داره بهتر میشه.
@PyBackendHub

Читать полностью…

Python BackendHub

یک سوال رو میخوام مطرح کنم , شما یک فانکشن parent دارید. داخل این فانکشن شما باید یوزر رو بگیرید (`getUser`) و بعد سه تا فانکشن inner1 و inner2 و inner3 رو صدا بزنید و یوزر رو بهشون بدید تا یک پردازشی تو دیتابیس انجام بده.
فانکشن inner1 و inner2 یوزر آیدی میگیرن و نیاز دارن یوزر لاک باشه تو دیتابیس وگرنه ممکنه ریس کاندیشن بخوره. ولی فانکشن ۳ براش مهم نیست چون پردازشی که میکنه ریس کاندیشن نمیخوره.

سوالی که پیش میاد اینه که شما چطور توابعتون رو طراحی میکنید که این مشکل به وجود نیاد؟ کدتون احتمالا این شکلیه.


def parent():
user = get_user(lock=True)
inner1(user)
inner2(user)
inner3(user)


همونطور که میبینید نحوه استفاده inner1 و inner2 کاپل شده به یوزر. من اگه حواسم نباشه lock=true رو نذارم کدم در برابر ریس کاندیشن سیف نیست. اگه یک نفر دیگه یک جای دیگه دوباره inner1 رو استفاده کنه و یادش بره یوزر رو لاک کنه بازم همین مشکلو داریم. درواقع یک استیت مشترک بین چند فانکشن داریم که فقط میشه چشمی دنبالش کرد... قبل اینکه پست بعدیو بخونید یکم بهش فکر کنید ببینید راه حلی داره این موضوع؟


@PyBackendHub

Читать полностью…

Python BackendHub

یک نمونه کد…
@PyBackendHub

Читать полностью…

Python BackendHub

یک منبع خیلی خوب برای اینکه واقعا TLS 1.2 رو درک کنید
بایت به بایت بهتون توضیح میده چه اتفاقی میفته :)

@PyBackendHub

Читать полностью…

Python BackendHub

یک مثال دیگه میزنم براتون. بین Better way و shitty way کدوم خوانا تره؟ کدوم تعداد خطوط کمتری داری؟ حالا تو پست بعدی طرز استفادشونو ببینید!

@PyBackendHub

Читать полностью…

Python BackendHub

میخوام یک تولید محتوا کنم، پنج قسمت مصاحبه به زبون انگلیسی برای پوزیشن بک اند پایتون (میدلول و سنیور) که تمرین و ریسورس خوبی باشه برای کسایی که میخوان مهاجرت کنند
چنانچه تمایل به شرکت دارید، به ایدی زیر پیام بدید

@Mani_nikou

داخل پیامتون، سطح زبان انگلیسی (بین A1 تا C2)، رزومه و ادرس لینکدینتون رو بفرستید.


@PyBackendHub

Читать полностью…

Python BackendHub

سال عجیبی بود امسال…
اومدم رستوران ایرانی
یک بغضی تو دل همه هست، یکی بغلم نشسته بود تنها بود نمیتونست حتی به خانواده اش زنگ بزنه 💔
و کارمند رستوران اومدن بغلش کردن

افتخار میکنم به تک تکمون

امیدوارم سال بعد بهترین عید با کلی جشن و کارناوال های مختلف تو آزادی کامل جشن بگیریم، این حق نسل ماست 🤞

@PyBackendHub

Читать полностью…

Python BackendHub

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

در هر صورت، امیدوارم چشم این ادما باز بشه تا قبل از اینکه خیلی دیر بشه ❤️

@PyBackendHub

Читать полностью…

Python BackendHub

لایو تجربه مهاجرت کاری مانی مظفر به آلمان 🚀🇩🇪

Software Engineer | Noah Labs | Berlin

📅 زمان: چهارشنبه ۷ آبان (29th Oct)
🕔ساعت: 10 شب به وقت ایران | ۷:۳۰ بعدازظهر به وقت اروپای مرکزی
🎙 میزبان: بابی
📆 اضافه کردن ایونت به کلندر:لینک

https://www.youtube.com/watch?v=7alVm0lwytg

Читать полностью…

Python BackendHub

یک ترد جالب تو ردیت
از اینجور آدما فراری باشید :)
کامنت خیلی خوب بود.. resume driven development 😂

@PyBackendHub

Читать полностью…

Python BackendHub

سلام به همه همراهان
من اکانت گیت هابم بسته شده, بدون اینکه دلیل رو بهم ایمیل کنند یا بگن. و این واقعا برام عجیب بود. تیکت ساختم که پییگری بشه ولی برام خیلی مهمه که بتونم اکانتمو برگردونم چون پروژه اوپن سورس داشتم روش که روزانه هزار دانلود میخورد و داکیومنتش رو گیت هاب هاست میشد :(‌

خیلی خوشحال میشم اگه این پست لینکدین رو repost کنید تا بیشتر دیده بشه 🙏


@PyBackendHub

Читать полностью…

Python BackendHub

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

/channel/PythonFellow
عضو گروه بشین، من همیشه معمولا پاسخ میدم. بقیه هم میدن، سوال ممکنه برای شما باشه ولی بقیه هم میتونن استفاده کنند جواب بدن و نظره من ممکنه bias باشه. بحث بهتره جمعی باشه تا دو نفره.


پیوی زمانی بپرسید که سوالتون رو نمیخواین تو جمع مطرح کنید به دلایل خیلی شخصی.

@PyBackendHub

Читать полностью…

Python BackendHub

مرسی که دلیل های بیشتری گذاشتین :))

Читать полностью…

Python BackendHub

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

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

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

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

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

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

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

@PyBackendHub

Читать полностью…

Python BackendHub

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

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

چند تا نکته به عنوان 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

Читать полностью…

Python BackendHub

برند تایپ یا همون New Type یعنی یه تایپ جدید بسازی رو همون تایپ قدیمی، بدون این که تو ران‌تایم هیچ خرجی داشته باشه. یه جورایی مثل اینه که سابکلس بسازی ولی واقعاً سابکلس نکردی.

فایده‌ش چیه؟ به تایپ‌چکر می‌فهمونی مثلا UserId با یه string فرق داره. تو ران‌تایم هردوش استرینگن ولی تو تایپ دیگه یکی نیستن.

تو مثال ما، یه UserId درست می‌کنیم، بعد یه برند جنریک به اسم Locked<T>. اگه تو getUser(true) صدا بزنیم خروجیش میشه Locked<UserId>. حالا توابعی که می‌خوان یوزر لاک شده باشه فقط همینو قبول می‌کنن. یعنی دولوپر مجبوره قبل استفاده یوزر رو لاک کنه، وگرنه تایپ‌چکر گیر میده و کدت دیپلوی نمیشه.

اگه اینو نداشتیم، باید تو هر تابع دوباره یوزر رو لاک می‌کردیم که هم تکراری میشه هم ران‌تایم گرون‌تر.

مزایا:
- جلوی خطا رو می‌گیره
- خودش یه جور داکیومنت زنده‌ست
- یه بار لاک می‌کنی، ران‌تایم سریع‌تره
- نگه داری کدتون رو راحت تر میکنه (maintainability)

ضررش؟ فقط دو سه خط تایپ بیشتر می‌نویسی، همین. که البته مقایسه کنی با کدی که باید بیشتر مینوشتی چون این تایپا رو نداشتی هیچ بود.

@PyBackendHub

Читать полностью…

Python BackendHub

تو بحث کردن دو روش داریم:
Strawman: یعنی ضعیف‌ترین و دم‌دستی‌ترین برداشت از حرف طرف مقابل رو می‌گیری و همونو می‌کوبی.
Steelman: یعنی قوی‌ترین و منطقی‌ترین نسخه از حرف طرف مقابل رو تصور می‌کنی و بعد اونو نقد می‌کنی.

تو بحث‌های تکنیکال و تو حوزه خودمون، حداقل steelman باشید. یعنی قبل از اینکه یه ایده رو بکوبید، سعی کنید بهترین حالت ممکنش رو در بیارید و بعد نقد کنید. ولی می‌بینم یک عده اخیرا کلا دلیلی نمیارن؛ ایده رو از بیسیک می‌زنن و میگن «کلا خوب نیست» بدون حتی یه خط استدلال! جملشون هم انگلیسی مینویسن که مثلا جذبه بیشتری داشته باشه :)) اینطوری نه بحث جلو میره، نه کسی چیزی یاد می‌گیره. اگه می‌خواید نقد کنید، اول قوی‌ترین نسخه‌ی ایده رو بسازید، بعد برید سراغ نقد.

@PyBackendHub

Читать полностью…

Python BackendHub

یک مصاحبه داشتیم با یک بنده خدا، وسط مصاحبه تو کد ادیتورش یک سینتکس ارور خورد، جای اینکه Fix with AI رو همون ارور رو ادیتورش بزنه یک تب باز کرد گفت این فایلو اسکن کن ببین چه مشکلی داره 😁 نکته دارکش اینجا بود که وسط جواب credit اش تموم شد:)) بعد یک تب دیگه باز کرد فایلو کپی پیست کرد، جوابی که بهش داد درست بود ولی مثالی که زده بود دقیقا با کدش یکی نبود و داشت ارور های دیگه میخورد.. اینقدر دست پاچه شد که مصاحبشو خراب کرد.

اما فقط ایشون نیست، تو ۱۰ تا assignment آخری که ریویو کردم ۹ تاش با AI نوشته شده بود، و کاملا وایب کدینگ… برای سنیور 🤦‍♂️

من واقعا فکر نمیکنم از ندونستن باشه، بیشتر به این مشکل دچار شدن که اینقدر از AI استفاده کردن که بیسیک برنامه نویسی یادشون رفته… چون با یک سرچ ساده به سولوشن میرسن.

@PyBackendHub

Читать полностью…

Python BackendHub

حالا طرز استفاده رو ببینید... بله تعداد خطوط‍ FooComponent خیلی کمتره. ولی در عوض هم شکننده تره هم ناخوانا تر. چرا شکننده تره؟‌چون اگه هم loading=true باشه هم data داشته باشه تو فرانت Loading Data... رو نشون میده دیتا هم میاد زیرش 😁 حالا باید بیای این کیس رو هندل بکنی!

بعضی کد ها اینقدر بد از تایپینگ استفاده کردن که شما وقتی کد رو میخونی باید رمزگشایی کنی ببینی هدف طرف چی بوده. اینکه صرفا شما میگی این variable تایپش string عه دلیل نمیشه کدتون تایپینگ خوبی داره!

@PyBackendHub

Читать полностью…

Python BackendHub

از کانال های مختلف دیدم پست میذارن که بله تایپینگ کد شما رو بیشتر میکنه کثیف تر میکنه اگه میخواستیم تایپ بزنیم که میرفتیم سمت C و این حرفا. اولا که C تایپ سیستم قوی نداره. تایپ سیستم بسیار ساده ای داره. پس statically typed بودن یا نبودن یک زبون رو خوب/بد بودن تایپ سیستمش تاثیری نمیذاره. پس اگه انتخابتون C هست برای اینکه تایپ سیستم قوی داشته باشین انتخاب درستی نیست!‌

ثانیا تایپینگ خودش یک داکیومنته. مثلا شما فکر کنید من یک سیستم نوشتم که ۱۰ تاسیستم مختلف رو integrate میکنه و یک API واحد میده برای هر ۱۰ تاشون. من یا میتونم ۱۰ صفحه داکیومنت بنویسم که اگه خواستیم یک سیستم جدید اضافه کنیم چه دپندسی هایی وجود داره یا اینکه میتونم یک Enum داشته باشم به اسم Service و همه جا با اون Enum بیام exhaustive check انجام بدم.

مثالش, من اینجا فقط یک سرویس Digikala دارم. و برای دیجی کالا یک رفتاری رو تعریف کردم و چک کردم سرویسی نباشه که این رفتار براش تعریف نشده باشه (`assert_never`)


def do_foo(service: Service):
match service:
case Service.DIGI_KALA: ...
case _: assert_never(service)


وقتی من یک سرویس جدید اضافه کنم به Enum ام اگه من کد رو کمپایل کنم یا تایپ چکر رو کد ران کنم و کدم کمپایل شه, کلی ارور تایپینگ میبینم که میگه شما این دپندنسی رو تعریف نکردی. مثل همین فانکشن. اون موقع به محض اینکه من تمام ایرادات تایپینگ رو برطرف کنم PRام تموم شده.

کد خواناییشو از دست میده؟ نه واقعا!‌شما اگه خوانایی کد رو به تعداد خط ملاک قرار میدین, پس کد ننویسید که خیلی خوانا و تمیز باشه. کد خوانا یعنی من کدی رو بخونم و بفهمم چیکار میکنه و constraint های اون کد چیه و تو موقع استفاده ازش اشتباه نکنم.

یک مثال دیگه بازم تو پست بعدی میزنم
@PyBackendHub

Читать полностью…

Python BackendHub

خلاصه پروداکتا یک وقتا به یک جایی میرسن که هر تغییری بدی یکی یک شکایتی میکنه :))
وقتی باگ ها تبدیل به فیچر میشن
@PyBackendHub

Читать полностью…
Subscribe to a channel