وب سوکت/سوکت پایتون

سلام دوستان
یه راهنمایی برای استفاده از وب سوکت تو پروژه وب پایتونی میخاستم …

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

بین این دوتا autobahn (پروژه خیلی باسابقه و کار کشته ای هست . بر اساس twisted ایجاد شده اما asyncio هم میتونه استفاده کنه) و websocket(روی asyncio بوجود اومده) مردد هستم …

و اینکه … اگه این پروژه هارو ک اسینک هستن و الگوی non-blocking i/o دارن … همراه با یه فریم ورک سینک و دیتابیس ریلیشنال و ormهایی مثل sqlalchemy/peewee استفاده کنم … احتمال block شدن نداره ؟؟؟‌

ممنون میشم تجربیاتتونو در اختیار بزارید …

پ.ن: متاسفانه falcon هنوز وب سوکت نداره … و in progress هست وب سوکتش …

پ.ن : گاهی این حد از تنوع و creativity اذیت میکنه :man_facepalming: هرکی یه طرف برا خودش لایبرری توسعه داده :smile:

1 پسندیده

در مورد اون کتابخونه ها اطلاعات ندارم . اما یکی از بزرگتری مشکلات فریم ورک هایی مثل Django و Rails و سایر وب فریمورک های بزرگ از نظر من مدل concurrency اونها بوده. و چون از async response به صورت پیشفرض پشتیبانی نمی کنن مجبور می شی بلاک کنی که خوب جالب نیست. هک هایی هم که برای این کار می شه انجام داد عموما اونقدری جالب نیست که بخوای ازشون استفاده کنی. شخصا در نهایت از این ابزار ها برای اینچنین موارد استفاده ای دیگه استفاده نمی کنم.

فکر می کنم شما هم این کارو بکنی بهتر باشه.

1 پسندیده

ممنون سمیرجان بخاطر پاسخ خوبت …

پس شما برای موارد اسینک و سوکت … سرور جداگانه راه اندازی میکنید ؟؟

1 پسندیده

کلا استک async استفاده می کنم. همه چی async هست و سرویس هام با یه سری queue باهم در ارتباط هستن.

2 پسندیده

می تونی مثلا به جا Django از httpio استفاده کنی.

1 پسندیده

اخه استک اسینک برای همه چیز ؟؟.
الان مثلا من میتونم tornado یا sanic بزنم … وب سرور built-in دارن و خالص اسینک هستن …
ولی هندل کردن پروژه فول اسینک هم مشکله … هم اینکه همه جا نیازی بهش نیست …

و اینکه مثلا میکروفریم ورکی مثل فالکون رو با اینکه sync هست … اما توی بنچمارک … خیلی از تورنادو و اسینک ها بالاتره . .بخاطر پرفورمنس … و مخصوص apiزدن درست شده …

میکروفریم ورک و سرور async زیاد داریم تو پایتون … یه نمونه خیلی جدید و قدرتمندش uvicorn هست ک نقطه مقابل gunicorn درست شده . .

1 پسندیده

به نظر من پرفرمنس فقط یه فاکتور هست. و فاکتور های دیگه ای هم برای انتخاب استک و اینا هستش.
برای مثال اینکه چه قدر راحت می تونی اسکیل کنی یا اگه تیم بزرگ شه کار کردن با این نرم افزار به چه شکل خواهد بود. یا مثلا Fault tolerance بودن مخصوصا در مورد خطاهای انسانی و خیلی چیزای دیگه.

اما در کل هر استک و هر تکنولژی هزینه ای داره و مورد استفاده ای. مثلا استک های اسینک هزینه بالایی دارن و به درد کارهای معمولی نمی خورن اما در عوض بشدت به درد نرم افزار های توضیع شده می خورن.

1 پسندیده

راستی اقا سمیر. . تو حیطه ای شما استفاده میکنید … تمام تکنولوژی های اسینک براش موجوده ؟؟
مثلا درایورای اسینک دیتابیس … odm/ormها … لایبرری ها …

