مفاهیمی که تو این ریپو به کار برده شده رو کم کم توضیح میدم.

راجب معماری SOA چقدر اطلاع دارین؟
اولا تو SOA ما رو برنامه نویسی ماژولار خیلی تاکید داریم. یک دیتابیس میتونه توسط دو اپلیکیشن استفاده شه برعکس microservice. پس هر دیتابیس شما باید یک اینترفیس داشته باشه که طبق اون پیاده سازی انجام شده باشه. من اسم ماژولی که استفاده کردم اینجا ‍shared گذاشتم. بعد همین ماژول رو تو دو سرویس دیگه هم دیپلوی کردم.

تو بست پرکتیس هر دیتابیس شما باید جداگونه یک ماژول جدا باشه. ماگریشن هم میتونیم یا تو اون ماژول بذاریم یا تو سرویس اصلی اون دیتابیس. معمولا هر دیتابیس یک سرویس اصلی داره مثل monolithic ولی اگه نداشت پس باید تو ماژولش هم ماگریشن رو میذاریم. تو ماژول دیتابیس علاوه بر ماگریشن, باید ‍sql model database و query repository و سمپل دیتا تست هم باشه.

sql model database -> همون مدل دیتابیس که یک تیبل رو نمایش میده

query repository -> یک ریپازیتوری پترن که کوئری های تکراری داخلش هست که باعث تکرار کوئری تو اپلیکیشن های مختلف نشه. تو اپلیکیشن های مختلف همین کوئری رو ساب کوئری میکنیم

sample data -> دیتایی که تو محیط dev استفاده میشه و ساخته میشه

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

جدا از این, ما تو shared library هم business entities داریم. مثلا اینجا business entities های ما کریپتو, درگاه صرافی و واحد های پول مختلف بود. معمولا خیلی خوبه که همشون تایپینگ داشته باشند اینطوری اون تایپینگ تو سطح تمامی سرویس هامون رعایت میشه.

همینطور تو SOA ما تو shared library میایمentities architectureمون هم قرار میدیم. مثلا بروکر هایی که استفاده میکنیم. پیاده سازیشون. اینترفیسشون. معماری logging امون. معماری streamingمون. مثلا من یک کلس ساختم به نام AbanConsumer که abstract کلسی بود برای هر کانسیومری که تو هر سرویسی وجود داره. بعد بقیه سرویسا از همین کلس ارث بری میکنن و خیلی سریع میرن سراغ پیاده سازی consumer.

این shared module ها و shared database ها به ما اجازه میدن خیلی راحت سرویس جدید یا فیچر جدید اضافه کنیم. البته استارت SOA اولش یکم سخت و پیچیدست چون ‍deploy و CI/CD پیچیده تری داره نسبت به microservice و monolithic.


داخل ریپازیتوری من shared library کامل implement شده که میتونید ببینید.

@ManiFoldsPython

نکته دومی که رعایت شده و اکثرا میبینم بین دوستان کم تجربه تر رعایت نمیکنن استفاده از دیزاین پترنه!

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

من تو کدم از strategy pattern و factory pattern به همراه interface استفاده کردم.

اینترفیس هام یا abstract بودن یا protocol بسته به سطح حساسیت interface و کلس هایی که باید از روش ساخته میشد. (اگه این جمله رو متوجه نشدین حتما این ویدیو رو ببینید)

من crypto و API Integration ام رو استراتژی پترن زدم. که البته با Enum هم یک مپر ساختم و هر کلسی که ساختم مپ کردم به یک Enum . مثلا کریپتو آبان و تتر تو این مثال:

from enum import auto
from typing import Type

from shared.enums import StrEnum

from .aban import AbanCrypto
from .abc import AbstractCrypto
from .tether import TetherCrypto


class ECurrenciesType(StrEnum):
    TETHER = auto()
    ABAN = auto()


CRYPTO_MAPPER: dict[ECurrenciesType, Type[AbstractCrypto]] = {
    ECurrenciesType.TETHER: AbanCrypto,
    ECurrenciesType.TETHER: TetherCrypto,
}

