https://www.youtube.com/watch?v=q99TYA7LnuA

یک فیلم جذاب از آرمین که داره rye رو معرفی میکنه. توصیه میکنم حتما ببینید.
داخل یک ویدیو تو کانال یوتیوبش هم یک walk through رو سورس کد و نحوه کارکرد rye رو نشون میده.
پ.ن: فقط صدای کیبورد آرمین >>>. البته واسه ویدیو. وگرنه همکارم بود استعفا میدادم 🤣(شوخیه دوستان جدی نگیرین😅)

@PyBackendHub

#otel

بر پایه opentelemetry ابزار بعدی pydantic هم توسعه داده شد 🔥🔥

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

دقایقی پیش logfire سولوشن جدید pydantic اوپن سورس شد. توصیه میکنم حتما یک سر بزنید بهش
https://docs.pydantic.dev/logfire/

@PyBackendHub

#otel

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

اول بذارین توضیح بدم observation یعنی چی. ما توی devops دو آپریشن داریم که شبیه همن و گاها باهم اشتباه گرفته میشن. اولیش مانتورینگه. مانیتورینگ به پروسه ای میگن که دیتا کالکت میشه از سرویسی, و یک ریپورت از سلامت سرویس بر اساس metric های مشخصی که برای سلامت سیستم رو نشون میدن و کالکت شدن ساخته میشه. یعنی چی؟ مثلا تعداد ریسپانس های 5xx در ۲۴ ساعت گذشته. یکی از شناخته شده ترین ابزار برای اینکار prometheus هست. observability به پروسه ای میگن که رویکرد تحقیقاتی داره. یعنی دنبال این نیست که بگه چقدر ریسپانس 5xx وجود داره. دنبال دلیل وجود این ریسپانس هاست. چرا الان این درخواست تو پروداکشن ارور ۵۰۰ میده؟ خوندن کل لاگ سرویس قدیمی ترین و ابتدایی ترین راهکار بود.

وقتی بک اند پیچیده تر شد, دیگه خوندن لاگ واقعا کارساز نبود. شما فکر کنید در لحظه ۱۰۰ درخواست داره میاد براتون. چطور میخواین لاگ هارو بخونید؟ تو قدم بعدی لاگ های هر درخواست رو جدا کردن. ولی بازم کار ساز نبود تو دنیای distributed system. چون مثلا یک سرویس ۱ با سرویس ۲ داشت حرف میزد. ورودی که میداد بهش درست نبود. سرویس ۱ صرفا یک exception میگرفت که سرویس ۲ استتوس ۵۰۰ داده. و این کافی نبود برای اینکه متوجه شیم چه اتفاقی میفته.

سولوشن های زیادی اومدن تو مارکت. از قبیل sentry که شاید اسمشو شنیده باشین. یا datadog و لوکی و ... . اینقدر این سولوشن ها زیاد شدن و هر کدوم ساز خودشون رو میزدن. نمیشد راحت از این سولوشن سوییچ کرد به اون یکی. نمیشد مزایا دو سولوشن رو همزمان داشت. و learning curve سختی داشت اگه میخواستین سوییچ کنید از یکی به یکی دیگه.

اینجا بود که CNCF (Cloud native compute foundation) یک پروژه جدید رو استارت زد. همون فاندیشنی که کوبر و prometheus و خیلی ابزار های تحت کلاد رو ساخته. اومد یک پروتکلی ساخت به اسم opentelemetry.
یعنی چی پروتکل؟ یعنی گفت sentry جان من برام مهم نیست شما لاگ رو چطور ذخیره میکنی یا پردازش میکنی اینترنالی. شما باید span داشته باشی. metric داشته باشی. و trace. و دقیقا تعریف کرد که اینا چین. یعنی اومد گفت اینترفیس خارجی یک سیستم observability چطور باید باشه؟ چون در نهایت همه این سیستما شبیه هم بودن. و حالا چون همشون داشتن از یک پروتکل خاصی پیروی میکردن شما میتونستی راحت از سولوشن یک سوییچ کنی به سولوشن دو. مثلا شاید مثالشو دیده باشین که تو سیستم فایل استوریج بعضی استوریجا s3 compatible هستن. اینم دقیقا شبیه همونه.

