محتوا و APIهای اپلیکیشن موبایل را با یک CDN سریع‌تر کنید

چه چیزهایی لازم دارید (و یک CDN برای یک اپلیکیشن چه می‌کند)

شما یک اپلیکیشن موبایل دارید — iOS، Android یا هر دو — که در زمان اجرا تصاویر و رسانه، شاید بسته‌های asset دانلودی، دانلود می‌کند و برای داده‌هایش با یک HTTP API صحبت می‌کند. و یک حساب cdn.com.tr دارید. کل راه‌اندازی همین است. یک CDN جلوی هر چیزی که اپلیکیشن شما روی HTTP می‌گیرد می‌نشیند و آن را از یک edge نزدیک به کاربر، روی HTTPS، سرو می‌کند و بار را جذب می‌کند.

ابتدا یک مرز صادقانه: خود باینری اپلیکیشن — همان .ipa یا .apk که منتشر می‌کنید — توسط App Store و Play Store روی شبکه‌های خودشان توزیع می‌شود، پس یک CDN جایگزین آن نمی‌شود. آنچه یک CDN شتاب می‌دهد هر چیزی است که اپلیکیشن در زمان اجرا می‌کشد: تصاویر، رسانه، asset bundleها، remote config و API شما. (اگر بیلدها را هم مستقیم توزیع می‌کنید — یک APK سازمانی یا sideload‌شده — می‌توانید آن‌ها را هم از storage مربوط به CDN سرو کنید؛ راهنمای توزیع بازی را ببینید.)

تصاویر، رسانه و بسته‌های asset را از edge سرو کنید

حجیم‌ترین چیزی که یک اپلیکیشن دانلود می‌کند محتواست: تصاویر پروفایل و محصول، thumbnailها، صدا و ویدیو، و بسته‌های asset یا مرحله‌های دانلودی. آن محتوا را روی storage مربوط به CDN بگذارید (یا پشت یک pull CDN جلوی سرور رسانه‌ی موجود خود) و اپلیکیشن هر فایل را به‌جای یک مبدأ واحد که ممکن است یک قاره دورتر باشد، از نزدیک‌ترین edge می‌گیرد. نخستین اجرا و صفحه‌های پرمحتوا همه‌جا سریع بارگذاری می‌شوند و مبدأ شما دیگر یک تصویر را ده‌هزار بار سرو نمی‌کند.

مانند هر کش کردن روی edge، مسیر هر چیزی را که می‌تواند تغییر کند نسخه‌دار کنید — /assets/v42/pack.bin یا یک hash بیلد در URL — تا یک نسخه‌ی تازه یک URL تازه باشد که هرگز کهنه نیست، و فایل‌های نسخه‌دار را محکم کش کنید. محتوایی که واقعاً هرگز تغییر نمی‌کند را می‌توان روی edge عملاً برای همیشه کش کرد.

پاسخ‌های API خود را روی edge کش کنید (جایی که امن است)

بخش زیادی از آنچه یک API موبایل برمی‌گرداند برای هر کاربر یکسان است و به‌کندی تغییر می‌کند: کاتالوگ، feed خانه، leaderboard، config عمومی. آن پاسخ‌ها را می‌توان روی edge با یک TTL کوتاه کش کرد، پس ده‌هزار باز شدن اپلیکیشن در یک دقیقه به مشتی درخواست به مبدأ فرو می‌ریزد در حالی که هر کاربر همچنان پاسخی از یک edge نزدیک می‌گیرد. قاعده ساده است: آنچه مشترک و کندتغییر است را کش کنید و آنچه شخصی است را هرگز کش نکنید.

پاسخ‌های مشترک و قابل‌کش را با یک Cache-Control عمومی و یک max-age منطقی (یا s-maxage برای edge) نشانه‌گذاری کنید، و هر چیز مخصوص کاربر یا احرازهویت‌شده را private / no-store علامت بزنید تا هرگز کش یا به شخص اشتباه سرو نشود. وقتی داده‌ی زیربنایی تغییر می‌کند، مسیر کش‌شده را purge کنید تا درخواست بعدی آن را تازه کند. همین ترکیب سرعت edge را روی نقاط داغ و مشترک به شما می‌دهد بدون آنکه هرگز داده‌ی یک کاربر به کاربر دیگر درز کند.

Cache-Control: پاسخ‌های مشترک در برابر مخصوص هر کاربر

# پاسخ مشترک و کندتغییر (کاتالوگ، config عمومی، feed)
Cache-Control: public, s-maxage=60, stale-while-revalidate=30