بعد از همون enum ها برای ورودی API استفاده کردم به جای استرینگ. اینطوری ارتباطمو با تیم فرانت به حداقل ترین حالت ممکن رسوندم و تیم فرانت میتونه از json خود سواگر بیاد تمام دیفالت ها و enum ها و آپشن هارو بگیره. تو سطح API هم دیگه نیازی نیست ولیدیشن بنویسم چون دارم از enum استفاده میکنم.

بعد تو قسمت Currency که در واقع واحد های پول بود از پترن فکتوری استفاده کردم که راحت کارنسی جدید اضافه کنم.
در نتیجه با این دیزاین پترن هایی که استفاده کردم خیلی راحت میتونم یک API جدید اضافه کنم‍, یک currency جدید اضافه کنم, یک کریپتو حذف کنم یا اضافه کنم, و کاملا دستم بازه تو سمت لاجیک بیزنس.

@ManiFoldsPython

نهایتا API این شکلی شد

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

یا گفته شده فرض کنید صرافی سفارشات زیر ۱۰ دلار نمیگیره. (API Integration). چون گفته شده فرض کنید اینطوره دلیل نمیشه همه صرافی ها اینطور باشه.

موقع زدن تسک:
۱. به بیزنس لاجیک خیلی دقت کنید و سعی کنید داینامیک باشه
۲. تمام edge case هارو در نظر بگیرید.
۳. موقع دیزاین کردن اصلا به فرضیات دقت نکنید. موقع کد زدن به فرضیات بچسبید.
۴. .وقتتون رو سره چیزایی که ارزش گذاری نشده تو تسک تلف نکنید

@ManiFoldsPython

من این تسکو خیلی دوست داشتم ولی چیزی که اصلا دوست نداشتم راجب این تسک زمانش بود! این تسک فقط ۴۸ ساعت فرصت داشت که روی تست نویسی, سالید, معماری تمیز, کلین کد و داکرایز مانور رفته بود. همچنین جایی اشاره نشده بود که مثلا سیستم احراز هویت ننویسید یا فلان چیزو ننویسید که حجم تسک کمتر شه.

تو خود تسکم گفته شده بود <تراکنش کریپتویی یوزر باید بلافاصله انجام شه>‌ که نشون میده دیزاین سیستم باید real time و ‍event driven باشه.

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


"The only way to go fast is to go well." - Uncle bob

@ManiFoldsPython

یک توصیه به دوستانی که دارن یادگیری fastapi/flask رو شروع میکنن:

خواهشا از tortoise استفاده نکنید. در مقابل sqlalchemy جوکه. استفاده از sqlalchemy باعث میشه کمی از سینتکس orm django فاصله بگیرین و SQLتون قوی تر شه. مخصوصا اگه از جنگو دارین شیفت میکنید احتمال خیلی زیاد پایه SQLتون ضعیفه و ابتدای کار دستتون کند باشه تو نوشتن query و دیباگش.

همینطور ORM کاملا shit عی هست. از تعداد ایشو هاش نسبت به ستارش فکر کنم مشخص باشه. پختگی و mature بودن sqlalchemy به کنار. من ۲ ماه تو مارکت آلمان و هلند دنبال کار بودم یک آگهی ندیدم نوشته باشه باید مسلط باشین رو tortoise orm. ولی تا دلتون بخواد sqlalchemy بود.

@ManiFoldsPython

من با این کد خیلی حال کردم
https://github.com/Kludex/fastapi-responses/tree/master

یک سر بزنید بهش. کلا ۹۰ خطه.
چند تا ایشو باز و help wanted داره. با توجه به حجم کمش و دولوپر قوی که پشتشه میتونه open source contribution خوبی برای رزومتون باشه.

@ManiFoldsPython

یک use case خاص داشتم که باید بنا به دلیلی لاگ های سطح های مختلفو تو فایل های مختلفی سیو میکردم.
و لاگ هر consumer رو جدا ذخیره میکردم تو یک فایل مجزا