استک observation به دو قسمت تقسیم میشه. یکی میشه exporter و یکی میشه داشبورد. exporter معمولا یک لایبریه که شما نصب میکنی. و باهاش اون دیتایی که میخوای export میکنی. و میگی دیتا رو کجا بفرسته.(یک وقتام برعکسه, سرور داره دیتا رو میگیره). قسمت دوم میشه اینترنال اون استک. مثلا دیتایی که فرستاده میشه تو چه دیتابیسی ذخیره میشه؟ چطوری پردازش میشه؟ چی به شما نمایش داده میشه؟من بهش میگم داشبورد.

خوده opentelemetry داشبورد خاصی نداره. صرفا یک سری exporter تو زبون های مختلف داره که میتونید تو گیتهابش ببینید. مثلا برای fastapi و جنگو لایبری داره. ولی پیاده سازی و داشبوردی نداره برای نشون دادن این اطلاعات. چون همونطور که گفتم در نهایت فقط یک پروتکل و specification هست. از طرفی سولوشن های داشبورد زیاده.یک سرچ کنید میرسید بهش. مثلا من خودم signoz استفاده میکنم.

خب همه اینارو گفتم. حالا نقش logfire این وسط چیه؟ logfire همون لایبری های اکسپورتر opentelemetry رو اینترفیسشو بهتر کرده. و با pydantic هم اینتگریتشون کرده. و یکم utilty اضافه کرده. این قسمت exporter اش هست که اوپن سورسه.
یک قسمت داشبورد هم داره که هنوز اوپن سورس نشده. و مشخص نیست که بشه یا نه. ولی فعلا رایگانه.


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

@PyBackendHub

یک سوال خوبی هم که پرسیدن این بود که چی سره sentry و datadog و اینا اومد.

ببینید اینا خودشون یک sdk داشتن. هنوزم دارن. منتهی اومدن sdk هارو ریفکتور کردن که با opentelemetry protocol هم سازگاری داشته باشه. ولی اگه sdk ها ۱۰۰ تا فیچر داشتن, اگه سوییچ کنید رو پروتکل اوپن تلمتری, اون موقع ممکنه ۲۰ تا فیچر sdk هاشو از دست بدید. چرا؟‌ چون opentelemetry هنوز نتونسته چهارچوبی بسازه که صد در صد فیت باشه واسه همه این سولوشن ها. ولی اگه بخواین اون ۲۰ تا فیچر رو فاکتور بگیرین, مثلا شما میتونید sdk سنتری رو استفاده کنید با داشبورد سیگنوز. یا sdk لاگ فایر با داشبورد سنتری. یا sdk خوده اوپن تلمتری با datadog. و خوبی opentelemetry هم دقیقا همینه. که شما هر sdk که دوست دارین با هر داشبوردی میتونید استفاده کنید.
منتهی همونطور که اشاره کردم ممکنه یک وقتا sdk ها در برابر داشبورد خودشون یک سری فیچر های اضافه و خارج از پروتکل opentelemetry داشته باشن.

@PyBackendHub

بنظرم دانش تو زمینه بک اند به ۳ قسمت تقسیم میشه، که خیلی مهمه سه تاشو داشته باشیم.

مثلا فکر کنید میخواین یک rest api بنویسید به همراه تست.

قسمت اول بلد بودن فریم ورکی برای اینکاره. مثل پای تست و فست. ولی بلد بودن اینا کافی نیست فقط

قسمت دوم، فلسفه پشت اون موضوعه. که دونستنش خیلی ضروریه. مثلا تو بحث api نویسی کی باید یک اندپوینت post باشه کی put کی patch و .. . یک api چطور باید باشه. Rest api چی داره که بهش میگن restful. و …. یا مثلا برای تست نویسی چی باید تست شه. چقد باید تست نوشته شه. چی باید ماک شه. چی نباید ماک شه.

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


@PyBackendHub

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

@PyBackendHub

👌👌
بحثش بود دیروز تو گروه که یکی از دوستان دنبال مدلی از business analytic دیتا بود و میخواست خودش اینو حساب کنه و یک فیچر جدید بذاره
ولی حقیقت واقعا نیازی نیست. اگه observationتون خوب باشه, خیلی وقتا همون دیتا میتونه برای بیزنس خیلی مهم و کریتیکال بشه.

@PyBackendHub

