سروش تو کامنتا جواب داد: کانکشن پول بیشترین افزایش performance ش زمانی هست که به "یک سایت" یعنی پورت و آیپی یکسان چندین request بدیم. میاد از keep-alive استفاده میکنه و کانکشن رو باز نگهمیداره. دیگه هربار هی tcp handshake و tls handshake نمیکنه با سرور. درخواست بعدی از همون سوکت و کانکشن استفاده میکنه.

به زبون ساده مرحله ۲ و ۳ طبق عکس تکرار نمیشه. البته درستش اینه بگیم برای هر اوریجین نه سایت. و این موضوع فقط برای http 1.1 هست. http 1.0 اصلا keep alive نداشت و deprecate شده از سال ۱۹۹۷. این هدر به صورت دیفالت هروقت شما از هر کلاینت http استفاده میکنی هندل میشه. یعنی درواقع کلاینت http پایتون (فرقی نمیکنه httpx یا هر لایبری دیگه ای) یک کانکشن پولینگ داره که درخواست هارو با اون میزنه و از کانکشن reuse میکنه.

حالا میخوام شما پرفومنسی که میگیرین رو لمس کنید تو سه سناریویی که
۱. کلاینت global دارین. یعنی یک جایی یک کلاینت ساختین به صورت سینگلتون و همه جا از اون استفاده میکنید.
۲. ابستکرشن روی کلاینت دارین. یعنی مثلا کراولر دارین و هر کرالورتون یک کلاینت داره
۳. اصلا کانکشن پولینگ ندارین. یعنی کلاینت درخواست میزنه

تو سناریو اول شما به محض اینکه هر اوریجینی درخواست بزنید, درخواست اول کمی کند تره. اما از درخواست دوم مدت زمان اجرا شما خیلی کمتر میشه.
تو سناریو دوم, اگه دو کلاینتتون به یک اوریجین درخواست بزنه اونوقت هرکدوم دارن مرحله ۲ و ۳ رو تکرار میکنن برای همین برای اوریجین های تکراری تو کراولر های مختلف مشکل خواهید داشت.
تا سناریو سوم که افتضاحه. شما هر درخواستی که میزنید درواقع tcp handshake میده و پشتش هم میبنده. این اتفاق میفته وقتی شما مستقیم متود ‍get رو از لایبری request استفاده میکنید.

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

The concept of a "hot loop" refers to the part of your application that is repeatedly executed and can become a performance bottleneck, especially if it involves network operations like establishing new connections. Understanding and optimizing this aspect of your code can lead to significant performance improvements.


@PyBackendHub

با درک کردن عکسه و متنی که گفتم حالا متوجه میشین که چرا داکیومنت توصیه کرده شما کلاینت گلوبال داشته باشین. متوجه میشین که چرا باید درخواست رو توی context منیجر بذارین چون باید close شه (لایه پنجم). تو حالت sync کلوز توی مجیک متود del زده میشه که موقع garbage collect اتفاق میفته یعنی رفرنس آبجکت ۰ میشه اونوقت کلوز میکنه خودش.
ولی تو async این اتفاق نمیفته. چون مجیک متودا اکثرا async پشتیبانی نمیکنن. ما adel نداریم.


@PyBackendHub

ادامه سری پست های SQL

علی پاسخ درستو داد تو کامنت. ولی یک نکته ای بود که هم بولد شده بود تو متن و هم میخواستم بهش برسم. ببینید کاربرد توابع windows function aggregation اینه که شما نیازی نباشه sub query بزنید که به دیتا row دسترسی داشته باشین. هروقت که اینکارو کردین یعنی بد نوشتین queryتون رو.

مثال میگم, اول علی همچین query ای زد:

with sum_val as (
    select sum(deal_amount) as region_deals_sum, region 
    from deals 
    group by region
)

select d.*, 100 * d.deal_amount/s.region_deals_sum
from deals d
join sum_val s on d.region = s.region; 

که بعدش همین خیلی راحت تر شد و بهتر شد وقتی دیگه sub query نزد:

select *, 100*deal_amount/sum(deal_amount) over (partition by region) from deals;

پس هرجایی که subquery دیدین با aggegation صرفا برای دسترسی به دیتا اون row بدونید اون query حتما اشتباه نوشته شده. 😁

بنظرتون تایپ سوم و چهارم توابع winodws function چیه که هنوز بررسیشون نکردم؟
@PyBackendHub

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