# پاسخ مخصوص هر کاربر یا احرازهویت‌شده — هرگز این را کش نکنید
Cache-Control: private, no-store

remote config و feature flagها را سریع تحویل دهید

بیشتر اپلیکیشن‌ها هنگام اجرا یک سند کوچک پیکربندی یا feature-flag می‌گیرند — چه چیزی نمایش داده شود، کاربر در کدام آزمایش است، kill-switch برای ویژگی‌های خراب. آن JSON را روی CDN با یک کش کوتاه میزبانی کنید. چون از edge سرو می‌شود، هر اپلیکیشن آن را هنگام راه‌اندازی سریع می‌گیرد؛ و چون می‌توانید آن را purge کنید، جابه‌جا کردن یک flag یا خاموش کردن یک ویژگی خراب در سراسر پایگاه کاربران شما آنی است، بدون عرضه‌ی یک به‌روزرسانی اپلیکیشن.

آن را کوچک نگه دارید و کوتاه کش کنید (چند ده ثانیه تا چند دقیقه) تا یک تغییر سریع منتشر شود، و هنگام انتشار purge کنید وقتی به‌طور فوری زنده‌اش می‌خواهید. این امن‌ترین اهرمی است که برای یک اپلیکیشن زنده دارید: نه بازبینی فروشگاه، نه به‌روزرسانی اجباری — فقط یک سند سرو‌شده از edge که هر وقت خواستید تغییرش می‌دهید.

remote-config.json سرو‌شده از CDN

{
  "min_supported_version": "3.2.0",
  "features": {
    "new_checkout": true,
    "live_events": false
  },
  "banner": { "enabled": true, "url": "https://cdn.yourapp.com/img/promo-v7.webp" }
}

تصاویر را برای صفحه‌های گوشی و شبکه‌ی سلولی بهینه کنید

گوشی‌ها صفحه‌های کوچک و اغلب اتصال‌های کند و اندازه‌گیری‌شده دارند، پس فرستادن تصاویر با ابعاد رومیزی به آن‌ها پهنای باند و زمان را هدر می‌دهد. فرمت‌های مدرن — WebP یا AVIF — را سرو کنید و تصاویر را به اندازه‌ی دستگاه درآورید به‌جای فرستادن یک عکس ۳۰۰۰ پیکسلی به یک جای ۴۰۰ پیکسلی. تصاویر کوچک‌تر و درست‌اندازه یعنی صفحه‌ها سریع‌تر رندر می‌شوند و کاربران روی شبکه‌ی سلولی داده‌ی کمتری خرج می‌کنند، که مستقیماً حس پاسخگویی اپلیکیشن را بهتر می‌کند.

edge می‌تواند این کار را برای شما انجام دهد: image optimization و تغییر اندازه‌ی درجا یک نسخه‌ی اصلی با وضوح بالا را در هر درخواست به فرمت و ابعاد درست تبدیل می‌کند، روی edge کش‌شده تا کار یک‌بار انجام شود. آن را با تحویل asset بالا جفت کنید و تصاویر اپلیکیشن شما هم به کاربر نزدیک‌اند و هم بزرگ‌تر از آنچه لازم است نیستند.

از API خود محافظت کنید و نوسان‌ها را مدیریت کنید

یک بک‌اند موبایل به‌صورت انفجاری ضربه می‌خورد: یک انتشار، یک push notification، یک کمپین یا یک لحظه‌ی وایرال هر اپلیکیشن را همزمان به API شما می‌فرستد — و کلاینت‌های موبایل با retry تهاجمی لحظه‌ای که یک درخواست شکست می‌خورد اوضاع را بدتر می‌کنند و یک نوسان کوچک را به طوفان تبدیل می‌کنند. کش کردن روی edge پیشاپیش نوسان خواندن را روی نقاط مشترک شما جذب می‌کند، پس سیل درخواست‌های یکسان به‌جای مبدأ شما توسط شبکه پاسخ داده می‌شود.

روی آن، WAF و حفاظت DDoS مربوط به CDN را جلوی API خود بگذارید و rate limiting اضافه کنید تا هیچ کلاینت یا IP واحدی نتواند login، signup یا یک نقطه‌ی پرهزینه را بکوبد. مبدأ واقعی شما پشت edge پنهان می‌ماند، پس هم هجوم مشروع و هم حملات آشکار روی شبکه‌ای فرود می‌آیند که برای جذب آن‌ها ساخته شده. نتیجه یک اپلیکیشن است که در روزی که بیش از همه به آن نیاز دارید پاسخگو می‌ماند.

اپلیکیشن‌هایی که به این تکیه می‌کنند