Python Hints

یک آپشن روی sqlalchemy برای relationship هست که شخصا خیلی دوسش دارم؛ باعث میشه به کوئری که سمت دیتابیس میفرستم فکر کنم بجای اینکه ساده‌ترین راه رو انتخاب کنم.
هرجا هم که نیاز دارم دولوپر‌ها به کوئری‌هاشون دقت کنند حتما ازش استفاده می‌کنم.

lazy = "raise"

الان داشتم خروجی پروفایلینگ یک پروژه رو نگاه میکردم؛‌ توی RandRng گفتم راجبش.
دیدم خیلی کوئری‌های دیتابیس زمان بر هست؛ ی سرچ توی مدل‌های دیتابیس زدم و همه‌ی relationship هارو بهش؛
lazy = "raise"
اضافه کردم؛‌ تا دلتون بخواد ارور میگیریم حالا ولی باعث میشه همه به کوئری‌هاشون فکر کنند.

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

این ترکیب به راحتی می‌تونه خیلی از پروژه‌ها رو از Postgres به Sqlite منتقل کنه؛

Sqlite + Litestream

توی خیلی پروژه‌ها برای خودم پیش اومده که یک دیتابیس نیاز داشتم؛ شاید ۵-۱۰ تا جدول ولی اینکه فقط روی یک سرور نباشه هم برام مهم بوده که خب سرویس‌های کلاد رو استفاده می‌کردم.

همزمان هم Latency میرفت بالا هم کلی هزینه پرفورمنس واسه سربارهایی کار کردن با Postgres میدادم درحالی که به ۹۰٪ اون ویژگی‌ها نیازی نداشتم.

الان داشتم دنبال یک راهکار برای یک پروژه دیگه میگشتم و واقعا دلم نمی‌خواد Latency و Throughput ام بخاطر استفاده از Postgres کم بشه و بعد بشینم اپتیمایز کنم. بخصوص اینکه این دیتابیس هیچ دیتای حساسی نداره و فقط همین که دیتاها از بین نره برام مهم هست.

به چندتا راهکار رسیدم که بنظرم این ترکیب برای کار من برنده هست بخصوص اینکه RustFS رو همین الان داریم :

Turso + Litestream + Rustfs

بعد از پروژه یادم باشه نتایجش رو هم میذارم.

پینوشت: اگر خواستید بیشتر بررسی کنید
Turso
Litestream
Rustfs

اینو یادداشت کرده بودم که بذارم:

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

امشب با مدیرعامل شرکت و صاحب پروژه صحبت می‌کردم (شاید پروژه دوم) می‌گفت علاوه بر دولوپر‌های بعدی ادمین دیتابیس هر چندوقت یکبار که روی دیتابیس کار می‌کنه ی دمش گرم هم به ما می‌گه.

من استاندارد‌های زیادی رو رعایت کردم روی اون پروژه ولی این ۵ خط بنظر میاد خیلی بچه‌هایی که روی دیتابیس کار می‌کنند رو راضی نگه‌داشته

class Base(AsyncAttrs, DeclarativeBase):
    metadata = sa.MetaData(
        naming_convention={
            "ix": "ix_%(column_0_label)s",
            "uq": "uq_%(table_name)s_%(column_0_name)s",
            "ck": "ck_%(table_name)s_%(column_0_name)s",
            "fk": "fk_%(table_name)s_%(column_0_name)s_%(referred_table_name)s",
            "pk": "pk_%(table_name)s",
        }
    )

من همیشه اینکار رو برای خودم می‌کنم که توی همه پروژه‌هام یک استاندارد رعایت شده باشه و راحت بتونم دیباگ کنم و بخونم؛ خلاصه برای راحتی خودم هست.

این حرفا رو که امشب شنیدم گفتم بذارم شما هم توی پروژه‌هاتون رعایت کنید.

امیدوارم مفید باشه