از rich و loguru استفاده کردم
شاید به درد کسی خورد.

(یکم کد عجیب شد بخاطر اینکه میخواستم دقیقا مثل rich اکسپشنو بندازم)
@ManiFoldsPython

کور دولوپرهای تیم Pydatic ✨

واقعا باعث افتخاره که حسن رمضانی هم عضوی از این تیمه. :) ❤️

خیلیا Depends و DIP رو اشتباه میگیرن. فکر میکنن هرجا از Depends تو fastapi استفاده کردن پس DIP رو رعایت کردن!

دوستان, مفهوم واژه DIP یعنی dependency inversion principle. یکی از پنج اصل سالیده. اصلا ربطی به Depends نداره. یعنی که که ماژول‌های سطح بالا باید به Abstraction وابستگی داشته باشند به جای low level module. این اصل به کاهش وابستگی‌های میان اجزا در برنامه شما کمک میکنه و می‌تواند کد شما را انعطاف‌پذیرتر، قابل نگهداری‌تر و آزمایش‌پذیرتر کنه.

هیچ کدی نیست که DIP رو رعایت کرده باشه ولی نشه تستش کرد. میخواد streaming باشه. میخواد ربات باشه. میخواد کراول باشه. علتی که تو فریم ورکی مثل scrapy ما تست نویسی نداریم چون این فریم ورک سورس کدش شت کده و DIP توش رعایت نشده برای همین نمیشه تست نوشت. رعایت DIP یک اصله هیچ ربطی به Depends نداره. شما میتونی تو کل اپلیکیشنت ‍Depends بذاری ولی بازم DIP رو رعایت نکرده باشی.


چه چیزی رو باید dependancy inject کنید؟ هرجایی که میتونید decoupling انجام بدید, و یا flexibility اضافه کنید, و یا نیاز به maintainability داره باید براش اینترفیس بنویسید. بعد implementation های مختلف اون اینترفیس رو dependency inject کنید.

پس این بستگی داره به پروژتون. مثلا اگه دارین یک لایبری اوپن سورس مینویسید و میخواین دست یوزر باز باشه تو تغییر روتر ها, اون موقع باید کنترلر روتر رو اینجکت کنید. همیشه باید جواب این ۴ سوال رو بدید موقع inject
1. Will it reduce the coupling?
2. Will it make my code more maintable?
3. Has flexibility increased?
4. Can I now write the test easily with mocking dependencies?
اگه یکی از این سوالا جوابش نه بود یعنی نباید DIP رو اعمال کنید.

مثلا authorization برای user role های مختلف باید inject شه!‌

حالا سوال اصلی, پس D‍epends چیه؟ depends یک فریم ورکی تو فست هست که DIP رو برای شما خیلی راحت میکنه.
خلاصش اینه که یک مپر اون پشت هست که Depends object هارو به یک callable وصل میکنه و موقع اجرا شدن روتر اون callable رو اجرا میکنه.

از دو نظر خوبه:
۱. نیاز ‍global variable رو از بین میبره تو سطح برنامه. در نتیجه برنامتون میتونه RAM خیلی کمی مصرف کنه موقع استارت شدن و سریع استارت شه.
۲. پیاده سازی DIP رو خیلی راحت میکنه.

موقع استارت شدن اپلیکیشنتون شما میتونید override_dependency کنید. یا برای هر روتر میتونید هم همینکارو کنید. اینطوری مثلا شما یک abstract database دارید, بعد میتونید همون اینترفیس رو با چند مدل مختلف دیتابیستون تو روتر های مختلف استفاده کنید. یا مسیج بروکر. مثلا یک روترتون message رو با کافکا produce میکنه و یک روترتون میتونه مسیج رو با rabbitmq بفرسته.

@ManiFoldsPython

یک سوال دارم از همتون,

