Handling Event
بیشتر سیستم ها request driven هستند که یه حجم قابل توجهی از api request های کاربر رو handle میکنن. یک بخش دیگری از سیستم ها event driven هستند. تفاوت event و request در اینه که معمولا request جزئی از یک مجموعه تعامل (interaction) یا session هست. معمولا هر درخواست کاربر یک جزیی از تعامل کاربر با وب اپلیکیشن هست. در طرف مقابل event ها معمولا single-instance و asynchronous هستند. معمولا event ها مهم هستند و باید اجرا بشن اما نکته ای که وجود داره اینه که معمولا event ها در زنجیره اصلی تعامل نیستند و با ناهمگامی زمانی هم میشه اجراشون کرد. مثلا ارسال ایمیل خوش آمدگویی به کاربران جدید یه event هست که کامل مستقل از تعامل اصلی کاربر با سیستم هست. به همچنین ارسال notification برای کاربران.
به دلیل ذات مستقل بودن و stateless بودن event ها و همچنین با در نظر گرفتن این نکته که نرخ اتفاق افتادن event ها میتونه خیلی متغیر باشه، معماری FaaS یه گزینه خیلی ایده آل برای سیستم های event driven هستند.
همچنین eventهای جدید بصورت dynamic به سرویس اضافه میشن و به خاطر lightweight بودن deployment توابع، FaaS میتونه گزینه ایده آلی برای اضافه کردن event handler ها برای سرویس ها باشه. علاوه بر این به خاطر مستقل بودن توابع، باعث میشه پیچیدگی سیستم کم بشه و developer فقط روی کارهایی که برای رسیدگی به یه single event داره تمرکز کنه نه چیز دیگه ای.
یه مثال مناسب برای event ها میتونه two-factor authentication باشه، جای اینکه سرویس اصلی مجبور به generate کردن کد بشه و اونو بخواد برای کاربر پیامک کنه، سرویس اصلی فقط کافیه یک web-hook request به FaaS بفرسته، و FaaS میتونه خودش پس از جنریت کردن کد برای کاربر ارسالش کنه.
#faas
#designing_distributed_systems_brendan_burns
@gocasts
Post #105
1.08K
Go Casts | Systems & Agents 🚀 الگوهای FaaS The Decorator Pattern: Request or Response Transformation الگوی decorator در زبان python شباهت زیادی به این الگو دارد. چون که decorator معمولا stateless هستند و معمولا بعد از نوشته شدن کد اصلی اضافه میشن. مثال خیلی روشنش وقتیه که شما میخواید…
- 👍 2