Background jobs
رو توی دو مرحله پیاده‌سازی کن
مرحله اول رو با خود
Fastapi
پیاده سازی کن ببرش زیر لود تست بعد ببین چه اتفاقی میوفته
ADR-0015
رو نمیدونم چی هست ولی اینکه بدونی تا چه زمانی از خود
Fastapi
میتونی استفاده کنی خیلی مهمه بعدش برو روی Dramatiq
——————
Auth
رو با
Argon2
هم چک کن (خیلی واجب نیست فقط برای اینکه بهش آشنا باشی)‌
————————
برای متریک
prometheus_client
استاندارد اصلی هست
————————

چندتا چیز دیگه که بهتره اضافه کنی :
۱- لاگ رو وقتی با structlog زدی بعدش باید قابل خوندن و تحلیل هم باشه اما لزوما این کار رو روی سروری که اپ لانچ هست ممکنه انجام ندی :
پس یک چیزی برای جمع کردن لاگ همه اپ‌ها لازم میشه (توی پروداکشن معمولا)‌ یک نسخه خیلی خوب و سبک و عالی :
https://vector.dev/
هست
۲- نمایش همه این‌ها؛ خیلی وقتا لاگ - تریس - متریک جمع می‌کنیم ولی تا وقتی آنالیزش نکنیم نمی‌دونیم درست هست یا نه
https://grafana.com/

گرافانا برای این وقتا خیلی خوبه (البته نیازی نیست ساخت داشبورد و ... توش رو یاد بگیری اون کار تیم‌های دیگه‌اس)
ولی همین که ببینی دیتات توی این داشبورد چطوری نشون داده میشه نکته خوبی هست


پینوشت:
اگر از نظرت مشکلی نداره plan رو بذارم تو کانال به اسم خودت.
بعنوان نمونه اگر کسی خواست انجام بده

#Backend_RoadMap
#Sample_Project

زحمت این فایل رو شایان عزیز کشیده (با استفاده درست از AI) و توی گروه گذاشت من چندتا نکته رو اضافه کردم و با اجازه‌اش گفتم بعنوان نمونه اینجا منتشر کنم

پست بعدی نکاتی هست که من اضافه کردم.

یادآوری :

https://t.me/pyHints/423

#Quick

from pydantic import SecretStr

لطفا ازین مورد استفاده کنید؛ نشستم لاگ سرور یک پروژه رو میخونم تمام اطلاعات سرور و اطلاعات کاربراش خیلی زیبا و خوانا توی لاگ هست.
قبلا هم یک موردی رو توی
@pyhints
یاد دادم برای لاگ نویسی موارد مهم.
لطفا از هر دو استفاده کنید؛ هیچ چیز مهمی نباید توی لاگ نوشته بشه.
بخصوص ایمیل و شماره‌تماس کاربر.

Python Hints pinned a photo

LLM
قراره جای برنامه نویس‌هارو بگیره ؟
من که کدم رو + دستورالعمل ریفکتور دادم تا برام تمیز کنه و خروجی که توی تصویر هست

نصف باگ‌های مدل‌های LLM رو من درآوردم باید بهم هزینه پرداخت کنند واقعا

پینوشت:
تازه ۳۵ دقیقه هم طول کشید. خودم میزدم ۲۰ دقیقه‌ای تموم می‌شد.

گزارش تیم مهندسی یکی دیگه از شرکت‌ها برای سالی بین ۲۰۲۳-۲۰۲۵ توی اون رنج بود که شرکت خیلی خیلی بزرگی هم هست و تعداد درخواست‌هاش تازه به ۵۰۰۰ رسیده

توی دوران جنگ اخیر توی گروه گذاشتم ولی متاسفانه الان پیداش نکردم؛ حتما اگر پیدا کردم اون مورد رو هم اضافه می‌کنم.

ولی بنظرم همین مورد Stackoverflow هم مورد به اندازه ملموسی هست برای درک این موضوع.

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

تا ۱۰۹ هزار درخواست در ثانیه رو می‌تونه جواب بده روی این بنچمارک؛ من اگر سرویسم به ۶۰۰۰ درخواست در ثانیه هم برسه یک چیزی در حد Stackoverflow هستم (بر اساس مصاحبه Roberta Arcoverde می‌گم)
برای تعجب بیشتر شما؛ توی مصاحبه به monolithic بودن معماری سیستم اشاره میشه و البته به اینکه on-permise هم هست.