چرا تو کامینیتی پستایی مثل دیزاین و کلین کد و اصول کد نویسی engage خیلی کمتری دارن؟‌ به جاش مثلا دیدم یک پستی راجب یک موضوع تخصصی تر تو پایتون خیلی engage بیشتری داره! یا مثلا پستم راجب sqlalchemy و tortoise که یک نصیحت و نظر شخصی ساده بود.

من تو دو کامینیتی روس هستم و میبینم ۲۴ ساعته حوزه سوالاتشون رو همین مباحث میچرخه. ولی احساس میکنم این تو بحثا تو کامینیتی ایران خیلی طرفدار نداره چون تاحالا هیچ پستی ازکانال که راجب این چیزا بوده engage نگرفته. البته هدف من engage گرفتن نیست ولی میخوام دلیلشو بدونم؟

نظره شخصیم اینه که هممون قرار نیست magic code بنویسیم. هممون قرار نیست اینترنال cpython رو خوب بلد باشیم. هممون قرار نیست پروژه big data داشته باشیم که مثلا یک جایی یک خطه کد efficient نبود پروداکشن زیر بار و فشار بره.

ولی هممون داریم رو یک پروداکت کار میکنیم که خیلی مهمه راحت بتونیم بهش فیچر اضافه کنیم و بیزنس fail نشه بخاطر دیزاین بدمون. هممون تست مینویسیم ولی حتی پستای تست نویسی منم engage خوبی نداشتن!

دلیل engage تو این بحثا نداشتمون چیه؟

@ManiFoldsPython

"من فکر میکنم بخاطر اینه که سطح usecase کامیونیتی پایتون فارسی در همین حد هست. کدی بنویسن که در درجه اول کار بکنه، در درجه دوم با پرفرمنس شوآف بکنن حتی اگه بهش نیاز نداشته باشن. درجه سوم هم نداره!😅"

چقدر حق بود این کامنت بابی!

من شخصا ترجیح میدم ۱۰۰ ساعت رو دیزاین وقت بذارم و بهتر یاد بگیرم تا اینکه ۱ ساعت رو cpython internal وقت بذارم. اونا هم فانه و قطعا دوست داشتنیه. ولی حقیقتا کاربرد کاری نداره براتون مگه maintainer لایبری اوپن سورس هستین.

من تو کانالم هر مطلبی نوشتم صرفا "یادداشت روزانم" بود. اینطور نیست که این مطالب رو همیشه بلد بودم. خیلیاشو همون روز یاد گرفته بودم. یادداشت میکنم چون بازنویسی و توضیحش به بقیه باعث میشه خودتون یک مبحث رو بهتر یاد بگیرین. و البته بحث کردن راجبش که باعث میشه ایده و نظرات بقیه رو بشنوید و یاد بگیرین. من واقعا دوست دارم پست میذارم ایرادی داره کلی کامنت و engage ببینم که به اون ایراد پرداخته شده. تو همون کامینیتی روسی پایتون که من هربار ریپویی یا کدی گذاشتم ترور شدم :)) و همون ترورا باعث شده که پیشرفت کنم.

مثال ‍DIP رو زدم امروز چون واقعا با پوست و گوشت حس کردم چقدر خفنه! تسک این هفته من این بود که admin role بنویسم برای بک اندمون, و کل این کار فقط با ۴۰ خط کد انجام شد. اضافه کردن یک implementation در راستای پروتکل authorization ای که داریم برای هر role. و return True تو همه حالت ها. حالا همون روتر هایی که داشتیم رو میتونیم با admin صدا بزنیم و بدون اینکه یک queryجدید هم اضافه کرده باشم دسترسی super user رو implement کردم. ولی تو کامینیتی ایران این خودش یک تسک چند هفته ایه :)) .

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

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand" - Martin Fowler

@ManiFoldsPython

پست آخر امروز:

من دانشم کافی نیست برای شرکت تو بحث. من دانشم کافی نیست برای کلین کد. من که تو big tech کار نمیکنم. من شرکتم ۵ نفره چرا باید کدم کلین باشه؟ من برای خودم کد میزنم. و .. . تجربه شخصی من ثابت کرده همه این حرفا اشتباهه. کد شما همیشه باید دیزاین شده باشه اگه قراره maintain شه. دیزاین به شما اجازه decoupling میده. دیزاین به شما flexibility میده. اینکه برداری تند تند کد بزنی یک جایی یقتون گرفته میشه.

