Rethink State💡 چرا باید وضعیت جلوی خود را در مورد وقایع الگوبرداری کنید

دنیای داده محور که در آن زندگی می کنیم

'داده ها پول است' – احتمالاً قبلاً این عبارت را شنیده اید. درست است داده ها با ارزش ترین دارایی در جهان امروز است. شرکت هایی مانند Google ، Facebook و Amazon مدل های تجاری خود را در مورد داده ها ساخته اند.

برنامه ها ، چه وب و چه موبایل ، حول داده ها می چرخند: نمایش آن ، پردازش آن و ارسال آن به پس زمینه ها یا سیستم های خارجی. این چالش در مدیریت داده ها به طور مؤثر برای ارائه تجربیات کاربر یکپارچه است. توانایی پردازش و واکنش به داده ها در زمان واقعی به طور فزاینده ای به تمایز بین برنامه های خوب و عالی تبدیل می شود.

با ادامه مشاغل ، نیاز به پردازش داده های زمان واقعی و معماری رویداد محور آشکارتر می شود. توسعه دهندگان و معماران باید با روشهای مدرن سازگار شوند که باعث افزایش عملکرد برنامه ، مقیاس پذیری و رضایت کاربر می شود.

تاریخچه مختصری از معماری رویداد محور

معماری رویداد محور (EDA) ده ها سال است که می گذرد. این امر در سیستم های توزیع شده ، به ویژه در نرم افزار سازمانی ، جایی که ارتباطات جدا شده لازم بود ، برجسته شد. پیاده سازی های اولیه در سیستم های پیام رسانی مانند IBM MQ و اتوبوس های سرویس سازمانی (ESB) ظاهر شد و به برنامه های کاربردی اجازه می دهد تا به صورت ناهمزمان ارتباط برقرار کنند.

با افزایش خدمات میکروسرویس و برنامه های کاربردی در زمان واقعی ، الگوهای رویداد محور محبوب تر شدند. چارچوب های مدرن ، مانند Apache Kafka ، RabbitMQ و اتوبوس های رویداد مبتنی بر ابر ، پردازش رویداد مقیاس پذیر را در حوزه های مختلف امکان پذیر می کنند. در توسعه Frontend ، این الگوی از طریق کتابخانه های مدیریت دولت مانند Redux ، RXJS و Vuex تکامل یافت و رویکردهای واکنشی و اعلامی را برای به روزرسانی های UI ارائه می دهد.

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

رویکرد CRUD در مقابل معماری رویداد محور

بسیاری از برنامه های وب از رویکرد CRUD (ایجاد ، خواندن ، به روزرسانی ، حذف) پیروی می کنند: شما یک منبع را از پس زمینه دریافت می کنید ، به کاربر اجازه می دهید آن را اصلاح کند و منبع به روز شده را به عقب برگرداند. این منجر به ساختارهای UI ساخته شده در اطراف عملیات داده ها می شود – نمودارها ، ایجاد/به روزرسانی فرم ها و حذف اقدامات. به عنوان مثال ، اگر در حال ساختن یک وبلاگ هستید ، یک ذهنیت CRUD به معنای تمرکز بر ایجاد ، به روزرسانی و حذف پست ها است.

با این حال ، انسان از نظر به روزرسانی داده ها فکر نمی کند. ما از برنامه ها برای انجام سریع کارها استفاده می کنیم. آیا برای مدل سازی برنامه در مورد وظایف به جای دستکاری داده ها شهودی تر نخواهد بود؟ به عنوان مثال ، به جای به روزرسانی دستی وضعیت پست ، می توانید لیستی از پست های منتشر نشده را با یک دکمه “انتشار” نمایش دهید تا به سرعت آنها را منتشر کنید.

معماری رویداد محور (EDA) با الگوبرداری از اقدامات به عنوان رویدادهای گسسته ، این الگوی را تغییر می دهد. به جای فکر کردن از نظر اصلاحات مستقیم داده ها ، توسعه دهندگان بر ضبط اهداف کاربر تمرکز می کنند و به سیستم اجازه می دهند تا بر این اساس واکنش نشان دهد.