اگر کار نیاز به صفحه ادمین و استانداردهای خارج از مایکروسرویس داشته باشه و تیم کوچیک باشه ۱۰۰٪ میرم سراغ جنگو.

عکس دوم هم از اینجا اومده و برای websocket هست
۱۰ هزار کانکشن با حجم دیتای ۱ کیلوبایت تعداد درخواست حداقل ۲۰ هزارتا (تازه روی fastapi که می‌گن برای وبساکت با حجم بایت بالا خوب نیست)

چیزایی که زیاد می‌بینم :
آدما هیچ درکی از معماری مونولوتیک و میکروسرویس ندارند و یکی رو میزنند؛ اینم بگم رندر صفحات استک اورفلو توی ۱۲ میلی ثانیه هست.
برید مصاحبه رو ببینید واقعا

آدما هیچ درکی از تعداد درخواست در ثانیه ندارند و زرتی عدد ۱ میلیون درخواست در ثانیه رو تو مصاحبه و ... اینور و اونور پرت می‌کنند

آدما هیچ درکی از هیچکدوم ندارند و حتی توانایی فهمیدن کد رو هم ندارند و فقط فریمورک پروژه رو می‌خوان عوض کنند 🤬🤬

یکبار برای همیشه؛ زرتی نرید استک بکند رو عوض کنید تا تعداد درخواست‌هاتون به ۵۰ تا در ثانیه رسید.

اگر سرویس بکند شما نمی‌تونه این تعداد درخواست رو جواب بده مشکل شما پایتون نیست؛ مشکل شما سواد هست.
واقعا خسته شدم طرف تعداد درخواست در ثانیه‌اش به ۳۰ تا هم نمیرسه میگه ما باید به Go مهاجرت کنیم.
حتما روی ۱۰۰ تا هم باید به Rust مهاجرت کنی ؟

من دوتا تصویر میذارم؛ تصویر اول بر اساس این بنچمارک مستقل با chatgpt جدول شده
برای هر کدوم تعداد درخواست بر ثانیه رو می‌نویسم:

1) Django + Postgresql: 31,000 - 33,000
2) Fastapi: 11,000 - 109,000
مثلا توی همون بنچمارک کانفیگ‌های مختلف Fastapi رو ببینید چقدر تفاوت داره از ۱۱ هزار درخواست برای یک مورد تا ۱۰۹۰۰۰ درخواست.
بدون تغییر فریمورک اصلی و کد
3) Gin: 110,000
و در نهایت فریمورک مورد علاقه خودم :
4) Axum + Postgres: 1,115,000
بله میلیون

با اینکه من خیلی به Axum علاقه دارم و بسیار هم توی کد زدن روش راحت هستم ولی تا الان نشده مشاور یا مدیر فنی تیمی باشم و Axum رو پیشنهاد بدم حتی روی بکند‌های با تعداد درخواست بسیار بالا گزینه اول همیشه FastAPI هست.

ادامه پست بعدی

class Engine():
    _instance = None
    _lock = threading.Lock()

    def __new__(cls):
        if cls._instance is None:
            with cls._lock:
                if cls._instance is None: 
                  ....

توی کد بالا بنظر شما چرا
if cls._instance
دوبار استفاده شده ؟
اگر بلد نیستید اشکالی نداره (قراره یاد بگیرید)

قبل از دیدن راهنمایی‌ها با دقت بهش فکر کنید ببینید متوجه دلیلش می‌شید ؟
راهنمایی:
به حالت async اجرای این Singleton فکر کنید

اسم این پترن : double check locking هست

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

95% of enterprise AI deployments fail to deliver value

در یک حرکتی چندتا از این شرکت‌های AI فروش داخلی (کاسبان تحریم) روی موج‌های اخیر درحال تلاش برای خوروندن LLM به شرکت‌های دیگر هستند. شرکت‌هایی که همینطوری بخاطر تحریم؛ جنگ؛ قطعی اینترنت و تعطیلی به زور سرپا موندند.

