سیستم افزونه تقویت – انجمن DEV

سیستم پلاگین یکی از بسیاری از ویژگی های هیجان انگیز منتشر شده در نسخه 1.0.0 Amplication است. به عنوان یک شرکت منبع باز، ما بر اساس نیازهای جامعه توسعه دهندگان هدایت می شویم. ایده توسعه یک سیستم پلاگین از یک تماس خاص از توسعه دهندگان ناشی شد: برای داشتن انعطاف پذیری بیشتر در برنامه تولید شده.

برخی از موضوعات مورد بحث در میان توسعه دهندگان نرم افزار امروزه بهترین شیوه ها، اصول (مانند SOLID، DRY، و YAGNI) و اینکه آیا از چارچوب ها و کتابخانه های صاحب نظر استفاده شود یا خیر است. کسانی که با نرم افزار کاربردی تولید شده ما آشنا هستند احتمالاً متوجه شده اند که این نرم افزار بسیار صاحب نظر است و از بهترین شیوه های NestJS پیروی می کند. با این حال، ما می‌خواهیم پلتفرم ما پاسخگوی همه باشد – و می‌خواهیم پاسخگوی جامعه توسعه‌دهندگان باشیم. بنابراین، ما نشستیم تا بهترین شیوه‌ها را برای فعال کردن گسترش و دستکاری برنامه‌های کاربردی تولید شده به منظور ایجاد نظر کمتر و انعطاف‌پذیرتر کردن آن‌ها در نظر بگیریم. نتیجه؟ راه حل جدید و جامعه محور Amplication برای معماری سیستم پلاگین.

بیایید به این بپردازیم که پلاگین ها چیست، بررسی کنیم که Amplication چگونه آنها را مدیریت می کند، نحوه ساخت آنها را به نمایش بگذاریم، و برخی از ملاحظات مورد نیاز برای ایجاد یک افزونه موثر و بدون خطا را بررسی کنیم.

پلاگین ها در Amplication

پلاگین ها نرم افزارهای اضافه شده ای هستند که امکان سفارشی سازی و بهبود برنامه های کامپیوتری، برنامه های کاربردی و مرورگرهای وب را فراهم می کنند. سیستم پلاگین Amplication به ما امکان می دهد ویژگی های جدید اضافه کنیم یا رفتارهای برنامه تولید شده خود را دستکاری کنیم. تولیدکننده خدمات داده ما (DSG) همه داده‌هایی را که کاربر در UI یا CLI پیکربندی می‌کند، از جمله نهادها و فیلدها، نقش‌ها، مجوزها و تنظیمات سرویس‌ها جمع‌آوری می‌کند. سپس DSG از این مقادیر به عنوان ورودی برای توابع خود استفاده می کند. هر تابع مسئول تولید کد در یک منطقه خاص است، مانند CreateEntityController، CreateEnitityResolver، CreateServerDockerCompose، و بیشتر.

برای ساختن این چارچوب برای افزونه‌ها، ما هر تابع را در اختیار توسعه‌دهندگان افزونه قرار داده‌ایم و تمام داده‌ها و زمینه‌های شناخته شده در آن نقطه را ارائه می‌کنیم و به سیستم اجازه می‌دهیم داده‌ها را دستکاری کرده و بر نتایج رویداد تأثیر بگذارد.

توابع قبل و بعد

همه رویدادها یک رابط مشترک دارند که شامل دو عملکرد است: قبل و بعد. این توابع مسئول مراحل مختلف چرخه حیات یک رویداد هستند. در اینجا چگونه به نظر می رسند:

export interface PluginEventType<T extends EventParams> {
  before?: PluginBeforeEvent<T>;
  after?: PluginAfterEvent<T>;
}

برای هر رویداد، نوع EventParams متفاوت است و دسترسی به داده های مربوطه را برای رویداد خاص فراهم می کند.

export interface EventParams {}

export type PluginBeforeEvent<T extends EventParams> = (
  dsgContext: DsgContext,
  eventParams: T
) => Promisable<T>;

export type PluginAfterEvent<T extends EventParams> = (
  dsgContext: DsgContext,
  eventParams: T,
  modules: Module[]
) => Promisable<Module[]>;

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

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

هنگامی که هیچ رویداد چرخه حیات ارائه نشده باشد و هیچ پارامتری تغییر نکند، آمپلیشن به تولید کد به صورت عادی ادامه خواهد داد.

توابع سودمند: skipDefaultBehavior

علاوه بر پارامترهای خاص مورد نیاز برای هر رویداد، ما همچنین یک شی زمینه کلی ارائه می‌کنیم که می‌تواند به توسعه‌دهنده کمک کند به سایر داده‌های مورد نیاز خود، مانند فهرست موجودیت‌ها، نقش‌ها، سایر خدمات در پروژه، و همه فایل‌های تولید شده تا کنون دسترسی پیدا کند. . همچنین دارای یک util دارایی متشکل از توابع ابزار. یکی از این توابع سودمند است skipDefaultBehavior.