مثلا برای پایتون … یه درایور خیلی خفن برای پستگری بصورت اسینک بوجود اومده asyncpg ولی لایه ormای نداره … باید کوئری بزنیم …

با مشکلات نبود ورژن اسینک یا ناقص بودنشون تو استکتون چطور کنار میایید ؟

1 پسندیده

من تو زمینه دیتا بازار سرمایه کار می کنم. و استکی که دارم async هست. با چیز خواصی مشکلی نداشتم بیشتر زمانم رو طراحی کل سیستم رفت که مجبور شدم چند تا کتاب بخونم و یه سری prototype بسازم. البته کتابخونه اصلی کل سیستم رو هم مجبور شدم بسازم که الان متن باز منتشرش کردم و زباد روش کار می کنم.

hellhound.io

حجم زیادی از کل سیستم با Clojure نوشته شده. به صورت کلی از یه ساختار مثل Commander Pattern استفاده می کنم. یه سری کامپوننت async سیستم کلی رو میسازن که توضیع شده هستند و با استفاده از stream های Kafka باهم در ارتباط هستن.

برای دیتا بیس هم با استفاده از همون HellHound و درایور های رسمی دیتابیس ها یه روند async رو ساختم. دیتابیس هایی هم که دارم. Cassandra و Neo4j هستند.

در کل در طراحی این سیستم خیلی از Event Sourcing و CDC استفاده کردم. اما کلا async هست و با Mesos مدیریت می شه که با توجه به stateless بودن و async بودنش به شدت scalable هست.

3 پسندیده

این یادم رفت چون کلوژر خیلی data oriented هستش کلا ORM خیلی معنا نداره واسش عموما از کتابخونه هایی استفاده می شه که تو نوشتن کوئری کمک می کنه اما در نهایت کوئری رو باید بسازی خودت

2 پسندیده

برای websocket هم از Aleph استفاده می کنم که هم خیلی سریع هست و هم با استکم سازگاری داره.

2 پسندیده

عالی بود . حسابی انرژی بخش و پرمحتوا :relaxed::+1:

منم همین الان به gevent-websocket برخوردم … ک با gunicorn و استک sync سازگاره و این قسمت رو روی یه ترد دیگه اجرا میکنه …

فقط یه سوالی … دیتا اورینتد بودن مگه جلوی خطاها و آورهد ها و ناامنی کوئری خالص رو میگیره ؟ :thinking: من با کوئری زدن مشکلی ندارم … اما مسئله تامین ایمنی دستی … خیلی مشکل و دردسرها داره

1 پسندیده

نه منظورم از data oriented این نبود. تو Clojure همه چی رو سعی می کنن با دیتا استراکچر های موجود پوشش بدن. مثلا حتی خود سورس کد هم یه سری لیست تو در تو هست. اما کلا چون ابجکت و کلاس و اینا وجود نداره ORM هم معنی نداره براش.

2 پسندیده

در این مورد شاید بد نباشه به روش پیاده سازی system های HellHound یه نگاه بندازی شاید از همون روش بتونی برای پیاده سازی یه سیستم async برای پایتون استفاده کنی

1 پسندیده

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

1 پسندیده

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

هر نرم افزار یه hashmap داره به اسم سیستم که از یه سری کامپوننت تشکیل شده. هر کامپوننت یه hashmap هست که یه اسم داره یه فانکشن start و یه فانکشن stop و یه سری چیزای دیگه که اجباری نیستن. کامپوننت ها ممکن هست به هم dependency داشته باشن. اما هر کامدوننت یه استریم ورودی و یه استریم خروجی داره. وقتی سیستم استارت می شه همه کامپوننت ها رو با صدا زدن start اجرا می کنه بعد با توجه به workflow ای که تو سیستم تعریف شده ( در واقع یه تعریف گراف ساده هست ) ورودی و خروجی این کامپوننت های رو بهم وصل می کنه. اینجوری همه چیز async هست. و هیچ کامپوننتی لازم نیست بدونه دیتای ورودی از کجا داره میاد و به کجا می ره تا زمانی که spec ( یه کتابخونه کلوژر برای ساختن دیتا specification هست ) ورودی و خروجی با اون چیزی که انتظار داره بخونه کار می کنه. از طرف دیگه هم سیستم رو می شه به راحتی توضیعش کرد. مثلا چندتا کامپوننت رو یه نود باشن چندا جای دیگه و …