یک سایتی هست, که ۱۲ فاکتور مهم برای اپلیکیشن های software-as-a-service رو نوشته. و توصیه میکنم بخونیدش حتما.

https://12factor.net
تو قسمت کانفیگ یکیش اینه:
Config varies substantially across deploys, code does not.

دقت کنید ببینید چطوری تغییر کرد. یعنی چی دقیقا این؟

یعنی این پترن اشتباهه:
deploy_env = "local" / "dev" / "staging" / "prod"

اپلیکیشن شما با تغییر deploy_env نباید تغییر کنه. اپلیکیشن شما یک کانفیگ داره که آگاه نیست که قرار کجا ران شه. پس چیزایی مثل prod.env اشتباهه. دلیلش هم تو سایتش نوشته:
In a twelve-factor app, env vars are granular controls, each fully orthogonal to other env vars. They are never grouped together as “environments”, but instead are independently managed for each deploy. This is a model that scales up smoothly as the app naturally expands into more deploys over its lifetime.

پس شما هرچیزی که میخواین کانفیگ شه رو کانفیگ پذیر میکنید. دیگه اینکه debug=false باشه یا true تو deploy برمیگرده به آپریشن. بهتره مقدار دیفالت نذارین اگه چیزی که دارین کانفیگ میکنید خیلی مهمه.

و نکته بعدی که بسیار مهمه, پوش کردن .env به ریپو نباید اشکالی تو ci/cd شما بکنه. حواستون باشه چه فایل هایی رو دارین شیپ میکنید به پروداکشن. فایلی مثل .env فایلی نیست که شیپ کنید. اینکه چطور env variable ها ساخته میشن روش های مختلفی وجود داره, ولی ساختنش با یک فایل .env و اضافه کردنش به گیت ایگنور اصلا روش منطقی نیست. چون تو scale شما خیلی اذیت میشین. هر scale horizontally که بخواین انجام بدید باید ssh کنید به سرور و اون فایل ‍.env رو اضافه کنید 🤦‍♂️
تجربه توسعه هم بد میکنه. روش های زیادی برای انجام این کار هست. مثل استفاده از kustomize یا secret manager کلادی که ازش استفاده میکنید یا hashicorp vault یا .... . اینکه چه روشی انتخاب میکنید مهم نیست. مهم اینه که تو حالت اول stateless باشه یعنی بتونید خیلی راحت scale horizontal انجام بدید. در درجه دوم اینکه implicit نباشه(مثل deploy env) و کاملا مشخص باشه چی داره کانفیگ میشه. و در درجه آخر و حالت خیلی ایده آل یک حالت versioning و ورژن کنترل داشته باشه.

@PyBackendHub

یک ویدیو خیلی جالب از کنفرانس pgconf در سال پیش که یک message queue با راست رو postgresql نوشتن.

https://www.youtube.com/watch?v=GG2C7gktfoQ

حتما توصیه میکنم ببینید. چون خیلی نکات قشنگی و query های قشنگی داره این ویدیو.

@PyBackendHub

یک پروژه خیلی ساده و کم حجم نوشتم که چطوری pub/sub رو با ردیس پیاده کنیم طوری که تایپ سیف باشه. تایپ سیف بودن این پروژه, هدفش بود. همین پترن رو میتونید هرجای دیگه ای هم اپلای کنید.

واسه sub هم از لایبری خودم aioclock استفاده کردم که ببینید چقدر سادست استفاده ازش 😁
https://github.com/ManiMozaffar/typed-redis

@PyBackendHub

ایده برای aioclock دارین؟ ممنون میشم کامنت کنید.

اگه مشتاقین aioclock چیه, یک لایبری هست که وظیفه اش scheduling عه با استفاده از asyncio پایتون و سینتکس جذاب و declartive که هم دپندسی اینجشکن مثل فست داره و هم event های مختلف مثل استارت آپ و شات داون.

https://github.com/ManiMozaffar/aioclock

@PyBackendHub

سوال پرسیدن که هدف این کد چیه چیو داره حل میکنه؟
ببینید یک اصلی تو کد نویسی هست که کد شما هرچی invariant کمتر داشته باشه بهتره چون احتمال خطا کمتره. و شما تست کمتری مینویسی. اینو بارها تو کانال اشاره کردم. که دو تا از بهترین روش ها برای رسیدن به این یکی fully typed بودنه کده (مثل کد ریپازیتوری که به اشتراک گذاشتم) و یکی type state هست یعنی استیت component شما تو یک تایپ encode شه. این دو تا کمی متفاوتن. لایبری fastexchange که اوپن سورس کردم تایپ استیت هست چرا چون state currency تو تایپینگ انکود شده. ولی این پروژه فولی تایپه نه تایپ استیت.