یک خاطره براتون تعریف کنم, من ربات نوشتم. که کراول میکنه. کی؟ ۲ سال پیش. فقط خودم روش بودم. ۱۸ ماهم maintain کردمش. با بقیه فریلنسر ها هم کار میکردم ولی به صورت ماژولار بود (یک بحثایی بود که تو تخصص من نبود). یعنی سورس اصلی فقط دست من بود.

با خودم اون موقع میگفتم چطور میتونم تستش کنم!‌باید رباتم واقعا کار کنه. برای همین تو محیط لوکال و staging اینقدر تست میکردم تا استیبل شه. بعد دیپلوی میکردم. همه چی خوب پیش میرفت. وقت ازم زیاد میگرفت ولی مشکلی نداشت. چیزی نبود که نتونم بهش اضافه کنم. ولی به یک نقطه رسیدم که یک خط کد اضافه میکردم مجبور میشدم کلی دستی تست کنم تا بره رو پروداکشن. نتیجشم این شد که یک دفعه چند ماه ریلیز ندادم به پروداکشن.

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

اما همین الان دارم ریفکتورش میکنم(هنوز تموم نشده). کامل دیکاپل کردم همه چیو از هم. کل کدم تست داره و اتفاقا هرجایی گاف میدم یک دفعه ۱۰ تا تست fail میشه. تهشم دو تا integration تست داره که stateful میشه تستام. بقیشم stateless هست و تو ci/cd ام هست.

این موضوعو جدی بگیرید. کد تمیز نوشتن rocket science نیست دوستان. فقط با مطالعه و تمرین بهتر میشه. اینکه میام مثلا چالش تورهام رو خودم پیاده میکنم هدفم اینه که تمرین کنم. اینه که دیدمو بهتر کنم. مغزم بتونه تو حالت مختلف سولوشن تمیز بده.

همین کدایی که من ۱ سال پیش میزدم رو اگه الان share کنم باهاتون آبروم میره!‌ پس مهم نیست شما چقدر پایتون بلدید. قرار نیست Guido باشین برای کد تمیز نوشتن. همون کد های ساده و غیر پیچیده ای هم که دارین میتونید تمیز بنویسید. کد تمیز نوشتن یک طرز فکر و سافت اسکیله نه یک هارد اسکیل.

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."

این qoute خیلی قشنگه! دقیقا توی این qoute گفته شده کی باید کدتون کلین باشه و چقدر باید کدتون کلین باشه!

@ManiFoldsPython

نمیدونم چرا لینکا تو پست قبل درست نمایش داده نمیشن.


DIP
Enums in API
Strategy pattern with enums, interface & mapper impl
SOA & Shared repository
Event driven Impl
Migraton best practices
Fastapi boilerplates
Don't validate, parse
TDD definition & My idea about TDD
Stateless/stateful test
DesignStaminaHypothesis

کامینیتی پایتون با محوریت دیزاین و اصول کد نویسی:
https://news.1rj.ru/str/PythonFellow

محوریت کامینیتی:‌ پایتون و کلین کد و clean architecture
هیچ قانونی نداره. میتونید ساعت ۴ صبح سوال بپرسید. سوالاتی که تو محوریت مباحثی که بالا گفتم باشه خودم شخصا سعی میکنم با حوصله و سره فرصت جواب میدم. ریپویی باشه با فرصت بررسی میکنم فیدبک میدم. ریپویی هم میذارم اگه بقیه بررسی کنند و engage داشته باشن ازشون خیلی ممنون میشم. من انتظار داشتم وقتی ریپو پیاده سازی صرافیمو بذارم چند سوال پرسیده شه و چند تا ایراد دیزاینی ازش گرفته شه ولی هیچ engage ای نگرفتم. اگه بلد نیستین سعی کنید کدای همون پروژه رو بخونید و سوالتون رو تو گروه بپرسید.