برای همین خواستم دوتا مورد رو یادآوری کنم:
اولین مورد گزارش MIT روی میزان سودآوری AI (که ۹۵٪ میزان بازگشت 0 داشتند)
‌legal.io

مورد دوم؛
تجربه شخصی بنده توی کار با تیمی از مهندس‌ها که مدتی قبل منتور اون‌ها بودم.
( استفاده درست از LLM ها برای مهندسی کامپیوتر )

با نهایت احترام به شرکت‌های AI داخلی که واقعا innovation دارند و در تلاش برای پیشرفت جامعه‌ی ایرانی هم هستند.

من یک توضیحی روی این پست قبلی درباره کانفیگ neovim خودم بدم.

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

پس چرا به اشتراک می‌ذاریم ؟

معرفی و یک چیزی برای شروع؛ اگر تلاش کرده باشید یک مورد رو از اول برای خودتون کانفیگ کنید (بخصوص دفعات اول) خوندن و کانفیگ درست انجام دادن می‌تونه از ۱-۲ روز تا ۱-۲ هفته زمان ببره ولی اگر یکی قبلا یک بیس براتون توسعه داده باشه این زمان بخصوص با وجود LLM ها می‌تونه به ۱-۲ ساعت برسه.
هیچکس هم علاقه نداره Lua یادبگیره که فقط Neovim کانفیگ کنه.

اما چندتا نکته :
۱- اگر یک چیزی می‌خواید که دانلود کنید و کار کنه؛ بهترین گزینه برای شما vscode هست
۲- اگر سنگینی vscode اذیتتون می‌کنه چون روی چند زبان کار می‌کنید یا پروژه شما خیلی بزرگ هست گزینه بهتر Zed هست.
۳- اگر تایپ ۱۰ انگشتی بلد نیسیتید؛ vim, neovim برای شما مناسب نیست
۴- اگر فقط روی یک زبان برنامه‌نویسی کار می‌کنید و vscode, zed کند نمی‌شه براتون یا اگر علاقه‌ای به کانفیگ کردن جزئیات ندارید بازم neovim بدرد شما نمی‌خوره
۵- اگر فکر می‌کنید neovim کمک می‌کنه تندتر کد بزنید چون شرتکات‌های خوبی داره؛ بهتره برای ادیتوری که روش هستید وقت بذارید و شرتکات‌های همون رو یاد بگیرید.

قبل از توضیح بیشتر :
یادتون باشه neovim دائما درحال آپدیت شدن هست؛ کانفیگ‌ها هم همینطور و بسیاری از اون‌ها بین ورژن و گیت‌کامیت تغییرات breaking هم داره شخصا ۶ ماه یا ۱ سال یکبار آپدیتش می‌کنم یا وقتی یک سیستم جدید رو کانفیگ می‌کنم و می‌بینم دیگه ورژن‌ها نمی‌خونه.

۶- قبل از اینکه با کانفیگ neovim دیگران کار کنید سعی کنید کلیدهای اصلی vim یا neovim رو یاد بگیرید.
۷- فلسفه کلیدها این هست که همه چیز روی home row باشه با استفاده زیاد از Ctrl, Alt فقط مزایای شرتکات‌ها رو از دست میدید و نشون میده این ادیتور برای شما نیست.
۸- هیچ چیز خفنی هم روی استفاده از neovim, vim نیست آدما شمارو با کدی که زدید قضاوت می‌کنند نه با ادیتوری که استفاده کردید.
۹- در نهایت از کاستومایز کردن لذت ببرید؛ این ادیتور مال شماست.

اگر به تنظیمات neovim من روی گیت‌هاب سر زده باشید و کمی هم بهش نگاه کرده باشید می‌دونید که تنظیمات مربوط به typecheck من یک مقدار هکی هست؛ ترکیبی از ruff, pyright, mypy و یک سری توابع کاستوم برای پیدا کردن .venv داخل پروژه و ...
کار می‌کرد ؟
بله
خیلی از دوستان حتی از عملکردش رضایت هم داشتند ولی روی پروژه‌های بزرگ بعضی وقتا واقعا اذیتم می‌کردم بخصوص اینکه شدیدا کند بود.