بعد سمت FastUI شما با استفاده از pydantic و لایبری fastui میای جیسونی میسازی که اون لایبری react میفهمه چطور رندرش کنه! یک چیزی شبیه htmx. اما نکته خیلی خفن ترش اینه که شما میتونی component خودتم تو ری اکت بنویسی و ساب تایپ بهش بدی و بعد لایبری ری اکتشون component شما هم رندر میکنه یعنی کاملا extendable هست😁

داک نداره هنوز، ولی داک خوب داشته باشه میتونه ابزار خیلی خوبی باشه برای توسعه یک internal tool به سریعترین شکل ممکن!

@PyBackEndHub

روز دوم, و واقعا تحت تاثیر قرار گرفتم. توصیه میکنم حتما یک سری بهش بزنید. لایبری FastUI صرفا یک مشت pydantic model عه فقط. نکته جالب تر اینه که FastUI در واقع پروتکلی پیاده سازی کرده که لایبری ری اکت طبق اون رندرینگ رو انجام میده. یعنی مثلا شما فکر کن میخوای بگی برو صفحه /foo. یعنی درواقع شما با جیسونی که از بک اندت میاد (لزوما میتونه پایتون نباشه) به صورت declarative میتونی فرانت بسازی. مثال زیر رو ببینید:

[{"event":{"url":"/foo","type":"go-to"},"type":"FireEvent"}]

و خوده react کلاینتو میبره اینجا. حالا مشابه همین میتونی بگی فرمی بساز که فیلداش اینن. تو یک div باشه با کلس x. و خلاصه به صورت جیسون میتونید تعریف کنید که چطور فرم ساخته شه. و بعد SubmitUrl هم بهش میدین که url رو میفرسته اونجا. به همین راحتی 😅و وقتی کلاینت درخواست میده به یک صفحه درواقع بک اند بهش جیسونی میده که توضیح میده اون صفحه چطور باید رندر شه و کلاینت طبق اون توضیح (که جیسونه) صفحه رو رندر میکنه. و دیتا هم داخلش باید بذاری که رندر کنه. مثلا کلاینت درخواست میده صفحه ۵ فلان تیبل رو بگیره, شما دیتا رو بهش میدی و میگی چند صفحه وجود داره آبجکت. یعنی یک جورایی هم کلاینت ساید رندرنیگه هم سرور ساید رندرینگ.


مشکلی که داره اینه که state نداره. که این هم خوبه هم بد. خوب از این نظر که باگ خیلی کمتره. بد از این نظر که دیتایی که به فرانت میدی تو هر صفحه ممکنه زیاد شه و سرعت لود صفحه رو کند کنه. مثلا استیتی نداری که فرانت یک بار استفاده کنه و بفهمه چقدر تیبل user چقدر user داره. و دیگه تو هر ریسپانس user list نیاز نباشه تعداد یوزر رو بدی. سرعت توسعه فوق العاده زیادی داره. واقعا عالیه از این نظر. component های خیلی خوبی داره و خیلی سریع میتونید یک داشبورد بسازید که خیلی کارای خفنی بکنه. اگه جایی نیاز داشتین با react همونطور که توضیح دادم میتونه extendable شه یعنی هم پایتون میتونید کد بزنید هم ری اکت.

ایده پشتش:
Think of your frontend as a puppet, and the backend as the hand within it — the puppet doesn't need to know what to say, that's kind of the point.

@PyBackEndHub

یکم با Rust کار کردم این چند وقت و ایده ای که نسبت بهش دارم اینه که Rust شما رو مجبور میکنه به همه edge case ها فکر کنید و شما رو خیلی به فکر وا میداره. خیلی باید explicit باشین راجب همه چیز که بنظره خودم تجربه توسعه رو هم خوب میکنه هم بد. بد از این نظر که طول میکشه یک برنامه رو بنویسید و خوب از این نظر که dx خوبی داره و وقتی برنامتون کامپایل شد خیلی smoothعه.

به درد توسعه وب اپلیکیشن بنظرم نمیخوره چون خیلی effort زیادی میخواد کد نوشتن باهاش و اپلیکیشن ها بیشتر data intensive هستن (مگه اپلیکیشنی cpu intensive). هیچ ادج کیسی نمیتونید داشته باشین. تایپ Any نمیتونید داشته باشید (تکنیکالی میتونید ولی برای اینکه بهش دسترسی داشته باشید و باهاش کار کنید تهش باید یک جایی cast اش کنید و همه کیس هارو هندل کنید)

اما چیزی که بنظرم توصیه میکنم حتما برین سمتش طرز و خط فکریه که شما رو به اون سمت میبره. و میتونید از همون ایده هایی که تو راست بود هم تو پایتون استفاده کنید.


