Python Hints
前往频道在 Telegram
Python tips and tricks The Good, Bad and the Ugly توی این کانال فقط قرار هست در مورد core python صحبت کنیم. این کانال یک بلاگ شخصی هست و پیرامون نظرات و چیزهایی که توی بیش از ۱۰ سال کد زدن یاد گرفتم (فقط برای کمک به دوستان تازهکار) Admin: @Abbasi_ai
显示更多📈 Telegram 频道 Python Hints 的分析概览
频道 Python Hints (@pyhints) 波斯语 语言赛道中的 是活跃参与者。目前社区聚集了 10 095 名订阅者，在 技术与应用 类别中位列第 11 614，并在 伊朗 地区排名第 30 613 位。
📊 受众指标与增长动态
自 невідомо 创建以来，项目保持高速增长，吸引了 10 095 名订阅者。
根据 22 九月, 2026 的最新数据，频道保持稳定运转。过去 30 天订阅人数变化为 144，过去 24 小时变化为 1，整体触达仍然可观。
- 认证状态： 未认证
- 互动率 (ER)： 平均受众互动率为 27.47%。内容发布后 24 小时内通常能获得 14.42% 的反应，占订阅者总量。
- 帖子覆盖： 每篇帖子平均可获得 2 773 次浏览，首日通常累积 1 456 次浏览。
- 互动与反馈： 受众积极参与，单帖平均反应数为 81。
- 主题关注点： 内容集中在 ᴘʀᴏxʏ, کانفیگ, مورد, shift, ابزار 等核心主题上。
📝 描述与内容策略
作者将该频道定位为表达主观观点的平台：
“Python tips and tricks
The Good, Bad and the Ugly
توی این کانال فقط قرار هست در مورد core python صحبت کنیم.
این کانال یک بلاگ شخصی هست و پیرامون نظرات و چیزهایی که توی بیش از ۱۰ سال کد زدن یاد گرفتم (فقط برای کمک به دوستان تازهکار)
Admin: @Abbasi...”
凭借高频更新（最新数据采集于 23 九月, 2026），频道始终保持新鲜度与高覆盖。分析显示受众积极互动，使其成为 技术与应用 类别中的关键影响点。
10 095
订阅者
+124 小时
+237 天
+14430 天
数据加载中...
吸引订阅者
九月 '26
九月 '26
+108
在0个频道中
八月 '26
+274
在0个频道中
Get PRO
七月 '26
+277
在3个频道中
Get PRO
六月 '26
+289
在2个频道中
Get PRO
五月 '26
+187
在1个频道中
Get PRO
四月 '26
+97
在0个频道中
Get PRO
三月 '26
+32
在0个频道中
Get PRO
二月 '26
+131
在1个频道中
Get PRO
一月 '26
+455
在19个频道中
Get PRO
十二月 '25
+175
在5个频道中
Get PRO
十一月 '25
+138
在1个频道中
Get PRO
十月 '25
+152
在0个频道中
Get PRO
九月 '25
+220
在1个频道中
Get PRO
八月 '25
+305
在3个频道中
Get PRO
七月 '25
+232
在4个频道中
Get PRO
六月 '25
+188
在6个频道中
Get PRO
五月 '25
+196
在4个频道中
Get PRO
四月 '25
+171
在3个频道中
Get PRO
三月 '25
+299
在4个频道中
Get PRO
二月 '25
+276
在9个频道中
Get PRO
一月 '25
+258
在3个频道中
Get PRO
十二月 '24
+373
在4个频道中
Get PRO
十一月 '24
+410
在2个频道中
Get PRO
十月 '24
+454
在7个频道中
Get PRO
九月 '24
+382
在5个频道中
Get PRO
八月 '24
+572
在7个频道中
Get PRO
七月 '24
+382
在8个频道中
Get PRO
六月 '24
+285
在4个频道中
Get PRO
五月 '24
+307
在1个频道中
Get PRO
四月 '24
+815
在5个频道中
Get PRO
三月 '24
+537
在6个频道中
Get PRO
二月 '24
+461
在5个频道中
Get PRO
一月 '24
+580
在6个频道中
Get PRO
十二月 '23
+599
在2个频道中
Get PRO
十一月 '23
+106
在1个频道中
Get PRO
十月 '23
+223
在1个频道中
Get PRO
九月 '23
+123
在0个频道中
Get PRO
八月 '23
+158
在0个频道中
Get PRO
七月 '23
+89
在0个频道中
Get PRO
六月 '23
+221
在0个频道中
Get PRO
五月 '23
+1 677
在0个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 23 九月 | 0 | |||
| 22 九月 | +1 | |||
| 21 九月 | +10 | |||
| 20 九月 | +4 | |||
| 19 九月 | +4 | |||
| 18 九月 | 0 | |||
| 17 九月 | +3 | |||
| 16 九月 | +10 | |||
| 15 九月 | +4 | |||
| 14 九月 | +5 | |||
| 13 九月 | 0 | |||
| 12 九月 | +8 | |||
| 11 九月 | +1 | |||
| 10 九月 | +2 | |||
| 09 九月 | +5 | |||
| 08 九月 | +13 | |||
| 07 九月 | +3 | |||
| 06 九月 | +1 | |||
| 05 九月 | +7 | |||
| 04 九月 | 0 | |||
| 03 九月 | +11 | |||
| 02 九月 | +10 | |||
| 01 九月 | +6 |
频道帖子
| 2 | At its peak, Python helped us serve more than 20 million requests every second.
تیم مهندسی openai یک مقاله داده در مورد یک لایبراری برای دسترسی سادهتر به دیتابیس که با پایتون روز اول نوشته شده بوده و بعد به سرویس پایتون تبدیل شده و نشون داده با طراحی درست سیستم تا ۲۰ میلیون درخواست رو داشتند باهاش هندل میکردند.
البته توی این مقاله راجب تصمیم برای سوییچ کردن به Rust صحبت شده ولی کل مقاله رو اگر بخونید از ابتدا درمورد مزایای استفاده از پایتون برای اینکار هست؛ پیشنهاد میکننم حتما این مقاله رو بخونید (پارت دوم هم داره که scale اش رو میگه)
علاوه بر اون برای دوستان علاقمند پیشنهاد میکنم حتما مقاله مربوط به Postgres رو هم بخونید بخصوص اگر توی تیمی هستید که از روز اول Shard کردن رو دوس داره.
How we adapted our application storage platform, Habitat, in Python to manage unprecedented growth. (Part 1)
Scaling PostgreSQL to power 800 million ChatGPT users | 2 208 |
| 3 | @pyhints
انقدر محبوب و معروف شده که پیشنهاد اسپانسر و تبلیغات دلاری براش داره میاد؛ توی تمام این سالها هیچکدوم از کانالها تبلیغات نداشته و ترجیح میدم این روند رو ادامه بدم.
اما باید از تمام دوستانی که این مدت همراه کانال بودند و مطالب رو به اشتراک گذاشتند هم تشکر کنم.
بابت همراهی شما با تمام کانالها و تمام این سالها ممنونم
@pyhints
@pytens
@pyrust
@per3onnel | 3 947 |
| 4 |  داشتم دنبال یک ویدئو میگشتم که ببینم کسی ماژولهای مهم رو برای پایتون توضیح داده ؟
یک بخشی از داکیومنت رو خوندم و فهمیدم ماژول چیزی هست که دنبالشم و توی این سرچ متوجه شدم ۳ سال قبل با این ابزار آشنا شدم؛ یا اون موقع بدردم نمیخورده یا پروژههام همه رو اسکریپت بوده و کار میکرده یا ایراداتی داشته که نتونستم استفاده کنم.
خواستم این نکته رو هم اضافه کنم که :
هرچیزی به زمانش و به وقت نیاز بهش خوبه؛ چیزی که امروز خیلی راجبش هیجان دادم و خوشم اومد از پیدا کردنش
۳ سال قبل (کل ویدئو رو دیده بودم) هیجان زدم نکرده شاید به این فکر کردم که خودم با اسکریپت دارم همینکارو میکنم دیگه باقیشم که .env و پایتون انجام میده
امروز نیاز و نگاهم عوض شده
اگر جونیور هستید و توی تیم میخواید ابزار جدیدی رو پیشنهاد بدید یادتون باشه باید نشون بدید :
۱- این ابزار جایگزین روش قبلی هست
۲- جایگزین کردن ابزار قدیم چقدر هزینه داره (یادگیری نیروهای دیگه هم در نظر بگیرید)
۳- مزیتهاش چیه
که بازم بر میگرده به یکی از مهمترین چیزایی که قبلا گفتم حتما یاد بگیرید یعنی نوشتن ADR اونم صادقانه هم مزایا و هم معایب | 5 809 |
| 5 | این دقیقا یکی از اون جاهایی هست که گفتم نیروی جونیور توی تیم لازم هست.
مسئله این هست که من اسکریپتهام و راهاندازی کانتینر dev برای ابزارها و کانفیگشون با اسکریپت و ... رو شاید ۱-۲ ماه بعد از یادگیری داکر (اوایل معروف شدن) شروع کردم همین امروز هم اگر تنبلی باعثش نبود عمرا همچین چیزی رو سرچ نمیکردم.
حتی اگر احمق بودن بیش از حد LLM ها نبود هم اینکار رو نمیکردم؛فیچرهایی که خواستم تست کنم جدید بود و البته چون نمیدونستم رفتار درست ابزارها روی فیچرهای جدید چی هست و چطوری عمل میکنه اعتمادی به LLM برای نوشتن این اسکریپت نداشتم دلیلش هم واضح هست :
از کجا بفهمم خطا توی کدم هست؛ یا توی اسکریپت LLM یا حتی اون فیچر رو اشتباه درک کردم یا اشتباه استفاده کردم و ...
این باعث شد سرچ کنم و testcontainers رو پیدا کنم؛ من همیشه محیط تست و توسعهام یکی هست همه چیزش.
روی پروداکشن هم سرور dev, stage و prod همیشه یکسان کانفیگ میشه حتی تا سطح دسترسی و جزئیاتی مثل firewall , ...
فقط تفاوت این میشه که مثلا prod با ۱۰ تا سرور میاد بالا dev با ۱ سرور و stage با ۳ تا سرور اگر جنبه distribute بودن چیزی باشه که برامون مهم هست تست شدنش.
خلاصه اینا معمولا دانشی هست که یک جونیور خوب به تیم اضافه میکنه؛ توی جلسات هفتگی یا حتی ماهانه راهکارهای جدید و به روز شده رو جونیورها معمولا به تیم اضافه میکردند وگرنه من و مثل من که ۱۰ سال هست یک راهکار رو دنبال میکنیم و همیشه جواب داده چرا باید دنبال راه دیگهای بگردیم ؟
جونیورهای تیم رو نگه دارید؛ چونیور درست و خوب تیم رو آپدیت نگه میداره. | 4 758 |
| 6 | من همیشه دیتابیس تست و ... رو براش اسکریپت مینویسم (دستی) بعد توی کدهام از اون موارد استفاده میکنم کار تمیزی هست ولی زمانبر
الان همینطوری یک سرچ زدم آنلاین ببینم روش دیگری هست ؟
پروژهای که دستم هست خیلی سادهاس و فقط میخواستم چندتا فیچر جدید رو هم تست کنم اینکه یک سری اسکریپت دقیق بنویسم و کانفیگ کنم بنظرم زیاد بود
testcontainer
رو پیدا کردم که بنظر میاد دقیقا برای همچین وقتایی هست گفتم معرفی کنم برای دوستان دیگری که مثل من شاید نیازشون باشه و راجب این پروژه چیزی نشنیده باشند. | 3 751 |
| 7 | اینم برای دوستان دانشجو یا علاقمندای به
Data Structure & Algorithm
این سایت با انیمیشن بهتون نحوه کار هر اگوریتم رو نشون میده (برای دانشگاه سنگاپور هست) و برای هر کدوم :
۱- کوئیز داره (نمره نداره یک سری سوال رندم برای درک میزان یادگیری هست)
۲- یک بخش پرینت داره که خلاصهی کامل رو بهتون میده مثل یک cheat sheet که توی چند مورد که من خوندم خیلی خوب و درست نوشته شده.
خلاصه این رو روزی ۱ بار بهش سر بزنید. | 2 943 |
| 8 | داشتم داستان ۲ هفته troubleshoot کردنم برای یک شرکت رو مینوشتم و اینکه ۷ نفر قبل من رفته بودند و راهکاری پیدا نشده بود.
حتی بهشون جابجایی استک پایتون رو هم پیشنهاد داده بودند.
و حتی اینکه خرید سرور تا ۳ برابر قویتر هم کمکی نکرده بود.
که سیستمم خاموش شد (نوسان برق)
خلاصهاش رو بگم،
تیبل refresh token رو براش بکگراند جاب بنویسید تمیز کنه.
که اگر یکی refresh token رو اشتباهی گذاشت روی 1 ساعت و ۵ میلیون یوزر داشتید
توی چندین ساعت تیبل بزرگ نشه، شما اون باگ رو توی ۳ ساعت بعدش حل میکنید
ولی ماها بعد حجم اون تیبل چندین برابر میشه و سرچ کردن توش تمام کوئریها رو کند میکنه و میشه چیزی که نباید بشه و خفت میشید.
تقریباً داشتم از پیدا کردن راهکار ناامید میشدم که مشکل رو پیدا کردم.
پینوشت:
۱- دسترسی گرفتن به سرور پروداکشن سخت بود، شاید تنبلی شایدم هرچیز دیگری نفرات قبلی اینکار رو نکرده بودند.
۲- من بعد از اطمینان از کد و البته تست لود و پروفایل روی سرور dev مطمئن شدم باید روی پروداکشن دنبالش بگردم
۳- حتی فکرشم نمیکردم مشکل از refresh باشه چون کد تغییری نکرده بود (۱ سال این بخش کدها دست نخورده بود، گیتلاگ) و البته آخرین تغییر فایل .env روی سرور هم برای ۷ ماه قبل بود ولی مشکل ۲ ماه پیش شروع شده بود.
۴- اگر سوال پیش اومد چرا refresh رو توی دیتابیس داریم در مورد jti, family id توی jwt بخونید. | 4 252 |
| 9 | بنظرم ویدئوهای کنفرانس امسال خیلی کم داره دیده میشه
PyData Youtube | 4 460 |
| 10 | یک آپشن روی sqlalchemy برای relationship هست که شخصا خیلی دوسش دارم؛ باعث میشه به کوئری که سمت دیتابیس میفرستم فکر کنم بجای اینکه سادهترین راه رو انتخاب کنم.
هرجا هم که نیاز دارم دولوپرها به کوئریهاشون دقت کنند حتما ازش استفاده میکنند.
lazy = "raise"
الان داشتم خروجی پروفایلینگ یک پروژه رو نگاه میکردم؛ توی RandRng گفتم راجبش.
دیدم خیلی کوئریهای دیتابیس زمان بر هست؛ ی سرچ توی مدلهای دیتابیس زدم و همهی relationship هارو بهش؛
lazy = "raise"
اضافه کردم؛ تا دلتون بخواد ارور میگیریم حالا ولی باعث میشه همه به کوئریهاشون فکر کنند.
گفتم اینجا هم بذارم شاید بدرد کسی خورد. | 5 480 |
| 11 | این ترکیب به راحتی میتونه خیلی از پروژهها رو از Postgres به Sqlite منتقل کنه؛
Sqlite + Litestream
توی خیلی پروژهها برای خودم پیش اومده که یک دیتابیس نیاز داشتم؛ شاید ۵-۱۰ تا جدول ولی اینکه فقط روی یک سرور نباشه هم برام مهم بوده که خب سرویسهای کلاد رو استفاده میکردم.
همزمان هم Latency میرفت بالا هم کلی هزینه پرفورمنس واسه سربارهایی کار کردن با Postgres میدادم درحالی که به ۹۰٪ اون ویژگیها نیازی نداشتم.
الان داشتم دنبال یک راهکار برای یک پروژه دیگه میگشتم و واقعا دلم نمیخواد Latency و Throughput ام بخاطر استفاده از Postgres کم بشه و بعد بشینم اپتیمایز کنم. بخصوص اینکه این دیتابیس هیچ دیتای حساسی نداره و فقط همین که دیتاها از بین نره برام مهم هست.
به چندتا راهکار رسیدم که بنظرم این ترکیب برای کار من برنده هست بخصوص اینکه RustFS رو همین الان داریم :
Turso + Litestream + Rustfs
بعد از پروژه یادم باشه نتایجش رو هم میذارم. | 5 766 |
| 12 | اینو یادداشت کرده بودم که بذارم:
تقریبا ۱.۵ سال پیش یک پروژهای روی یک پروژهای کار میکردم (فکر کنم گفتم جزو معدود پروژههایی بود که از اول توی پروژه بودم)
امشب با مدیرعامل شرکت و صاحب پروژه صحبت میکردم (شاید پروژه دوم) میگفت علاوه بر دولوپرهای بعدی ادمین دیتابیس هر چندوقت یکبار که روی دیتابیس کار میکنه ی دمش گرم هم به ما میگه.
من استانداردهای زیادی رو رعایت کردم روی اون پروژه ولی این ۵ خط بنظر میاد خیلی بچههایی که روی دیتابیس کار میکنند رو راضی نگهداشته
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",
}
)
من همیشه اینکار رو برای خودم میکنم که توی همه پروژههام یک استاندارد رعایت شده باشه و راحت بتونم دیباگ کنم و بخونم؛ خلاصه برای راحتی خودم هست.
این حرفا رو که امشب شنیدم گفتم بذارم شما هم توی پروژههاتون رعایت کنید.
امیدوارم مفید باشه | 4 633 |
| 13 | Background jobs
رو توی دو مرحله پیادهسازی کن
مرحله اول رو با خود
Fastapi
پیاده سازی کن ببرش زیر لود تست بعد ببین چه اتفاقی میوفته
ADR-0015
رو نمیدونم چی هست ولی اینکه بدونی تا چه زمانی از خود
Fastapi
میتونی استفاده کنی خیلی مهمه بعدش برو روی Dramatiq
——————
Auth
رو با
Argon2
هم چک کن (خیلی واجب نیست فقط برای اینکه بهش آشنا باشی)
————————
برای متریک
prometheus_client
استاندارد اصلی هست
————————
چندتا چیز دیگه که بهتره اضافه کنی :
۱- لاگ رو وقتی با structlog زدی بعدش باید قابل خوندن و تحلیل هم باشه اما لزوما این کار رو روی سروری که اپ لانچ هست ممکنه انجام ندی :
پس یک چیزی برای جمع کردن لاگ همه اپها لازم میشه (توی پروداکشن معمولا) یک نسخه خیلی خوب و سبک و عالی :
https://vector.dev/
هست
۲- نمایش همه اینها؛ خیلی وقتا لاگ - تریس - متریک جمع میکنیم ولی تا وقتی آنالیزش نکنیم نمیدونیم درست هست یا نه
https://grafana.com/
گرافانا برای این وقتا خیلی خوبه (البته نیازی نیست ساخت داشبورد و ... توش رو یاد بگیری اون کار تیمهای دیگهاس)
ولی همین که ببینی دیتات توی این داشبورد چطوری نشون داده میشه نکته خوبی هست
پینوشت:
اگر از نظرت مشکلی نداره plan رو بذارم تو کانال به اسم خودت.
بعنوان نمونه اگر کسی خواست انجام بده | 3 774 |
| 14 | #Backend_RoadMap
#Sample_Project
زحمت این فایل رو شایان عزیز کشیده (با استفاده درست از AI) و توی گروه گذاشت من چندتا نکته رو اضافه کردم و با اجازهاش گفتم بعنوان نمونه اینجا منتشر کنم | 3 181 |
| 15 | یادآوری :
https://t.me/pyHints/423 | 3 531 |
| 16 | #Quick
from pydantic import SecretStr
لطفا ازین مورد استفاده کنید؛ نشستم لاگ سرور یک پروژه رو میخونم تمام اطلاعات سرور و اطلاعات کاربراش خیلی زیبا و خوانا توی لاگ هست.
قبلا هم یک موردی رو توی
@pyhints
یاد دادم برای لاگ نویسی موارد مهم.
لطفا از هر دو استفاده کنید؛ هیچ چیز مهمی نباید توی لاگ نوشته بشه.
بخصوص ایمیل و شمارهتماس کاربر. | 2 845 |
| 17 |  LLM
قراره جای برنامه نویسهارو بگیره ؟
من که کدم رو + دستورالعمل ریفکتور دادم تا برام تمیز کنه و خروجی که توی تصویر هست
نصف باگهای مدلهای LLM رو من درآوردم باید بهم هزینه پرداخت کنند واقعا
پینوشت:
تازه ۳۵ دقیقه هم طول کشید. خودم میزدم ۲۰ دقیقهای تموم میشد. | 4 332 |
| 18 | گزارش تیم مهندسی یکی دیگه از شرکتها برای سالی بین ۲۰۲۳-۲۰۲۵ توی اون رنج بود که شرکت خیلی خیلی بزرگی هم هست و تعداد درخواستهاش تازه به ۵۰۰۰ رسیده
توی دوران جنگ اخیر توی گروه گذاشتم ولی متاسفانه الان پیداش نکردم؛ حتما اگر پیدا کردم اون مورد رو هم اضافه میکنم.
ولی بنظرم همین مورد Stackoverflow هم مورد به اندازه ملموسی هست برای درک این موضوع.
خلاصه مشکل سواد و معماری هست؛ نه فریمورک و زبان برنامهنویسی | 5 788 |
| 19 |  تا ۱۰۹ هزار درخواست در ثانیه رو میتونه جواب بده روی این بچمارک من اگر سرویسم به ۶۰۰۰ درخواست در ثانیه هم برسه یک چیزی در حد Stackoverflow هستم (بر اساس مصاحبه Roberta Arcoverde میگم)
برای تعجب بیشتر شما؛ توی مصاحبه به monolithic بودن معماری سیستم اشاره میشه و البته به اینکه on-permise هم هست.
اگر کار نیاز به صفحه ادمین و استانداردهای خارج از مایکروسرویس داشته باشه و تیم کوچیک باشه ۱۰۰٪ میرم سراغ جنگو.
عکس دوم هم از اینجا اومده و برای websocket هست
۱۰ هزار کانکشن با حجم دیتای ۱ کیلوبایت تعداد درخواست حداقل ۲۰ هزارتا (تازه روی fastapi که میگن برای وبساکت با حجم بایت بالا خوب نیست)
چیزایی که زیاد میبینم :
آدما هیچ درکی از معماری مونولوتیک و میکروسرویس ندارند و یکی رو میزنند؛ اینم بگم رندر صفحات استک اورفلو توی ۱۲ میلی ثانیه هست.
برید مصاحبه رو ببینید واقعا
آدما هیچ درکی از تعداد درخواست در ثانیه ندارند و زرتی عدد ۱ میلیون درخواست در ثانیه رو تو مصاحبه و ... اینور و اونور پرت میکنند
آدما هیچ درکی از هیچکدوم ندارند و حتی توانایی فهمیدن کد رو هم ندارند و فقط فریمورک پروژه رو میخوان عوض کنند 🤬🤬 | 5 173 |
| 20 |  یکبار برای همیشه؛ زرتی نرید استک بکند رو عوض کنید تا تعداد درخواستهاتون به ۵۰ تا در ثانیه رسید.
اگر سرویس بکند شما نمیتونه این تعداد درخواست رو جواب بده مشکل شما پایتون نیست؛ مشکل شما سواد هست.
واقعا خسته شدم طرف تعداد درخواست در ثانیهاش به ۳۰ تا هم نمیرسه میگه ما باید به 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 هست. | 4 384 |