یک پیام توی گروهی دیدم (خیلی قدیمی بود و گروه رو من خیلی وقت بود باز نکرده بودم) درمورد بازنویسی pyrefly با Rust و بحث‌های پیرامون اون یک سری به سایتش زدم و دیدم چقدر عالی حالا دیگه extension هارو هم داره و با Mason هم کار می‌کنه.

اگر خواستید بدونید تفاوت سرعتش نسبت به جایگزین‌ها چقدر هست؛ صفحه‌ی اصلی رو می‌تونید چک کنید:
مثلا برای پروژه instagram (بله این پروژه روی پایتون هست)

Pyrefly: 13.4s
Pyre: more than 300s

من حوصلم نشد تا آخر Pyre صبر کنم ولی از چیزی که نوشتم هم گذشت
یا برای پروژه pytorch :

Pyrefly: 2.4s
Pyright: 35.2s
MyPy: 48.1s

دوستانی که روی پروژه بزرگ کار کردند یا CI/CD نوشتند برای پروژه یا حتی pre-commit رو فعال کردند کاملا می‌دونند من چی ‌میگم.
پیشنهاد می‌کنم حتما تستش کنید؛ برای من بسیار بسیار مفید بود واقعا

اگر هم خواستید می‌تونید از کانفیگ neovim بنده استفاده کنید

My Neovim Config

البته فعلا روی برنچ feat/pyrefly هست تا چندروز بیشتر و روی پروژه‌های دیگر هم تستش کنم و مطمئن بشم همه چیز درست کانفیگ شده.

یادآوری : ....

توی پست مربوط به رودمپ بکند :
Backend Roadmap
برای آخرین مورد گفتم که حتما همه‌ی بچه‌ها باید از روز اول ADR بنویسند؛ سر این موضوع با هیچ کدوم از بچه‌ها شوخی ندارم.

اما خیلی‌ها (مثل بچه‌هایی که باهاشون کار می‌کنم) پرسیدید چرا باید ADR بنویسیم بهتر نیست وقتمون رو روی کد زدن و تمرین و یادگیری بذاریم.

جواب کوتاه:
هیچ ابزار - هیچ کتاب و ... دیگری به اندازه نوشتن ADR شمارو تست نمی‌کنه و به شما یاد نمی‌ده حتی.

اما اگر توضیحات برای قانع شدن می‌خواید ادامه مطلب رو بخونید:

بخش بزرگی از کار یک مهندس نرم‌افزار (بخصوص توی سطوح بالاتر) یادگیری بحث و مناظره کردن هست؛ چیزی که توی سال‌های اخیر همکاریم با بچه‌ها توی ایران خیلی خیلی کم دیدم. این بحث‌ها اکثرا سر چه چیز‌هایی هست ؟
۱- از کدوم فریمورک استفاده کنیم
۲- با کدوم استاندارد پیش بریم
۳- دیتابیس چی بذاریم
۴- تست نویسی چطوری باشه
۵- چرا از این ابزار استفاده کنیم یا نکنیم
و ...

شما هرروز درگیر این بحث‌ها خواهید بود و اینکه بتونید از پیشنهادات خودتون بطور منطقی دفاع کنید موضوع بسیار بسیار مهمی هست.
وقتی شروع به نوشتن
ADR = Architecture Decision Records
می‌کنید یاد می‌گیرید ابزاری که دارید انتخاب می‌کنید رو همه جنبه‌هاش رو ببینید؛ خیلی وقتا ابزارهایی که افراد انتخاب می‌کنند فقط بخاطر hype هست و جو زده هست اون انتخاب بدون اینکه بدونند آیا واقعا بدردشون میخوره یا مناسب کارشون هست.
خیلی وقتا این مکالمه رو شنیدیم:

