یک دایرکتوری عمومی اساتید کاری متفاوت از پنل ادمین CMS دارد — پس یک اپ متفاوت بهش بده
یک CMS دانشگاهی ویراستاران، پیشنویسها، تأییدیهها و کنترل دسترسی را برای کارکنانی مدیریت میکند که مدام لاگین میکنند. یک دایرکتوری عمومی اساتید بازدیدکنندههای ناشناس، جستوجو، و ترافیک سنگین-خواندنی را مدیریت میکند که هر وقت یک کاتالوگ درس منتشر میشود اوج میگیرد. چسباندن کار دوم به کار اول بهعنوان «فقط یک نوع محتوای دیگر» تا زمانی جواب میدهد که الگوهای ترافیک و حالتهای خرابی شروع به تداخل با هم کنند. فنپروفایل سرویس مستقل Django REST Framework خودش است، جدا از CMSی که همهچیز دیگر را مدیریت میکند.
چرا فقط شکل ترافیک، یک اپ جدا را توجیه میکند
یک دایرکتوری عمومی سنگین-خواندنی و ناگهانی است — شروع یک ترم، یک اشارهی رسانهای، یک دانشجوی آینده که بر اساس دانشکده جستوجو میکند، همه میتوانند موج ترافیک خواندنی ناشناس بفرستند. سمت ادمین یک CMS سنگین-نوشتنی اما کمحجم است، از تعداد کمی ویراستار لاگینکرده. سرو کردن هر دو از یک اپلیکیشن یعنی یا برای اوجهای نادر سمت ادمین بیشازحد تدارک دیدن، یا برای اوجهای واقعی سمت عمومی کمتدارک دیدن — یک REST API اختصاصی برای پروفایلها میتواند به شرایط خودش scale، کش، و rate-limit شود.
این جدایی واقعاً چه شکلی است
- یک مرز دسترسی تمیز — داده پروفایل عمومی (نام، عکس، انتشارات، دانشکده) از طراحی فقط-خواندنی و ناشناس است؛ هیچ مسیری از جستوجوی دایرکتوری به نشست یک ویراستار وجود ندارد.
- جستوجو و فیلتر بهعنوان ویژگی درجهیک، نه یک فکر بعدی چسباندهشده به یک جعبه جستوجوی عمومی CMS — بر اساس نام، دانشکده، یا حوزه پژوهشی، چون این کل نکتهی اپ است.
- ساختار دانشکده بهعنوان داده واقعی، نه یک تگ — مرور بر اساس دانشکدهها و گروهها منعکسکنندهی این است که یک دانشگاه واقعاً افراد را چطور سازماندهی میکند، نه اینکه تاکسونومی دستهبندی یک CMS اتفاقاً چطور تنظیم شده.
درس کلی
«فقط یک نوع صفحه دیگر است» برای محتوای واقعاً مشابه انتخاب درستی است. یک دایرکتوری رو-به-عموم که مخاطب، الگوی ترافیک، و مدل دسترسی کاملاً متفاوتی از CMS اطرافش دارد معمولاً این نیست — یک کار متفاوت است که همان نام دامنه را پوشیده، و سرویس خودش را سزاوار است.