من الان تو چنل "foo" انتظار دارم یک data خاصی ارسال شه چه گارانتی هست که من تو چنل فو چیز اشتباهی نفرستم؟ این صورت مسئله هست. راهکارش چیه؟ من لایبری رو wrap میکنم. دیگه موقع پابلیش فورس میکنه که تایپ درستی بدم برای چنل با استفاده از discriminated union میزنم رو چنلج های مختلفی که ساپورت میکنه برنامم. و همینطور موقع گرفتن مسیج هم فورس میکنه که همون تایپ رو بگیرم. دیگه بایت و دیتا خام نمیگیرم.

این باعث میشه:
۱. دیتا رو تو چنل اشتباهی نفرستم
۲. تو چنلی دیتا اشتباه نفرستم

و تجربه توسعه رو بهتر میکنه.

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

@PyBackEndHub

داکیومنت پروژه AioClock منتشر شد 🔥🚀

برای دسترسی میتونید لینک کنید

یک scheduler مدرن و async به جای راکتری و لایبری های مشابه

@PyBackendHub

این عکس واقعا خیلی قشنگ نشون میده over engineering رو. بیشتر مواقع زمانی اتفاق میفته که میخوایم آینده رو پیشبینی کنیم.

تا وقتی به حد کافی نقطه مشخص دارین سعی نکنید سولوشنی بدید که همه کیس هارو کاور کنه. معمولا سولوشن پرفکت اول مسیر خودشو نشون نمیده.

@PyBackendHub

تو خیلی زبونا ما تایپی داریم به نام Never از جمله پایتون. به چه دردی میخوره این تایپ؟‌
خیلی مفیده. و یکی از قشنگ ترین کاربردش exhaustive block هست. یعنی به شما اجازه اجازه میده که کدتون رو تو کیس های مختلف تو یک بلاک هندل کنید بدون اینکه چیزی رو جا بذارین. و اگه یک چیزی بعدا اضافه کردن که هندل نکرده بودین تایپ چکر ایراد بگیره ازتون و بتونید هندل کنید. مثلا فکر کنید شما User status دارین. و رفتار سیستم شما تغییر میکنه نسبه به وضعیت یوزر. و این رفتار تو تک تک بیزنس کیس ها وجود داره. یک راهش استفاده از دیزاین پترنه که به قول مارتین به نحوی کل لاجیکتون تو یک فایل باشه.و برای هر وضعیت هندلر داشته باشین. ولی یک راه خیلی آسونتر استفاده از تایپ Never هست. که خیلی قابل اعتماد تره و فضایی نمیذاره برای خطا کردن!

class UserStatus(StrEnum): 
    Verified = auto()
    Unverified = auto()
    Banned = auto()
    # any other...


user_status: UserStatus
match user_status: 
    case UserStatus.Banned:
          # handle here
          ...
    case _: 
          assert_never(user_status) 

الان این کد fail میشه تو تایپ چک. چرا؟ چون user_status تو اون بلاک میتونه هر استتوسی جز Banned باشه. وقتی فیل نمیشه که شما همه کیس های ممکن رو هندل کرده باشین. دقیقا همین موضوع تو زبونای دیگه هم هست.

enum UserStatus {
    Verified,
    Unverified,
    Banned
}

const user_status: UserStatus

switch(user_status) {
      case UserStatus.Banned:
          // handle here...
      default:
         user_status satisfies never;
  }

خلاصه که از IDE و تایپ چکر بیشتر بهره ببرین 😁 تو سال ۲۰۲۴ هستیم. و تایپینگ های زبونا اینقدر قوی شدن که بعضا turing complete هستن!

@PyBackendHub