- چرا فلان ابزار رو انتخاب کردید ؟
+ گوگل داره ازین استفاده می‌کنه؛ چی ازین بهتر
آره دوست من ولی گوگل چندین میلیارد کاربر داره و تو به زور به ۵ هزارتا میرسی.
گوگل هزاران نفر توسعه دهنده داره ولی تیم تو به زور به ۱۰ نفر میرسه.
گوگل میلیاردها دلار خرج زیرساخت و دستمزد و ... میده.
تو زیرساختت به زور ۱۰۰ هزار دلار میشه.

برای خود من موقع بحث سر موضوعاتی که بچه‌ها باید یاد بگیرند برای توسعه بکند همین موضوع پیش اومد یکی از بچه‌ها گفت برای سرویس ارسال ایمیل از celery استفاده کنیم پس اینم بنویسید؛ که اگر نگاه کنید من ممنوع کردم استفاده‌اش رو celery سرویس بسیار بزرگ و سنگینی هست.
برای پروژه‌های کوچیک اشتباه هست که توی قدم اول برید سراغش؛ اما اگر کسی بتونه ADR خوب بهم بده قطعا قبول می‌کنم.

درسته وقتی تنهایی کد میزنید به ADR نیازی نیست اما نوشتنش باعث میشه یاد بگیرید بحث کنید؛ توی نوشتن ADR معمولا شما به چندتا ابزار میرسیدو باید این چیزها رو توضیح بدید :

۱- این ابزارها برای چه کاری هستند و چرا فکر می‌کنید توی پروژه لازمشون داریم ؟
۲- چرا هرکدوم از ابزارها رو در نظر گرفتید؟ (چرایی مهم هست)
۳- انتخاب شما کدوم بوده ؟ و البته چرا ؟
۴- نقاط قوت و ضعف ابزاری که انتخاب کردید چی هست ؟
۵- نقاط قوت و ضعف ابزارهایی که انتخاب نشدند چی هست؟
۶- تحت چه شرایطی ابزارهای دیگر رو انتخاب می‌کردید یا اینکه شرایط پروژه چی بود که نقاط قوت ابزار انتخابی شما به باقی موارد و البته نقاط ضعف اون چربید و انتخاب شد.

فکر می‌کنم از سوال‌ها مشخص باشه که چقدر چیز مفید و مهم رو درک می‌کنید و یاد میگرید.
آیا همه پروژه‌ها این رو دارند ؟
به جرات میگم که بیش از ۹۲-۹۳٪ پروژه‌ها و حتی شاید توسعه دهنده‌ها حتی نمی‌دونند چی هست؛ ولی تمام پروژه‌ها و تمام مدیران فنی و اعضای تیم‌هاشون هرروز درگیر یکی از این تصمیم گیری‌ها هستند.

به مدیرای فنی هم پیشنهاد می‌کنم توی تیم این موضوع رو داشته باشید؛ خیلی وقتا نیرو احساس می‌کنه حرف‌هاش شنیده نمی‌شه درصورتی که شما می‌دونید چیزی که پیشنهاد می‌کنه خوب نیست برای پروژه فقط وقت برای توضیح دادن بهش رو ندارید.
معمولا با نوشتن ADR خیلی از بچه‌ها خودشون متوجه می‌شوند که چرا جواب نه بهشون داده شده.

#Backend_RoadMap_2025
قبل از اینکه بخواید این roadmap رو دنبال کنید باید پست قبلی رو بخونید.
یک نکته‌ای که اضافه کنم؛ توی جلسات و ... که بحث شد من اصلا قرار نیست هیچ چیزی رو آموزش بدم (اشتباهات رو کمک می‌کنم حل بشه و ...) اما اینکه آموزش بدم FastAPI چیست و جطوری CRUD بنویسیم و ازین موارد با اوضاع الانم اصلا نمی‌خونه پس دلیل ساده بودنش همین پست قبلی هست.

چیزایی که توقع دارم یک Senior توی جنبه‌ی فنی بکند بلد باشه (اعداد هیچ ربطی به ترتیب یادگیری نداره؛ فقط برای این هست که تهش بدونم چندتا مورد رو گفتم) از دوستان Senior هم می‌خوام اگر نکته یا موردی جا افتاده بهم یادآوری کنند.
بازم توجه کنید Senior شدن کلی جنبه‌های مختلف داره ولی برای بخش فنی مربوط به بکند این لیست کافی و قوی هست؛ برای بحث‌های دیگر هم از منابع خودش می‌تونید دنبال کنید.

