برنامه های وب مدرن فقط مجموعه ای از مؤلفه ها و API ها نیستند. آنها اکوسیستم های پویا و حساس به عملکرد هستند که نیاز به مقیاس در تیم ها ، ویژگی ها و سیستم عامل ها دارند. و این دقیقاً همان جایی است که معماری Frontend بازی می کند.
در این پست ، آنچه را که برای معماری سیستم های جلوی مقیاس پذیر است که در آزمون رشد تیم ، ویژگی های پراکندگی و انتظارات کاربر قرار دارند ، باز می کنیم.
“معماری جلوی مقیاس” به چه معنی است؟
مقیاس پذیری در مهندسی Frontend مربوط به سیستم های ساختمانی است که:
- توسعه ویژگی های سریع و موازی را پشتیبانی کنید
- مقاومت در برابر کد های بزرگ و تعداد مشارکت کنندگان
- الگوهای سازگار و قابل حفظ را ارائه دهید
- تحت بار کاربر سنگین عملکرد خوبی داشته باشید
به ترکیبی از تکه های فنی ، تفکر UX و بلوغ DevOps نیاز دارد. این فقط مربوط به نوشتن کد خوب نیست – این در مورد این است که دیگران بتوانند همین کار را در مقیاس انجام دهند.
“یک جلو مقیاس پذیر فقط مربوط به عملکرد نیست. این مربوط به افراد ، فرآیند و پلتفرم است.”
ستون های کلیدی سیستم های جلوی مقیاس پذیر
1 معماری مؤلفه مدولار
یک رویکرد مدولار به مؤلفه ها به شما کمک می کند تا بدون کپی کردن تلاش یا ایجاد ناسازگاری سبک ، توسعه UI را در بین تیم ها مقیاس بندی کنید. آجرهای LEGO را فکر کنید – نه برج های Jenga. با تجزیه UI خود به مؤلفه های اتمی و قابل استفاده مجدد ، سیستمی را ایجاد می کنید که با گذشت زمان ، نگهداری ، آزمایش و تکامل آن آسان تر است.
با استفاده از اصول طراحی اتمی ، می توانید اجزای سازنده را در لایه هایی مانند اتم (دکمه ها ، ورودی ها) ، مولکول ها (زمینه های فرم) و ارگانیسم ها (هدر ، پاورقی) سازماندهی کنید. هر لایه برای پشتیبانی از انعطاف پذیری و ترکیب ، روی قسمت قبلی ساخته شده است.
// A simple, stateless Button component
const Button = ({ label, onClick }) => (
<button className="btn" onClick={onClick}>
{label}
</button>
);
2 مدیریت دولتی مقیاس پذیر
حالت ستون فقرات منطق برنامه شما است. با رشد برنامه شما ، رسیدگی به حالت نادرست می تواند به یک آشفتگی غیرقابل کنترل تبدیل شود. یک معماری مقیاس پذیر نگرانی ها را با بیان واضح بین وضعیت محلی UI ، وضعیت برنامه جهانی و داده های سمت سرور از هم جدا می کند.
استفاده کردن useState وت useReducer برای منطق UI جدا شده. برای وضعیت گسترده برنامه ، به راه حل هایی مانند Zustand یا Redux Toolkit با انتخاب کنندگان مناسب و میان افزار تکیه دهید. Server State سزاوار ابزارهای اختصاصی مانند REACT QUERY یا SWR است که بدون استفاده مجدد از چرخ ، ذخیره سازی ، تجدید نظر و صفحه بندی را کنترل می کنند.
// Local state
const [count, setCount] = useState(0);
// Server state (with React Query)
const { data, isLoading } = useQuery('todos', fetchTodos);
3 سیستم های طراحی و قوام UI
یک سیستم طراحی قوی تضمین می کند که تیم ها UI را با برندسازی مداوم ، دسترسی و قابلیت استفاده بسازند. این فقط یک پرونده FIGMA نیست – این یک مستند زنده از زبان رابط شماست.
مضامین مبتنی بر توکن به شما امکان می دهد سبک های انتزاعی و استفاده مجدد مانند رنگ ، فاصله و تایپوگرافی را انتزاعی و استفاده مجدد کنید.
شما می توانید این کار را با یک کتابخانه مشترک قطعات مشترک و بررسی های دسترسی برای اجرای یک تجربه کاربری مداوم در همه تیم ها و ویژگی ها ترکیب کنید.
ابزارها: Tailwind CSS ، Radix UI ، UI بدون سر ، UI Chakra ، کتاب داستان
4 مالکیت Monorepo & Code
به عنوان مقیاس org مهندسی شما ، تعداد برنامه ها ، بسته ها و مشارکت کنندگان نیز به همین ترتیب انجام می شود. یک ساختار monorepo (از طریق NX یا TurborePO) به شما امکان می دهد برنامه ها و کتابخانه های مرتبط را تحت یک مخزن واحد با مرزهای اجباری و ذخیره سازی برای ساختهای سریع تر گروه بندی کنید.
با این کار اهمیت مالکیت کد به وجود می آید. نگهدارنده یا تیم های ویژگی را به قسمت های خاصی از پایگاه کد اختصاص دهید. این وضوح مسئولیت پذیری را ارتقا می بخشد و تضمین می کند که تغییرات از طریق داوران مناسب پیش می رود.
5 عملکرد و مشاهده
مقیاس پذیری فقط مربوط به معماری نیست – سیستم شما باید در مقیاس اجرا شود. برای جلوگیری از ارائه تنگناها ، از تقسیم کد ، بارگذاری تنبل و استراتژی های یادبود استفاده کنید.
به همان اندازه مهم است که مشاهده. نظارت واقعی کاربر (RUM) ، بودجه عملکرد و ردیابی خطا به شما بینشی می دهد که کاربران واقعی را تجربه می کنند. منتظر نباشید که کسی یک مسئله را گزارش کند – به طرز فجیعی آنها را تشخیص داده و برطرف کنید.
// Code-splitting using dynamic import
const LazyChart = React.lazy(() => import('./Chart'));
<React.Suspense fallback={<Spinner />}>
<LazyChart />
</React.Suspense>
6 خطوط لوله اتوماسیون و CI/CD
اتوماسیون در هنگام رشد تیم ها شبکه ایمنی شماست. قلاب های قبل از آن با استفاده از husky وت lint-staged اطمینان حاصل کنید که کد بد حتی وارد repo شما نمی شود. چک های PR خودکار تأیید می کنند که کد شما ساخته می شود ، آزمایش می کند و از استانداردها پیروی می کند.
آزمایش رگرسیون بصری (با استفاده از کروماتیک یا پرسی) باعث شکستن UI می شود. محیط های پیش نمایش به ذینفعان اجازه می دهد تا قبل از ادغام ، ویژگی ها را تأیید کنند-ضروری در ارگان های سنگین محصول.
خلاصه: اصول زندگی توسط
به recap:
- همه چیز را با استفاده مجدد در ذهن مؤثر کنید
- برای کاهش هرج و مرج از معماری حالت لایه بندی شده استفاده کنید
- از طراحی اول دسترسی با یک سیستم مستند پیروی کنید
- کد را تقسیم کنید و عملکرد را به عنوان یک شهروند درجه یک مدیریت کنید
- آنچه را که بیشتر از آن می ترسید خودکار کنید
معماری جلوی مقیاس یک کار یک بار نیست-این یک عمل مداوم است. بهترین سیستم ها با کمال میل و بدون کند کردن تیم ها یا به خطر انداختن تجربه کاربر رشد می کنند.
منابع اضافی