مدل سازی در اطراف وقایع

شروع با دستورات

برای ساده تر کردن تغییر در تفکر ، بیایید یک ترفند کوچک را معرفی کنیم: تعامل UI جداگانه از حالت UI. به جای اصلاح مستقیم داده ها ، UI فقط باید ارسال کند دستورات– اهداف استفاده کننده ای که باعث ایجاد منطق با باطن می شود. این مثال از انتشار یک رویداد را به یک موضوع RXJS جهانی در نظر بگیرید.

import { Subject } from 'rxjs';

const GlobalEvent$ = new Subject();

class ReleasePostEvent {
  public readonly type = 'POST_RELEASE_COMMAND';
  public readonly payload = new ReleasePostPayload();
}

class ReleasePostPayload {
  public postId: string;
}

const UiComponent = ({ postId }) => {
  const handleReleasePost = (postId: string) => {
      const event = new ReleasePostEvent();
      event.payload.postId = postId;
      GlobalEvent$.next(event);
  };

  return <button onClick={() => handleReleasePost(postId)}>Releasebutton>;
};

این تغییر کوچک نحوه ساختار برنامه را تغییر می دهد. به جای اصلاح مستقیم وضعیت پست ، سیستم قصد کاربر را ضبط می کند و به طور غیر همزمان بر آن عمل می کند.

با جدا کردن تغییرات حالت از تعامل UI ، برنامه ها پیشرفت های قابل توجهی در عملکرد ، کاهش مجدد مجدد و درخواست های شبکه غیر ضروری به دست می آورند.

چه اتفاقی برای این وقایع می افتد؟

این جایی است که جادو اتفاق می افتد: شما می توانید رویدادهایی را که دوست دارید انجام دهید. 🚀

به جای اینکه به طور محکم اتصال حالت در اقدامات UI تغییر کند ، وقایع باعث انعطاف پذیری بیشتر می شوند. در اینجا برخی از امکانات وجود دارد:

• مدل های ذخیره شده را در سرور به روز کنید.
• ارسال رویدادها به ابزارهای تحلیلی مانند Posthog.
• وقایع را به کنسول مرورگر در طول توسعه وارد کنید.
• گردش کار را که به سایر قسمت های برنامه اطلاع می دهد ، تحریک کنید.

تصور کنید مشتری از یک ویژگی درخواست می کند: “وقتی X اتفاق می افتد ، آیا می توانید Y را نیز انجام دهید؟” با داشتن یک مدل رویداد محور ، شما در حال حاضر آماده هستید تا بدون استفاده مجدد از کل معماری ، آن را به طور کارآمد انجام دهید.

ترکیب رویدادها برای حالت هوشمند UI

یک شاخص بارگیری را در نظر بگیرید: در یک سیستم مبتنی بر Crud ، شما به طور معمول A را تنظیم می کنید boolean پرچم در حالت برنامه. با وقایع ، شما نیازی به مدیریت صریح دولت ندارید. اگر یک دستور “بارگیری” اعزام شود و یک رویداد مربوط به “منبع بارگذاری شده” هنوز دریافت نشده باشد ، می دانید که برنامه هنوز در حال بارگیری است. منطق می تواند به این شکل باشد:

import { filter, map } from 'rxjs';

const isLoading$ = GlobalEvent$.pipe(
  filter(event => event.type === 'LOADING_COMMAND' || event.type === 'RESOURCE_LOADED'),
  map(event => event.type === 'LOADING_COMMAND')
);

این الگوی اجازه می دهد تا برنامه ها قابل پیش بینی تر باشند و از مدیریت غیر ضروری UI جلوگیری می کنند.

پایان

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

اتخاذ این طرز فکر ممکن است نیاز به تغییر در تفکر داشته باشد ، اما مزایا – مقیاس پذیری ، قابلیت حفظ و پاسخگویی – آن را به یک رویکرد قدرتمند برای توسعه جبهه مدرن تبدیل می کند.