ساخت دموی کامل بدون بک‌اند: شبیه‌سازی API با axios-mock-adapter
می‌خواستم دموی ClassBan را عمومی کنم ولی نمی‌خواستم دیتابیس یا سرور نگه دارم و مهم‌تر، نمی‌خواستم داده‌ی واقعی یا کلید پیامک نزدیک دمو باشد. راه‌حل: کل بک‌اند را داخل مرورگر شبیه‌سازی کردم.
ایده
تمام صفحه‌های ClassBan درخواست‌ها را از طریق یک نمونه‌ی مشترک axios می‌فرستند. اگر آن نمونه را با axios-mock-adapter رهگیری کنم، می‌توانم برای هر آدرس (مثل /api/students یا /api/absences) پاسخ را خودم بسازم. هیچ صفحه‌ای عوض نمی‌شود؛ رابط واقعی دست‌نخورده می‌ماند.
چه چیزی شبیه‌سازی شد
- ورود با نام کاربری و ورود با شماره و کد تأیید ثابت،
- دانش‌آموزان، معلمان، غیبت‌ها و قالب‌های پیام (CRUD کامل)،
- ارسال پیامک (فقط در لاگ ثبت می‌شود؛ هیچ پیامکی نمی‌رود)،
- کاربران و نقش‌ها با همان محدودیت‌های نسخه‌ی اصلی (مثلاً معاون صفحه‌ی مدیریت کاربران را نمی‌بیند)،
- آمار داشبورد.
داده‌ها در حافظه و در sessionStorage نگه داشته می‌شوند. هر ۳۰ دقیقه و با دکمه‌ی «ریست» به حالت اول برمی‌گردند.
داده‌ی فرضی
دانش‌آموزان با نام‌های فارسی ساختگی از ترکیب تصادفی نام و نام‌خانوادگی ساخته می‌شوند؛ شماره‌ها از الگوی غیرواقعی 0900000xxxx. نکته‌ی کوچک: مولد تصادفی با seed ثابت است تا هر بازدیدکننده همان مجموعه‌ی اولیه را ببیند و ریست قابل‌پیش‌بینی باشد.
مزایا
- دیپلوی فقط یک build استاتیک است.
- هیچ دیتابیس، کلید یا داده‌ی واقعی در کار نیست.
- هر بازدیدکننده نسخه‌ی خودش را دارد و نمی‌تواند به دیگران آسیب بزند.
محدودیت‌ها (صادقانه)
- منطق بک‌اند دوبار نوشته می‌شود (یک‌بار واقعی، یک‌بار شبیه‌ساز)؛ ممکن است با هم ناهمخوان شوند.
- هر چیزی که فراخوانی مستقیم
fetchباشد، توسط axios-mock-adapter رهگیری نمی‌شود. در ClassBan صفحه‌ی «فراموشی رمز» ازfetchمستقیم استفاده می‌کرد و باید جداگانه اصلاح می‌شد. - امنیت واقعی را تست نمی‌کند؛ دمو نشان‌دهنده‌ی رابط است، نه سرور.
- نمودار «روند ۷ روز اخیر» فعلاً داده‌ی روزانه ندارد و صاف می‌ماند.
نتیجه
اگر هدف نمایش رابط و جریان کار است، شبیه‌سازی API ارزان‌ترین راه است. اگر هدف تست رفتار واقعی سرور است، نه. دموی کامل را در classban.primlagic.ir می‌توانید ببینید؛ معرفی محصول در صفحه‌ی ClassBan است.