@ManiFoldsPython

یکی از لایبری هایی که به درد میخوره یاد گیریش moreitertools هست.

https://github.com/more-itertools/more-itertools

البته قبلش باید رو خود built-in های پایتون مسلط باشین!یک سرچ کنید تو گوگل جلوش یک realpython بذارین کلی مقاله راجب همون موضوع میاره از realpython که عالیه :)

https://realpython.com/python-itertools/
https://realpython.com/python-zip-function/
https://realpython.com/python-collections-module/
https://realpython.com/python-filter-function/
https://realpython.com/python-reduce-function/
https://realpython.com/python-map-function/

@ManiFoldsPython

توضیح در پست بعدی
@ManiFoldsPython

این چیزیه که این هفته پیاده کردم و بنظرم خیلی تمیز دراومد! احتمالا ازش یک proto type تو fast بنویسم که تو ریپوم.

بذارین توضیح بدم:

خب ما چهار تو role داریم مثلا. طبیعتا میخوایم Super user admin امون همه امکانات رو داشته باشه (read/write/update/...)

و از طرفی میخوایم مثلا support امون امکان read-only داشته باشه فقط.

و از طرفی میخوایم user role 1 و 2 هم دیتای خودشون رو چهار آپریشن اصلی رو داشته باشین (CRUD)

چطور هندل کنیم؟
یک کنترلر مینویسیم. تو arg اون کنترل as_user_ids میگیریم به عنوان parameter.

بعدش وقتی وارد مثلا یوزر ادمین میشیم. آیدی همه یوزر هارو از یک اندپوینت میگیریم که فقط توسط ادمین قابل اجراست.

بعد تو درخواست های بعدی میتونیم یوزر رو سوییچ کنیم. بالای صفحه هم میتونیم مثلا یک toggle down بذاریم که ایدی یا اسم یوزر رو وارد کنیم و صفحه از perspective اون یوزر نمایش داده شه. انگار که اون یوزر هستیم ولی بدون اینکه لاگین کنیم توش.

چرا نباید لاگین کنیم تو یک یوزر؟‌چون متریک system رو زیر سوال میبریم و پیچیده میکنیم (که مثلا داریم بررسی میکنیم یوزر چقدر فعالیت کرده تو ۱۴ روز گذشته)

اینطوری با حداقل تغییر میتونیم دقیقا از همون اینترفیسی که برای کاربرمون داریم با اضافه کردن یک toggle و implement کردن admin access level یک همچین فیچر خفنی بذاریم. طبیعتا همینو هم میتونیم برای role های دیگه اعمال کنیم مثل support که فقط میتونه دیتا رو read کنه.

و خود ACL هم dependency inject میکنیم. ببینید چقدر decopuling کمکمون میکنه تو فیچر جدید دادن !:) حالا اگه کنترلر نداشتیم باید کل پروژه رو از اول ریفکتور میکردیم برای همچین فیچری


اگه جاییشو متوجه نشدید حتما بپرسید تو کامنتا
@ManiFoldsPython

به طور ساده تر

مثلا برای یوزری که دسترسی خاصی نداره
تو پیاده سازیش میگیم as_user_ids همیشه مساویه با user_id خودش تو JWT. چون نمیتونه user دیگه ای رو میمیک کنه

اگه ادمین بود, هر یوزری خواست میتونه mimic کنه. مشکلی نداره. کلا reutrn True همه جا 🙂

ولی اگه مثلا یوزر خاصی بود (مثل حالت مجموعه گیری) که میتونست چند یوزر دیگه رو کنترل کنه, اون موقع باید تو ACL service چک کنیم که ایا این یوزر میتونه mimic کنه اون یوزر دیگه رو یا نه؟ و اگه میتونست, اونوقت کنترل رو ران کنیم. اگه نمیتونست, همونجا http exception بندازه.