توصیه شخصی, دیدم بعضیا میخوان یک فریم ورک یا زبون جدید یاد بگیرن خیلی سریع میرن سراغ یک پروژه خیلی خوب. (از جمله خودم تا چند وقت پیش). ولی حقیقتا خیلی کمکتون نمیکنه.مثلا من برم یک پروژه خفن FastAPI ببینم و سعی کنم همون پترن رو تکرار کنم. چه مشکلی ایجاد میکنه؟ دید منو به شدت کور و محدود میکنه. یعنی چی؟ فرض کنید شما کاناله منو دارین دنبال میکنید, یک پروژه فست دارین میخواین تصمیم بگیرین چطور با دیتابیس کانکت شید. خب راه های مختلفی هست, مثل استفاده از orm و چه orm ای هم مهمه. یک راه حل اینه که شما صرفا چیزی که من نوشتم رو دنبال کنید, که اصلا ممکنه حرف من درست نباشه یا دیدم bias باشه.

خب چیکار باید کنیم؟‌ نظره من اینه که شما باید بتونید سبک سنگین کنید. ببینید کسی که از orm django استفاده کرده چی گفته (تو اینترنت مقاله پیدا کنید). درک کنید چرا یک نفر از orm django خوشش میاد و یک نفر بدش میاد. همینکارو برای بقیه orm های پایتونی هم انجام بدید. و البته یک قدم خارج تر شید. فلسفه استفاده orm چیه؟ چه فلسفه ای پشت orm django هست؟ چه فلسفه ای پشت sqlalchemy هست؟ query builder چیه؟ فرقش چیه با orm؟ یعنی خیلی فلسفه ها صرفا تو طرز استفاده از ابزاره, نه تنوع یا فیچر های مختلف یک ابزار.

@PyBackendHub

#otel
تو پست قبلی که ریپلای زدم به زبون خیلی ساده توضیح دادم opentelemetry یا همون otel چیه. در ادامه سری پست های opentelemetry (که مخففش میشه otel) میپردازیم به ۴ تا component بسیار مهم که بدنه otel رو تشکیل میدن. همونطور که گفتم otel صرفا یک specification ای هست برای observation. پس خیلی مهمه که بدونید. این component ها چی هستن و چرا وجود دارن.

اولی که حتما آشنایی دارین باهاش لاگه. که زیادی به توضیح نمیخواد. لاگ قدیمی ترین شکل observation در یک نرم افزار بود. دومی event هست. event هم لاگه ولی با این تفاوت که event کاملا structure مشخصی داره. تو otel لاگ قابل قبول نیست و همیشه باید event بسازین. معمولا پکیج های otel خودکار لاگ شما رو تبدیل به event میکنن پس نیازی نیست نگرانش باشی. یک نمونه ساده از event اینطوریه:
{"event":"Failed to connect to DB","level":"warning","timestamp":"2024-02-15T12:45:32.681868Z","logger":"foo_module"}

ایونت به عبارت ساده تر لاگیه که تایم استمپ داره و راحت تر query میشه.
قسمت سوم otel میشه span. چیه دقیقا و فرقش با لاگ (یا ایونت چیه)؟‌ span یک نقطه استارت و یک نقطه انتها دارن تو زمان. یعنی تو یک بازه زمانی هستن. و هر span کلی event میتونه داشته باشه.
یعنی به عبارت ساده تر لاگ یا event درواقع یک عکسی هست از یک لحظه از execution در نرم افزار شما. ولی span یک فیلم ۳ بعدیه از یک کاری که در نرم افزار شما انجام شده. و نکته جالب تر اینه که span میتونه key attribute داشته باشه. مثلا من یک span دارم که وقتی کاربر محصولی اضافه کرد, یک مدل train شده باید اطلاعات رو از اون عکس محصول extract کنه و به محصول اضافه کنه (مثل رنگ و اینا).
تو این کیس منطقیه که اسم span من باشه "extracting metadata from product" . و attribute ای داشته باشم به اسم image_id که بدونم داره رو چه عکسی این اتفاق میفته. user_id هم مناسبه چون میدونم عکس برای چه یوزریه. تعداد تگ هایی که مثلا extract شده هم میتونم key value کنم. "extracted_tags". این شد یک span خیلی با ارزش. این مثالو تا اینجا داشته باشین.