context.utils.skipDefaultBehavior = true;

رفتار پیش‌فرض وقتی اجرا نمی‌شود skipDefaultBehavior تنظیم شده است true در تابع قبل، بنابراین توسعه دهندگان باید منطق خود را ارائه دهند. توسعه دهندگان می توانند این کار را پس از پرش در توابع قبل یا بعد انجام دهند.

مهم است که به یاد داشته باشید که استفاده از skipDefaultBehavior بدون ارائه یک عملکرد جایگزین می‌تواند باعث رفتار غیرمنتظره شود—به عنوان مثال، رویداد نادیده گرفته شده می‌تواند فایل‌های وارد شده توسط فایل‌های دیگر را ایجاد کند، بنابراین باید عاقلانه و با دقت از آن استفاده کرد. همانطور که عمو بن گفت: “با قدرت زیاد مسئولیت بزرگی به همراه دارد.”

سلسله مراتب رویدادها

در نظر گرفتن ترتیب اجرای رویدادها در DSG ضروری است (شکل 1.) دو رویداد اصلی در سرویس DSG وجود دارد: یکی برای تولید سرور و دیگری برای ایجاد admin-ui.

این رویدادهای اصلی شامل سایر رویدادهای فرعی برای ایجاد سرور و فایل‌های admin-ui است. (در کد منبع Amplication، گاهی اوقات به این فایل ها ماژول گفته می شود.) رویدادهای داخلی سرور و رویدادهای admin-ui همزمان هستند، بنابراین ترتیب اجرای کد افزونه باید در هنگام توسعه آنها در نظر گرفته شود.

بیایید این تصویر را به سه نوع جزء تقسیم کنیم:

• یک رویداد DSG منفرد با بسته بندی افزونه با یک مستطیل بدون فلش رو به جلو نشان داده می شود. عنوان نشان دهنده نام رویداد مربوطه است.
• “Create message broker” تابعی با بسته بندی افزونه است که سایر رویدادهای ایجاد واسطه پیام را اجرا می کند. مانند دسته قبلی، عنوان با نام رویداد مطابقت دارد.
• ایجاد منابع (در یک مستطیل خاکستری “برای هر موجودیت”) تابعی است که رویدادهای ایجاد منابع مانند سرویس ها، کنترل کننده ها و حل کننده ها را اجرا می کند.

یک نفس سریع

بیایید قبل از اینکه به نحوه توسعه یک افزونه برویم کمی نفس بکشیم. نفس عمیق، 1… 2… 3… 4… 5…، نفس عمیق بیرون، 1… 2… 3… 4… 5…

alt=”یک تمرین تنفسی”
عرض = “287” ارتفاع = “311”
بارگیری = تنبل
style=”margin-left: auto; margin-right: auto;”>

اگر به سیستم افزونه Amplication علاقه مند هستید و می خواهید بیشتر از آنچه این پلتفرم ارائه می دهد ببینید. در این صورت، از شما دعوت می کنیم تا مخزن Amplication GitHub را بررسی کنید.

ما پلتفرم خود را با فناوری های منبع باز ساخته ایم و حمایت شما برای موفقیت ما بسیار مهم است. اگر پلتفرم ما را مفید می‌دانید، بسیار سپاسگزار خواهیم بود اگر لحظه‌ای به ما در GitHub 🌟 اختصاص دهید. حمایت شما به ما کمک می کند تا به توسعه و بهبود پلت فرم برای همه ادامه دهیم. علاوه بر این، اگر می‌خواهید در پروژه مشارکت کنید، از درخواست‌ها و مشکلات موجود در مخزن GitHub خود استقبال می‌کنیم. ما از حمایت شما قدردانی می کنیم!

در حال توسعه یک پلاگین

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

فرآیند توسعه آمپلیکاسیون

در این بخش آخر، می‌خواهیم فرآیند توسعه افزونه مورد استفاده تیم ما در Amplication را به اشتراک بگذاریم. قبل از شروع توسعه، مراحل زیر را انجام می دهیم:

1. یک سرویس با Amplication ایجاد کنید.
2. تغییرات مورد نیاز را به صورت دستی روی کد منبع حاصل که Amplication ایجاد کرده اعمال کنید:
   • هر گونه عملکرد گم شده را اضافه کنید.
   • عملکرد موجود را دستکاری کنید.
3. برای مشاهده تغییرات یک PR ایجاد کنید و از نتیجه برای طراحی افزونه استفاده کنید.
   • تعیین کنید که کدام رویداد مورد نیاز است. به عنوان مثال، اگر از یک بسته جدید npm استفاده می کنیم، باید فایل package.json را به روز کنیم.
   • نحوه استفاده از رویدادها با عملکردهای قبل و بعد از چرخه حیات را تعیین کنید. ما آن را میدانیم CreateServerPackageJson یکی از اولین رویدادهایی است که اجرا می شود، بنابراین ما باید آن رویداد را در تابع قبل ضبط کنیم و بسته جدید npm را اضافه کنیم.
   • خطاهای استثنایی ناشی از عملکرد یا محدودیت های افزونه را در نظر بگیرید.

