راه‌اندازی فضای ذخیره‌سازی شخص اول Vercel با بحث‌هایی درباره قیمت‌گذاری و مدل کسب‌وکار و پتانسیل آن برای «خوردن فضای ابری از بیرون»، سر و صدایی در رسانه‌ها ایجاد کرده است.
با این حال، چیزی که توجه من را به خود جلب کرد، فصل Why now در صفحه راه اندازی آنها، به ویژه در صفحه راه اندازی آنها بود لبه اول کلمه در جمله اول:
با توجه به نیاز به عملکرد و شخصی‌سازی، فریم‌ورک‌ها در حال تبدیل شدن به سرور اول و لبه اول هستند.
به عنوان فردی که در مورد مزایای محاسبات لبه در برنامه های کاربردی وب مطمئن نیستم، کنجکاو هستم که ببینم چگونه این رویکرد لبه اول استراتژی را بهبود می بخشد.
مشکلات لبه پذیرفته شده در برنامه وب
نقطه فروش Edge زمان پاسخگویی سریعتر است که معمولاً از طریق دو عامل به دست می آید:
- زمان اجرای لبه
- موقعیت لبه
زمان اجرا لبه
Edge runtime یک لایه API سبک وزن است که بر روی موتور V8 ساخته شده است. این به طور هدفمند حداقل است و برای امنیت و سرعت طراحی شده است، بنابراین می تواند زمان شروع سرد سریع تری نسبت به عملکردهای بدون سرور ارائه دهد.
ناراحتی محدود API را کنار بگذارید، آیا شروع سرما واقعاً برای شما مشکل ایجاد می کند؟ در بحث اخیر بدون سرور، Alex DeBrie اشاره کرد که در AWS تنها 1٪ از فراخوانی های Lambad شروع سرد هستند. او همچنین یک نمونه واقعی از مشتری ارائه کرد:
27 سرما از 91 هزار فراخوانی در یک بازه زمانی 12 ساعت شروع می شود (0.03%)
علاوه بر این، به طور غیرمستقیم، نمونه های بیشتری که در مکان های مختلف اجرا می شوند ممکن است منجر به زمان شروع سرد طولانی تر شوند. برای اطلاعات بیشتر، سخنرانی او را در لینک زیر ببینید:
موقعیت لبه
این یکی در واقع بیشتر توسط عموم شناخته شده است. با اجرای منطق نزدیک به کاربر نهایی، می تواند مسافتی را که داده ها برای طی کردن نیاز دارند کاهش دهد.
با این حال، هنگامی که پایگاه داده وارد بازی می شود، این مزیت کاهش می یابد. در واقع، ممکن است حتی بدتر هم شود، زیرا مقدار و فرکانس داده های منتقل شده بین لبه و پایگاه داده معمولاً بیشتر از بین لبه و کاربر است.
تصور کنید تابع Edge شما 3 جستجوی پایگاه داده انجام می دهد و پایگاه داده شما در منطقه غرب ایالات متحده iad1 قرار دارد. حال تصور کنید که یک کاربر در استرالیا این تابع را بزند. آن کاربر به نزدیکترین مرکز داده خود در سیدنی متصل می شود و این تابع 3 پرس و جو را به پایگاه داده ارسال می کند – در سراسر اقیانوس آرام شمالی در طول یک ثانیه کامل.
Vercel یک گزینه تابع لبه منطقه ای ارائه می دهد که به کاربران امکان می دهد منطقه ای را که عملکرد آنها در آن اجرا می شود انتخاب کنند، بنابراین با قرار دادن آن در نزدیکی پایگاه داده، تاخیر کلی را کاهش می دهد.
با این حال، به نظر می‌رسد این رویکرد با وعده اصلی محاسبات لبه، یعنی اجرای منطق در نزدیکی کاربر نهایی، نه پایگاه داده، تناقض دارد.
در اصل، در حالی که سرورها در سطح جهانی توزیع شده اند، پایگاه داده ها هنوز توزیع نشده اند.
خود تدارک برای آزاد کردن پتانسیل لبه
اگرچه راه‌حل‌های پایگاه داده توزیع‌شده جغرافیایی مانند HaperDB، Turso و غیره در بازار موجود است، اما Vercel نسبت به سایرین مزیتی دارد که به هماهنگی ارتباطات داده بین نمونه لبه و پایگاه داده می‌پردازد، به خصوص اگر Vercel ارائه‌دهنده ذخیره‌سازی باشد. از آنجایی که Vercel درک عمیقی از برنامه شما دارد، می‌تواند آن را به روش‌های مختلف شبیه به مفهوم Self Provisioning بهینه کند.
به عنوان مثال، در آینده ممکن است شاهد سناریوهایی مانند موارد زیر باشیم:
- یک تابع Edge داده ها را از پایگاه داده برای ارائه یک جزء Task بازیابی می کند.
- پرس و جو خواندن در نزدیکترین نمونه پایگاه داده ماکت خوانده شده اجرا می شود.
- Vercel می‌داند که داده‌ها بر اساس ردیابی برنامه‌ها در معرض تغییرات مکرر هستند، بنابراین نتیجه را در Vercel KV ذخیره می‌کند.
- یکی دیگر از تابع Edge تلاش می کند تا همان مؤلفه Task را ارائه دهد. از آنجایی که Vercel می‌داند که داده‌ها در طول دوره زمانی تغییر نکرده‌اند، داده‌های کش شده را از نزدیکترین نمونه KV بازیابی کرده و آن را برمی‌گرداند.
به عنوان یک توسعه دهنده، امیدوارم که به زودی آن را ببینم تا بتوانیم تمرکز بیشتری روی “فقط منطق کسب و کار را بنویسید“.
صحبت از “فقط منطق کسب و کار را بنویسید“، جعبه ابزار ZenStack که ما در حال ساختن آن هستیم، همین هدف را دارد. از مدل داده های اعلامی در بالای Prisma استفاده می کند که خط مشی دسترسی و قوانین اعتبار سنجی را اضافه می کند، که از آن به طور خودکار API هایی از جمله OpenAPI، مسیر tPRC، و قلاب ها را برای شما تولید می کند. می تواند روی آنچه مهم است تمرکز کند – تجربه کاربر.