یک نکته خیلیییی مهم وقتی دارین از async orm استفاده میکنید مثل sqlalchemy async engine مثل asyncpg

اگه دارین transaction میزنید اصلا نباید connection sessionاتون رو بین coroutine ها share کنید. تا وقتی تراکنش کامل نشده. ممکنه فاجعه رخ بده. مثل Unintended commit یا رول بک نخوردن یا Data Inconsistencies یا deadlock یا از بین رفتن ایزولیشنی که تو transaction داریم یا خیلی حالت های دیگه که نمیگنجه تو این پست جا بدم!
ارور هندلینگتون کاملا باید به صورت graceful باشه که کانکشن رو تو حالت stable نگه داره و بسته نشه.

بهترین کار چیه؟ فقط واسه read بیاین از چند coroutine استفاده کنید. دیگه خیالتون راحت هیچ اتفاقی نمیفته. میتونید کل query هایی که میزنید رو همه یک جا بزنید. و مشکل N+1 اگه تو یک روتر دارید (که از query نمیاد مثلا باید رو یک ریزالتی لوپ بزنید و قبلش یک درخواست به یک جایی بزنید بعد query بنویسید برای هر ریزالت درخواست)‌میتونید با این روش حداقل تو لایه اپلیکیشن ریسپانس تایمو به شدت کاهش بدید (البته حواستون باشه دیتابیس رو داون نکنید :))‌ حواستون باشه N چقدر گندست).

@ManiFoldsPython

یک کدینگ چلنج بسیار ساده و در عین حال بسیار سخت جهت تمرین 🙂


Software Requirements:
فرض کنید برنامه ای دارید برای یک مدرسه ای مینویسید. داخل مدرسه ۴ یوزر role مختلف وجود داره:
۱. مدیر(ادمین)
۲. مشاور
۳. معلم
۴. دانش آموز

یک اپ student طراحی کنید که داخل آن یک نمره grade دانش اموز مشخص باشد. و همچنین امکان CRUD برای آبجکت دانش آموز وجود داشته باشد
۱. ادمین توانایی CRUD رو تو سطح کل مدرسه داشته باشد. ادمین میتواند دانش آموز را از مدرسه اخراج کند.
۲. مشاور فقط قابلیت read ولی اطلاعات دانش اموز سطح کل مدرسه رو داشته باشد
۳. معلم قابلیت CRUD فقط تو کلاس خودش را داشته باشد. معلم نمیتواند دانش آموزی را از یک کلاس دیگه که معملش نیست اخراج کند.(دیلیت کند)
۴. دانش آموز فقط میتواند نمره خودش رو ببینید و اجازه آپدیت و خروج و یا ساخت دانش آموز دیگر یا دیدن نمره دانش آموز دیگری رو ندارد.


Technology Requirements:
زبان برنامه نویسی می بایست پایتون باشد.
برای انجام این تسک ازJWT و فست یا فلسک استفاده کنید.
به جهت ساده سازی و کاستن زمان صرف شده میتونید از ساخت تیبل SQL صرفه نظر کنید و دیتا رو داخل اپلیکیشن ذخیره کنید. توجه کنید استراکچر تیبل سازی و دیتا کلاس مطابقا می بایست رعایت شود.
تست نوشتن قدردانی می شود.(writing test is appreciated)
رعایت اصول OOP و سالید و کلین کد ارزش ارزش گذاری میشود

بیش از ۴ ساعت برای این تسک زمان نذارید.
----
خودم انجامش میدم ریپوشو بعدا میذارم اینجا. شما هم اگه دوست داشتین انجام بدید. اگه ریپو رو ریپلای کنید رو همین پیام بررسی میکنم حتما

۴ ساعت دیگه نه. کلا بهتره ۴ ساعت وقت بذارین براش بیشتر نشه. بیشترم شد اشکالی نداره ولی بهتره که خیلی وقت نذارید روش.
هر موقع وقتتون خالی بود وقت بذارید براش‌. ددلاین نداره استخدام که نمیکنم‌:))


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

@ManiFoldsPython