فریمورک مورد نظرتون رو کمی بشناسید (من روی FastAPI پیش میرم ولی خیلی فرقی نیست)

1. Middleware: Starlette interface for how to write middleware.
Must know: auth, request ID, timing, gzip, validators, rate-limit, logging.
Important to know the order of execution.

2. CORS (and headers in general).

3. Authentication / Authorization: What is JWT + RS256.
Nice to know: Auth0, Cognito.

4. SQL and SQLAlchemy 2.0 (async style).

5. Tests:
* Unit tests for business logic.
* Integration tests for database, Redis, etc. interactions.
* Contract tests (very important) for endpoints and services you use.

6. Benchmarking: k6, load testing, CI smoke tests for performance-sensitive endpoints; wrk, hyperfine (or alternatives).

7. Docker / Docker Compose: multi-stage builds.

8. Profiling: Scalene or Perf — flamegraph interpretation.

9. Caching (Redis): cache invalidation; GET/SET strategies (Cache-Aside vs Write-Through).

10. Background tasks:
FastAPI background tasks & Dramatiq (or other alternatives).
Don't bring Celery or its equivalent into projects — it's heavy and overkill in most cases.
Use/understand: idempotency, retries, dead-lettering.

11. Observability: Logging, tracing, metrics.
Logs must be structured (JSON is a good option).
Distributed tracing is a must-have.
Metrics (Prometheus) are important — at minimum: response_time_ms, active_connections, etc.

12. Configuration management: Pydantic Settings; no hard-coded settings or configs.

13. Migrations: Alembic — each migration should have both UP and DOWN so it is safe to revert.

14. API documentation: FastAPI provides it automatically, but don't forget to use the Pydantic model example field.
BTW: Pydantic v2 is the only accepted version.

15. Error handling + correct HTTP codes.

16. Graceful shutdown:
App must stop accepting new HTTP connections,
finish processing current requests,
drain the database connection pool,
then exit.

17. Idempotency and retries:
For network/database failures — learn exponential backoff, circuit breakers, bulkheads.

18. Health checks and readiness probes: The app must provide them (Docker health check alone is not accepted).

19. Connection pooling tuning: Postgres, Redis, etc.
You must be able to explain tuning decisions based on your benchmarks/profiling results.

20. Security basics: Input sanitization/validation, rate limiting, secrets management, secure defaults (CSP, HSTS), threat modeling for endpoints.

21. Scalability patterns: Focus on connection pooling and indexing first.
Too many or unnecessary indexes = Fail.
Nice to learn: horizontal scaling, load balancing, sharding, replication.

22. Feature flagging (dynamic configuration): All projects should have it — very important.

23. API versioning strategy: Header versioning / URL versioning.

24. Architecture Decision Records
From day 1 you must have this document in the project with at least 3 entries per decision:
What you decided.
Why you did that.
What the consequences are.
--————————————-
Future / next steps

1. Design system architecture.
2. Integrate message queues (when and why to use them) — Kafka, RabbitMQ.
3. Event-driven patterns.
4. Optimize for latency.
5. GraphQL / gRPC — when and why to use them.

پینوشت: اگر جایی کپی کردید؛ لطفا پیام قبلی و بعدی رو هم بذارید 🌱
توضیحات مهم هست.

یکی به من پیام داده، توهین نکرده ولی خوبم صحبت نکرده:

همه چیز رو سخت می‌کنی الکی،
من ۶ ماهه بعنوان برنامه‌نویس شروع به کار کردم
نه این کتابارو خوندم، نه چیزایی که تو کانال pyhints گفتی رو بلدم.
ولی همه‌ی کارامم دارم انجام میدم
با دوره فلانی هم همرو یاد گرفتم، برو ازون یادبگیر همه چیز رو ساده می‌گیره

مکالمه من :