اما نکته مهم هم اینه که به صورت پیش فرض هر کامپوننت روی ترد خودش اجرا می شه و این امکان هست که یه thread pool یا service executor برای هر کامپوننت مشخص کنی که باعث می شه کنترل بهتری رو parallelism داشته باشی.

استریمهایی هم که استفاده می کنم یه abstraction خیلی خوب هست که به بیشتر استریم های شناخته شده JVM وصل می شه با این حساب راحت مثلا می تونی از kafka streams استفاده کنی بدون اینکه نگران چیزی باشی.

هر کامپوننت هم state خودش رو به صورت immutable نگه می داره.

3 پسندیده

بسیار عالی واقعا استفاده کردم …

و اما بعضی ضعف های پایتونی: )
مثلا یکی از ضعف ها توی پایتون . اینه ک تقریبا همه چیز mutable هست … برای immutable . باید از collection استفاده بشه … و همینطور ساپورت الگوی فانکشنال به چند متد map / filter / reduce/ lambda محدود میشه …

فانکشنال بودن و ایمیوتیبلیتی تاثیر به سزایی توی کانکارنسی و پاراللیسم داره … وگرنه عین جاوا باید یه VM و GC هیولا باشه تا از data racing و overhead جلوگیری کنه … ک عمده مشکلات پایتون بخاطر refrence counting هست … ک یه GC درستو حسابی از اول روش نزدن … و بعد ک کدبیس بزرگ شد … مجبور شدن کاری کنن ک پایتون نتونه مالتی ترد باشه (GIL)

یک سری لایبرری ها داریم ک الگوی فانکشنال دارن مثل PyParallel اما صرفا رپر هست …

البته با موارد بالا ک گفتم .با فانکشنال زدن … براحتی میتونیم از Multi processing برای cpu bound و از multi threading برای io bound استفاده کنیم … و پاراللیسم میده … و همینطور خود asyncio
اما محدودیت داره … و به خوبی الگو های کانکارنسی کلوژور یا الیکزیر … نیست

3 پسندیده

سمیر جان من اصلا در حد این بحث های بسیار سطح بالای برنامه نویسی نیستم ولی یک چیز برای سوال شدم اگر سوال مبتدیانه هست ببخشید

شما گفتید همه ورودی خروجی ها کامپوننت ها به هم وصل می شه و داده در کل کامپوننت ها جریان داره بخاطر همین async هست درسته ؟
اینجوری یعنی داده ای که مربوط به کامپوننتی هم نمی شه ولی در کامپوننت جریان داره؟ درسته؟

2 پسندیده

من خیلی حجم زیادی از جزئیات رو نگفتم. به اسریم هایی که من پیاده سازی کردم می تونی به چشم یه سری queue نگاه کنی ( اما از لحاظ تکنیکی این حرفم غلط هست ) هر کامپوننت به صورت async از queue ورودی یه value رو بر می داره تو یه ترد یا تردپول یا service executor کارش و انجام میده و می ذاره تو queue خوروجی.

3 پسندیده

اول این که stateless بودن با توجه به scalable بودن نه تنها یه مزیت محسوب نمیشه، بلکه یک ضعف برای برنامه هست.
دوم این که بیشتر object های asyncio اساسا thread safe نیست. شما با کمک asyncio چطور می‌خواهید ایده HellHound رو پیاده کنید؟

اساسا همین thread safe نبودن خودش مانع توسعه پروژه میشه و اگه هم بخوای برنامه رو به روز کنی و یا تغییری توی یک قسمت از برنامه بدی، پیچیدگی برنامه رو بیشتر می‌کنه ، امنیت رو کم می‌کنه ، و هزینه رو بالا می‌بره.

1 پسندیده