گردش کار توسعه پلاگین در عمل

برای نشان دادن این گردش کار توسعه، اجازه دهید به پلاگین MySQL نگاه کنیم. اما ابتدا، اجازه دهید عملکرد یک اتصال پایگاه داده را بررسی کنیم:

1. ما قبلاً قابلیت اتصال پایگاه داده را با استفاده از Prisma به عنوان یک ORM داریم.
2. Prisma از MySQL به عنوان یک ارائه دهنده پشتیبانی می کند. بر این اساس ارائه دهنده طرح پریسما را تغییر دهید.
3. ما از متغیرهای محیطی برای URL پایگاه داده طرحواره Prisma و مقادیر DockerCompose استفاده می کنیم. ما متغیرهای محیطی و مقادیر آنها را در صورت نیاز تغییر می دهیم.

حالا بیایید مراحل بالا را به رویدادها ترجمه کنیم:

در طول مرحله 3 گردش کار توسعه، با یک رفتار غیرمنتظره مواجه شدیم: ارائه‌دهنده MySQL Prisma از لیست‌هایی از انواع اولیه پشتیبانی نمی‌کند. در تابع زیر (beforeCreateServer)، این محدودیت را در Prisma با پرتاب یک خطا در زمانی که یکی از فیلدهای موجودیت ها از نوع MultiSelectOptionSet. در اینجا یک مثال از یک مورد استفاده است که در آن افزونه باید خطا ایجاد کند:

CreateServerDotEnv: before

در این رویداد، ما پارامترهای رویداد خود، به ویژه متغیرهای محیطی برای پایگاه داده MySQL را ارسال می کنیم. در نتیجه، فایل .env با متغیرهای پیش فرضی که قبلاً در اختیار دارد و متغیرهای محیطی ما ایجاد می شود.

CreateServerDockerCompose: before

ما همچنین پارامترهای رویداد خود را برای این رویداد ارسال می کنیم، این بار ویژگی ها و مقادیر YAML برای پایگاه داده MySQL. در نتیجه، فایل docker-compse.yml تولید می‌شود تا ویژگی‌های MySQL جایگزین ویژگی‌های PostgreSQL شوند.

CreateServerDockerComposeDB: before

این رویداد مسئول تولید فایل docker-compose.db.yml است که حاوی تصویر docker پایگاه داده PostgreSQL است. در اینجا ما یک مثال عالی داریم skipDefaultBehavior استفاده ما می‌توانیم از تولید این فایل بگذریم و بعداً در تابع after، عملکردهای مختلفی را ارائه کنیم – در این مورد، یک فایل جداگانه.

CreateServerDockerComposeDB: after

پس از پرش از رفتار پیش‌فرض در تابع قبل، فایل docker-compose.db.yml خود را در این رویداد ارائه می‌کنیم.

CreatePrismaSchema: before

این رویداد مسئول دستکاری بخش زیر از طرحواره Prisma است:

EventParams

ما از پارامترهای رویداد برای موارد زیر استفاده می کنیم:

• نام منبع داده را از Postgres به MySQL تغییر دهید
• ارائه دهنده را از Postgresql به MySQL تغییر دهید

(CreateServerDotEnv رسیدگی می کند DB_URL)

خلاصه و نتیجه گیری

سیستم پلاگین Amplication به توسعه دهندگان این امکان را می دهد که فرآیند تولید کد را گسترش دهند یا تغییر دهند تا از ویژگی های اضافی پشتیبانی کنند یا هر گونه تغییری در “طعم” پیش فرض برنامه تولید شده ایجاد کنند. این یک راه عالی برای جامعه توسعه دهندگان ما است تا پلتفرم خود را با خیال راحت گسترش دهند و کاربران ما کد تولید شده را با نیازهای خاص خود تنظیم کنند. هنگام نوشتن این خطوط، بیش از دوجین افزونه در حال حاضر برای Amplication موجود است و جامعه و کاربران ما در حال حاضر در حال توسعه سایر افزونه ها هستند.

در این وبلاگ، پلاگین ها و معماری آنها را بررسی کردیم و یک مثال واقعی از ایجاد یک پلاگین جدید ارائه دادیم.

اگر ایده پشت پلاگین های ما را دوست داشتید و می خواهید آن را بنویسید، لطفاً به انجمن Discord ما بپیوندید، جایی که می توانید از اعضای انجمن و تیم اصلی ما کمک بگیرید. ما دوستانه هستیم و دوست داریم به جامعه کمک کنیم تا افزونه های مفیدتری تولید کند. اگر پلاگینی را توسعه دهید و ما آن را منتشر کنیم، حتماً Swag جالبی را برای شما ارسال خواهیم کرد 🙂.