@PyBackEndHub

😂😂😂😂 دقیقا همینه :)))))))))

Type masturbate 😂

@PyBackEndHub

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

مرحله ۱: مبانی و زبان‌های برنامه‌نویسی
1. مقدمه به برنامه‌نویسی
2. زبان برنامه‌نویسی پایتون
3. زبان برنامه‌نویسی جاوا اسکریپت
4. مفاهیم برنامه‌نویسی شی‌گرا

مرحله ۲: توسعه وب و فریم‌ورک‌ها
5. فریم‌ورک Django
6. فریم‌ورک FastAPI
7. فریم‌ورک VueJS
8. فریم‌ورک gRPC
9. استفاده از بوت‌استرپ، HTML، CSS و فریم‌ورک‌های CSS معتبر

مرحله ۳: دیتابیس
10. دیتابیس SQL
11. دیتابیس MongoDB
12. آشنایی با دیتابیس Neo4J
13. استفاده از ردیس، ربیت ام کیو، سلری

مرحله ۴: تکنولوژی‌های متنوع
14. مفاهیم داکر
15. آشنایی با لینوکس
16. اجرای دیپلویمنت خودکار و CI/CD

مرحله ۵: امنیت و تست‌ها
17. تکنیک‌های تست نویسی
18. استفاده از گیت
19. مفاهیم امنیت در وب

مرحله ۶: مفاهیم پیشرفته
20. مفاهیم مالتی‌تردینگ و مالتی‌پروسسینگ و Async
21. آشنایی با معماری میکروسرویس

مرحله ۷: مهارت‌های مساعدتی
22. آموزش ساخت رزومه
23. راهنمایی در مسیر کاریابی
24. فرایندهای توسعه نرم‌افزار Agile/Scrum

روش ارائه:
- کلاس‌ها به صورت لایو در دیسکورد برگزار خواهند شد.
- کلاس‌ها به صورت شبانه ارائه خواهند شد.

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

مدرس دوره:
- سید و همکاران ایشان افتخار دارند این دوره را برگزار نمایند.

کانال تلگرام سید و رفقا:
زمان دقیق شروع دوره و لینک دیسکورد در کانال سید و رفقا اطلاع رسانی داده خواهد شد
https://news.1rj.ru/str/seyed_bax

لاگرتونو خوب‌ کانفیگ کنید✅

https://www.youtube.com/watch?v=9L77QExPmI0

بحث کانفیگ درسته لاگر چیزیه که خیلی کم تو پایتون دیدم درست پیادش کنند
این چنل و کلا این یوتیوبر عالیه، مباحث عمیق پایتونی رو بهش میپردازه

@PyBackEndHub

یک چیزه خیلی مهم تو دنیای برنامه نویسی:
https://www.youtube.com/watch?v=U7A12dQgFqI

به شدت Idempotency تو کد مهمه. صرفا به API ختم نمیشه و تو سطح کد هم میتونه رعایت شه. توابعی بنویسید که در برابر arguement ای که بهش میدین همیشه Idempotent هستن! یکی از مزایا بزرگ type state بودن هم Idempotency عه.

ویدیو تایپ استیت که قبلا تو کانال فرستاده بودم:
https://youtu.be/DwAQ6dm-Vn8


@PyBackEndHub

یک نکته امروز یاد گرفتم که کاش زودتر یاد میگرفتم
تو پایتون هیچوقت از Any استفاده نکنید. اگه تایپ یک آبجکتی رو نمیدونید اونوقت از object استفاده کنید.
چرا؟
چون مجبور میشین حالا تایپ رو چک کنید و شرط بنویسید.

یعنی اگه بنویسی:

def foo(bar: Any): 
   bar.not_valid

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

def foo(bar: object): 
   bar.not_valid

استتیک تایپ چکر بهتون ایراد میگیره. پس مجبور میشین به صورت explicit تایپشو چک کنید. جاهایی که نمیدونید چه تایپی به این تابع پاس داده میشه عالیه.


@PyBackEndHub

کاربرد گروهو میخوام تغییر بدم
به گروهی برای رفع مشکل و بحث در خصوص Backend Engineering و پایتون

مرجعی هم بشه که بتونید کلا سوالات flask یا kafka یا rabbitmq یا FastAPI یا ORM هرچیز دیگه ای که ممکنه براش community پیدا نکنید. لینک:

https://news.1rj.ru/str/PythonFellow

خوشحال میشم جوین شید. قانون خاصی نداره به جز حفظ احترام اعضای گروه.