+ شرکت و پروژه شما چندتا برنامه‌نویس و چقدر کاربر داره ؟
- ۱۱ نفریم، ۲۰۰۰ تا هم کاربر داریم.

+ حقوق شما چقدر هست ؟
- حدوداً ۲۳م

+ هروقت شرکتی ایرانی با تورم امروز قبول کرد بابت کاری که می‌کنی بهت حداقل ۶ برابر یا بیشتر حقوق بده، اون موقع متوجه شدی که چرا کتاب خوندی و مفاهیم رو فهمیدی.

اما اگر بخوام برای همه توسعه دهنده‌های دیگر توضیح بدم؛ باید با این جمله که همیشه به بچه‌های توی تیمم می‌گم شروع کنم :

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

به خیلی از تکنولوژی‌های امروز فکر کنید؛ اگر نخوندید برید ببینید همشون از دل مشکلات در اومدند
Hadoop, Kafka, Spark, Docker, K8s, ...

قرار نیست همه چیز رو یاد بگیرید؛ تک تک تکنولوژی‌ها و نحوه کانفیگ اون‌ها و ... اما قرار هست آماده باشید که قبل از بروز مشکل بتونید اون رو پیدا کنید و سیستم رو ارتقا بدبد براش.

مثال بزنم :
چند مدت پیش یک توسعه دهنده بر اساس یکی از انیمیشن‌ها یک سایت خیلی ساده نوشته که یک مارمولک وسط صفحه هست و وقتی روی اون کلیک می‌کنی می‌گه Lizard
بعد خیلی معروف شد و ملت درخواست دادند counter جهانی براش بسازه

ببین دیگه ازین اپلیکیشن ساده‌تر و بی‌خطر تر وجود نداره؛ نه تراکنش مالی داره و نه یوزر پولی داده و نه هیچی ...

طرف اول همه درخواست‌ها رو توی فایل می‌ریخته؛ سایت دان میشه
همرو میریزه توی دیتابیس؛ سایت کند میشه (تعداد req/sec بیش از حد بالا بوده)
شروع می‌کنه سرورهای بزرگتری رو خریدن؛ از ۴ دلار به ۶۰ دلار میرسه هزینه ماهانه سرور ولی مشکل همچنان پا برجاس و مسئله این بوده که با این مفهوم که write های کوچیک و زیاد روی دیتابیس داره بهش آسیب میزنه آشنا نبوده.

چون مشکل رو نمی‌شناخته؛ سراغ راه حل اشتباه رفته.

درنهایت بر می‌گرده و شروع به optimize کردن کد می‌کنه؛ الان سایت روی همون هاست ۴ دلاری بالاس و تا این لحظه

2,146,829,700

کلیک رو ثبت کرده (البته خیلی از کلیک‌ها رو از دست داده)

ایشون وقتی تونست راه‌حل رو پیدا کنه که دیگران مشکلاتش رو بهش گفتند؛ اگر این یک بیزینس خصوصی با کاربرای واقعی بود سرور 5,000 دلاری هم نجاتش نمی‌داد (چون راه اشتباه بود) و امکان داشت با وجود هزینه بسیار بالا بهترین مشتری‌هاش رو هم از دست بده.

شرکت‌هایی با محصولات خوب اینطوری از دور خارج می‌شوند؛ من شاهد این موضوع بودم (حداقل ۱۰ نفر شما برای سورس کد پروژه‌های شرکت‌هاتون من رو دعوت به همکاری دادید تا مشکل حل کنم و خب به هر دلیلی با مدیرعامل به توافق نرسیدیم)‌

توی تمام کانال‌ها من هدفم آموزش مقدمات نیست (البته غیر از Rust که خودم داشتم Syntax یاد می‌گرفتم)‌ بلکه هدفم این بوده که شما حداقل یک بار هر مشکلی رو ببینید و اگر اون الگو رو توی کار واقعی دیدید بتونید قبل از down شدن سرویس‌ها شناساییش کنید.

وگرنه برای یادگرفتن یک framework فقط ۲-۳ ساعت آموزش کافی هست.

راستی اون سایت هم :
https://lizard.click/