و در آخر trace رو داریم. که مجموعه ای از span ها میشن یک trace. هر کدوم از این اسپن ها میتونن تو یک سرویس و یک جای مختلف سیستمتون اتفاق افتاده باشن. لزوما نیازی نیست این اسپن ها به ترتیب باشن. میتونن همزمان اتفاق افتاده باشن که میشه end-to-end view از سیستمتون. بخوام ساده تر بگم trace در نهایت میشه یک سریالی که چند فیلم 3d کنار هم گذاشتین و همه اینا به هم مربوطن و باهم معنی پیدا میکنن.

حالا به چه دردی میخوره؟ فکر کنید تو facebook marketplace دارین کار میکنید. و همون flow ای که بالا تر توضیح دادم هست. یوزر عکس یک محصولی رو آپلود میکنه به یک api ای. و بعد متا دیتا اون عکس extract میشه و در نهایت به عده ای از کاربران که علاقه دارن به اون category از اون محصول ایمیل ارسال میشه که مثلا همچین محصولی تو مارکت فیسبوک اومده.

به شما تیکت میدن که چرا فلان یوزر عکسش هیچ تگی نداشته؟ شما بلافاصله داشبوردتون رو query میکنید

name = 'extracting metadata from product' AND user_id='x' AND  extracted_tags=0

تمام. حالا شما همه span هایی که مربوط به اون یوزره و هیچی extract نکرده رو میبینید. حالا رو یک span مورد نظرتون کلیک میکنید. و trace رو میبینید. trace اش چی میشه؟‌میشه از اون نقطه ای یوزر عکسو از فرانت آپلود کرد تا اون موقعی که ایمیل فرستاده شد به یوزر های دیگه. کل این میشه trace. و لاگ هر span ای که تو هر جای سیستمتون داشتین رو اینطوری میتونید بخونید و راحت دیباگ کنید.

یا لزوما reactive نیست.یک سیستمی که خوب instrument شده (observability خوبی داره) میتونه کاره مانیتورینگ هم تا حدی انجام بده. شما دیتا خیلی راحت تو این case میتونید پرفونس مدل هاتون رو graph کنید که روزانه چند در صد عکس ها تگ میشن. چقدر تگ میشن. با percentile نشون بدید اینو.

ولی صبر کنید تموم نشده! یک سیستمی که خوب instrument شده خیلی راحت میتونه دیتا برای business analytics هم داشته باشه. سوال اینجاست که من ایمیل فرستادم به یوزر های دیگه. آیا اونا رو ایمیل کلیک کردن و محصول رو خریداری کردن؟ چند درصد اینکارو کردن؟ ادامه همین مسیر هم میتونست تو همون trace باشه!

خلاصه اینکه opentelemetry رو دست کم نگیرین😁 باهاش میشه جادو کرد. به شرطی که درک کنید برای چی ساخته شده.

@PyBackendHub

اینم میشه flow کلی..

@PyBackendHub

#otel

نمونه مثال دیروز رو یادتونه؟ پیاده سازیش همچین حالتی میشه. که البته کدشم پوش کردم اینجا که ببینید

وقتی مفاهمیشو بلد باشین خیلی سادست. مثل این میمونه SQL بلد باشین و بخواین از orm فقط برین ببینید چطوری میتونید اون query رو بنویسید. ولی اگه مفاهیم یا specification رو بلد نباشین به شدت گیج کنندست.

برای مثالمون ۳ تا راهکار هست:
۱. وقتی تو یک سرویس هستن, اگه همون کانتکس منیجری که من باز کردم رو دو بار زیر هم باز کنید اسپن دوم میشه child اسپن اول. وقتی مناسبه که تو یک سرویس نیاز دارین به چند اسپن.(دارین چند تا کار میکنید)

۲. وقتی تو دو سرویس جدا هستین, میتونید لینک کنید. برای لینک کردن باید trace id و span id رو داشته باشین. میتونید تو هدر بفرستین و بعد بگیرین.

۳. روش سوم و از همه بهتر Context Propagation هست. که اینجا مثالشو گذاشته که با ۲ تا api فلسک اینکارو انجام داده. وقتی به درد میخوره که شما یک event ای دارین تو چند تا سرویس. و میخواین همه باهم کنار هم بیان. یک وقتا حتی ممکنه sequential هم نباشن. ولی پیچیده تره این حالت. برای همین تو مثال نیاوردمش. تو کیس ما این روش از بهترین بود.

@PyBackendHub

در نهایت تو داشبورد همچین حالتی میشه اگه روش ۳ام رو برین:

@PyBacknedHub