@PyBackEndHub

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

@PyBackEndHub

توصیه میکنم حتما یک سری به warp بزنید.
هم برای مک هست. هم برای لینوکس منتشر شده. (ویندوزیا یک چرخ بزنن بعدا بیان :))‌ ) قابلیتاش که زیاده چیزایی که ترمینال های دیگه هم دارن. ولی چیزایی که ترمینال های دیگه ندارن:

۱. مثل ide هست. یعنی میتونید با کلیک برید وسط تکست. یا خیلی کار هایی که تو IDE میتونید انجام بدید اینجام میتونید.

۲. با راست نوشته شده و چیزی که با rust نوشته شده اکثر مواقع هم سریعه هم امن 😂 سرعت و پرفومنس رو قشنگ حس میکنید. هیچوقت قفل نمیکنه یا کند نمیشه.

۳. یک AI داره که من استفاده نکردم نمیدونم چیکار میکنه

۴. میتونید کامند هایی که در دسترسه رو ببینید. تو این کیس دیدین آپشن های Poetry lock رو قشنگ توضیح داده یک به یک. یا مثلا موقع checkout کردن بهتون inline support میده که دارین رو کدوم گیت برنچ checkout میکنید.


warp.dev

چند ماهه میخواستم تستش کنم. یک waiting list مسخره داشت که برداشته شد.

@PyBackendHub

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

هر روز دری جدید از sqlalchemy برام باز میشه :))

میدونستین sqlalchemy میتونه با یک کلس سشن همزمان به چند دیتابیس وصل شه؟ یعنی خودش هندل میکنه. و خودش میفهمه که الان کانکشن رو باید کجا بزنه و رو کدوم دیتابیس اجرا کنه. ولی چیزی که نظرمو جلب کرد این نیست. چیزی که نظرمو جلب کرد اینه که وقتی transaction بزنید و از دو دیتابیس استفاده کنید، خودش خودکار two phase commit میزنه به صورت implicit. البته به صورت explicit هم ممکنه این. ولی برام خیلی جالب بود یک فریم ورک چقدر میتونه اون پشت مجیک و باهوش باشه که همچین کاریو بتونه انجام بده 😅. ساپورتش برای two phase commit خیلی زیاده ولی تاحالا تو هیچ orm ای همچین چیزی ندیده بودم که به صورت smart بیاد two phase بزنه خودش!

و نکته عجیب تر اینه که این لایبری یک جورایی یک maintainer فقط داره که از ۲۰۰۶ داره رو این پروژه کامیت میزنه!😁

@PyBackendHub

🫡 Commitment
به این میگن… خیلیم معروف نیست نسبت به بزرگی کاری که کرده که خدایی در حقش خیلی کم لطفی شده😅 پکیجش یکی از پردانلود ترین پکیج های پایتونه، با اختلاف خیلی بیشتری نسبت به بقیه ORM های پایتونی.

اینجام hachyderm عشه. سوال های جالبی میکنه. جالبه با community اش در حال ارتباطه دائم و ازشون سوال میپرسه😁 پیرو پست قبلیم، ایشون با این حجم سواد میاد تو پابلیک سوالشو میپرسه که نشون میده سنیور بودن به نپرسیدن و جواب اشتباه دادن نیست، بلکه به پرسیدن و جواب غلط ندادنه!

https://hachyderm.io/@zzzeek

امروز یکی جذاب ترین اتفاقات عمرم برام رخ داد، که دوست دارم اینجام به اشتراک بذارم.
تیم ایونت دعوت شدم به یک ویلایی خارج از برلین. جای خیلی خوبیه و خلاصه جاتون خالی 😁 اب و هوا ام عوض شد.

یک ایونت داشتیم، که هرکسی باید ۲۰ عکس به صورت اسلاید از یک تیکه با ارزش زندگیش درست میکرد و تو هر اسلاید ۲۰ ثانیه حرف میزد. میتونست خاطره باشه، یک عادت (hobby) باشه، یا هرچیزی. خلاصه کل افراد تیم پرزنت کردن تا اخر سر نوبت رسید به CEO. وقتی پرزنتش شروع شد عکسای ایرانو دیدم! خاطره سفرش از سال ۲۰۱۷ داخل ایرانو گفت و اینکه چقدر مردم باهاش مهربون بودن، مهمون نواز بودن، غذا مهمونش میکردن و چقدر جو صمیمی بود. از تهران و اصفهان و شیراز و چند شهر ایران دیدن کرده بود، و اخرش گفت با وجود اینکه خیلی کشور ها رفته و مسافرت کرده ولی بهترین تجربه زندگیش تو ایران بوده.

همینطور که اسلایدا رو داشت میبرد به اسلاید بعدی، خیلی حس غرور منو گرفت :)) ۷ ساله ایران نیومدم و کاش میتونستم بیام یک سر مسافرت.😁

خلاصه اینکه اگه یک سری اتفاقا نمیفتاد و یک سریا وجود نداشتن ایران واقعا توریستی ترین و قشنگ ترین کشور جهان برای همه مردم میشد 🥲

@PyBackendHub

یکی از بهترین روش های پیاده سازی retry mechanism استفاده از کانتکس منیجر و generator هست. علتش؟ چون شما میتونید یک try except ای داشته باشین که کاملا reusable هست و base اش درواقع اکسپشن هایی هست که catch میکنید.
مثالش, به جای اینکار:

def fn(): 
    try:
        foo(bar)
    except FooBarException: 
        ... # handler 1
    except BazException: 
        ... # handler 2

میتونید اینکارو انجام بدید

@contextmanager
def flow_manager(): 
    try:
        yield
    except FooBarException: 
        ... # handler 1
    except BazException: 
        ... # handler 2

with flow_manager(): 
     foo(bar)

خوبیش چیه؟ هیچی try except بلاکتون کاملا reusable میشه. خیلیا برای اینکه همچین چیزی داشته باشن ۲ لایه کلس مینویسن که نیازی نیست واقعا. اینطوری خیلی ساده تره و راحت تره. بخش زیادی از سورس کد httpx اینطوریه.
چیزی نیاز داشته باشین تو try except میتونید به کانتکس منیجر بدید. تو این مثال ساده بود من چیزی نذاشتم. ولی این شیوه کاملا داینامیکه و خیلی میتونه خوب باشه برای retry mechanism مخصوصا برای لایبریا چون نیازی نیست دیگه ارث بری انجام شه فلان متود رو اورراید کنی فلان کارو کنی فلان اتفاق میفته. نه flow کاملا دسته خودتونه.
همیشه توصیه کردم سورس کد لایبری هارو بخونید خیلی چیزا برای الهام داره. مثلا تو httpx مثالی که زدم خیلی استفاده شده و باعث شده کد یک دست و خیلی خوبی داشته باشه.

@PyBackendHub

تو جنگو هیچوقت از .save() خالی استفاده نکنید موقعه آپدیت کردن. چون هرچی تو مموری باشه فلاش میکنه به دیتابیس. پس بهتره explicit باشین و بگین چی میخواین فرستاده شه سمت دیتابیس. یک مثال عینی میزنم که متوجه شین یعنی چی این جمله.

ببین فکر کن یک مدل داری با ۳ تا فیلد

MyModel
- id
- first_name
- last_name

که دو تای پایینی nullable هستن. رکورد ایدی اول تو دیتابیس هم first name اش null هست هم last name اش. من ۲ درخواست همزمان میدم. درخواست اول first name رو مانی میکنم. درخواست دوم last name رو مظفر.
اتفاقی که میفته اینه که اول از دیتابیس MyModel رو میخونه جفت درخواستا. برای جفتشون first_name=None و last_name=None هست. بعد هرکدومشون همچین query ای میزنن:

درخواست اول:

// model.first_name = "Mani"
// model.save()
UPDATE MyModel
SET first_name = 'Mani', last_name = NULL
WHERE MyModel.id = 1

درخواست دوم:

// model.last_name = "Mozaffar"
// model.save()
UPDATE MyModel
SET first_name = NULL, last_name = 'Mozaffar'
WHERE MyModel.id = 1

دیدی چی شد؟ جفتشون یک NULL هم فرستادن سمت دیتابیس. چرا؟ چون تو مموری یکی از نام و نام خانوادگی null بود و وقتی .save رو میزنی همونو میفرسته به دیتابیس.
بنابراین یا first name نال میمونه یا last name. در صورتی که درستش اینه:

// req 2
UPDATE MyModel
SET last_name = 'Mozaffar'
WHERE MyModel.id = 1

// req 1
UPDATE MyModel
SET first_name = 'Mani'
WHERE MyModel.id = 1

معادل orm اش چی میشه؟

# req 1
MyModel.object.filter(id=instance.id).update(last_name="Mani")

# req 2
MyModel.object.filter(id=instance.id).update(last_name="Mozaffar")

# OR...
mymodel.save(update_fields=['first_name'])

@PyBackendHub