پلتفرم‌های Runtime شروع به رقابت برای ورود به زنجیره ابزار تمام پشته می‌کنند

به محض اینکه پروژه شروع به لمس SSR، وظایف پس‌زمینه، ذخیره‌سازی شی و استقرار پیش‌نمایش به طور همزمان کند، ابزار ساخت به زودی مرزهای اصلی خود را آشکار می‌کند. vite dev مسئول اجرای صفحه، بازگرداندن مدیریت چارچوب آزمایشی، استقرار CLI برای آنلاین شدن، و افزودن یک لایه چسب به لایه سازگاری زمان اجرا است. در ابتدا، این مجموعه از چیزها قابل تحمل بود، اما زمانی که پروژه اشکال زدایی محلی و زمان اجرای تولید را از هم جدا کرد، مشکلات شروع به ظهور کردند: می توانست به صورت محلی اجرا شود، اما پیش نمایش شکست خورد. هنگامی که نسخه آداپتور ارتقا یافت، صف و اتصالات ذخیره سازی دیگر سازگار نبودند. دستورات همچنان یکسان بودند و من از قبل می دانستم که هر لایه ممکن است به طور مستقل مشکل داشته باشد.

واضح ترین تغییر در زنجیره ابزار در دو سال گذشته این است که پلت فرم دیگر از “آخرین مرحله استقرار” راضی نیست. آنها شروع به حرکت به جلو کردند و توسعه محلی، شبیه سازی زمان اجرا، بازخورد آزمایشی و دستورات انتشار را در همان لینک آوردند. با ادغام اخیر VoidZero در Cloudflare، آنچه واقعاً ارزش تماشا را دارد، خود اخبار مربوط به خرید نیست، بلکه یک سیگنال واضح تر است: پلتفرم های زمان اجرا شروع به رقابت مستقیم برای ورود به زنجیره ابزار تمام پشته کرده اند.

هنگامی که ابزار ساخت به زمان اجرا رسید، مرز پلت فرم به جلو حرکت می کند

در مفهوم سنتی، مسئولیت های یک ابزار ساخت بسیار روشن است: کد منبع را بخوانید، بسته نرم افزاری را تولید کنید و آن را برای پردازش به سیستم بعدی تحویل دهید. این تقسیم کار دیگر کافی نیست. تا زمانی که برنامه دارای مسیریابی سمت سرور، پایگاه داده ها، صف ها، ذخیره سازی اشیا و توابع لبه باشد، تکمیل ساخت به معنای تکمیل تحویل نیست. هنوز بخش کاملی از معناشناسی زمان اجرا برای تراز کردن وجود دارد.

ساده ترین مکان برای گیر کردن این نوع پروژه این نیست که آیا باندلر به اندازه کافی سریع است یا خیر، بلکه این است که آیا آنچه که این بار به صورت محلی اجرا می شود، همان زمان اجرا تنظیم شده آنلاین است یا خیر. تا زمانی که پاسخ منفی باشد، حلقه توسعه سنگین‌تر و سنگین‌تر می‌شود. برای پر کردن این شکاف، پلتفرم قطعا راهی برای کشاندن سرور توسعه دهنده به زمان اجرا خودش پیدا می کند و «نوشتن کد به صورت محلی» و «اجرای آنلاین آن» را به همان مدل تبدیل می کند.

بنابراین تغییراتی که اکنون می‌بینیم دیگر فقط این نیست که پلتفرم یک آداپتور برای یک چارچوب خاص ارائه می‌کند، بلکه به نوبه خود، CLI، پلاگین‌های زمان اجرا و محیط محلی خود پلتفرم به طور فعال به شکل زنجیره ابزاری تبدیل می‌شوند که توسعه‌دهندگان از قبل با آن آشنا هستند. به این ترتیب ورودی تغییر می کند. پلتفرم دیگر منتظر ظاهر شدن مرحله deploy نیست. قبلاً از dev، build، test و حتی فرمت اعلان خطا وارد بازار شده است.

عامل تمام اصطکاک های کوچک در زنجیره ابزار را که قابل تحمل بود بزرگ کرد.

وقتی این موضوع در مرحله توسعه صرفاً دستی قرار می گیرد، سرعت آن چندان فوری نیست. مردم به یاد خواهند آورد که کدام دستورات باید بیش از یک بار اجرا شوند، کدام خطاها فقط مشکلات محیطی هستند، و کدام آداپتورها گاهی اوقات تشنج می کنند. پس از ورود Agent، این ابهامات اساساً تبدیل به هزینه می شوند.

عامل بارها و بارها سرور توسعه دهنده را بالا می کشد، آزمایش را دوباره اجرا می کند، خطاها را می خواند، کد را تغییر می دهد و دوباره تأیید می کند. دستورات ناسازگار، لاگ های نامنظم، و رفتار زمان اجرا ناسازگار. این اشکالات کوچک که قبلاً با تجربه حل شده بودند مستقیماً به یک حلقه بی نهایت در حلقه اجرا تبدیل می شوند. البته، سرعت ساخت، سرعت تست و سرعت پرز نیز مهم هستند، اما آنچه ارزشمندتر است این است که آیا کل پیوند دارای محدودیت‌های یکپارچه است یا خیر: مجموعه یکسان CLI، مجموعه مشابهی از مدل‌های پیکربندی، همان نوع خروجی خطا، و همان رابطه نقشه‌برداری محلی و تولیدی.

به همین دلیل است که وضعیت ابزارهایی مانند Vite در حال تغییر است. آنها در ابتدا فقط مفیدترین ابزار در لایه ساخت و ساز جلو بودند، اما اکنون به تدریج به پایگاه پیش فرض عاملی تبدیل شده اند که راحت ترین وسیله برای رانندگی پایدار است. سریع، ساده و به طور گسترده سازگار است. این مزایا عمدتاً در خدمت تجربه توسعه بودند، اما اکنون مستقیماً به قابلیت اطمینان اجرا کمک می کنند. تا زمانی که پلتفرم قابلیت‌های زمان اجرا خود را به این حلقه پیش‌فرض متصل کند، نه تنها یک هدف استقرار را به دست می‌آورد، بلکه مجموعه‌ای کامل از عادات تولید و تأیید برنامه را به دست می‌آورد.

آنچه واقعاً ارزشمند است، همسویی چارچوب نیست، بلکه کسی است که گردش کار پیش‌فرض را از بین می‌برد.

تنها با نگاهی به عناوین اخبار، می‌توان چنین اقداماتی را به عنوان سرمایه‌گذاری زیست‌محیطی یا پلتفرمی که می‌خواهد ترافیک را به سمت خدمات میزبانی خود هدایت کند، تفسیر کرد. تغییرات حساس‌تر در مهندسی در واقع در سطح دیگری هستند: هنگامی که داربست پروژه پیش‌فرض، زمان اجرای محلی پیش‌فرض، حلقه آزمایش پیش‌فرض، و دستورات انتشار پیش‌فرض همگی بر روی یک زنجیره ابزار قرار می‌گیرند، واحد رقابت پلتفرم از «چه کسی ارزان‌تر است» به «چه کسی برای اولین بار نحوه ساخت برنامه را تعریف می‌کند» تغییر می‌کند.

این تفاوت کم نیست. قیمت ها را می توان به صورت افقی مقایسه کرد. هنگامی که گردش کار در انبار، اسکریپت ها، CI و عادات تیم نوشته شود، تغییر آن به ندرت آسان است. اگر پلت فرم فقط بتواند آخرین مرحله استقرار را بر عهده بگیرد، آستانه مهاجرت زیاد نیست. اگر پلتفرم کل مسیر از dev تا deploy را طی کرده باشد، مهاجرت بر محیط محلی، عادات فرمان، پیوندهای پیش نمایش، روش های اشکال زدایی و اسکریپت های اجرای Agent تأثیر می گذارد. اغلب این لایه است که واقعاً چسبندگی را تشکیل می دهد.

این موج اخیر حرکات، چیز دیگری را نیز نشان می دهد: زنجیره ابزار تمام پشته در حال بازتعریف “خنثی” است. در گذشته، بی طرفی بیشتر به این معنی بود که مستقل از چارچوب بود و روی باندلرهای مختلف اجرا می شد. امروزه الزامات بی طرفی سختگیرانه تر شده است. قابلیت های پلتفرم باید وصل شوند، اما خود زنجیره ابزار را نمی توان به یک پروتکل پلتفرم خصوصی تبدیل کرد. هر کسی که بتواند لایه انتزاعی ارائه دهنده-اگنوستیک را حفظ کند در حالی که پیاده سازی خود را به صورت پیش فرض تجربه می کند، احتمال بیشتری دارد که دور بعدی پاداش ورودی را دریافت کند.

این مسیر فقط برای تیم هایی مناسب است که به دلیل پیچیدگی تحویل عقب مانده اند

لازم نیست همه پروژه ها به این نوع بحث ورودی اهمیت دهند. برای سایت‌های ثابت، باطن‌های کوچک یا خدمات با یک فرم استقرار واحد، ادامه جداسازی ساخت، آزمایش و استقرار ممکن است ضرری نداشته باشد. هنگامی که مقیاس پروژه بزرگ باشد، این نوع مشکلات به سرعت ایجاد می شود:

• تفاوت بین توسعه محلی و زمان اجرا آنلاین به طور مکرر زمان عیب یابی را مصرف می کند
• SSR، صف وظایف، ذخیره سازی اشیا و اتصال پایگاه داده همه در یک انبار ظاهر می شوند
• تیم ها در حال حاضر به محیط های پیش نمایش، دستورات داربست و الگوهای CI برای تحویل مشترک متکی هستند.
• عوامل در کدنویسی، رفع اشکالات و آزمایش شرکت می کنند و پایداری زنجیره ابزار شروع به تأثیر مستقیم بر خروجی می کند.

در این مرحله، کمی دیر است که ابزار ساخت را به عنوان یک جزء لایه جلویی خالص در نظر بگیریم. در حال حاضر بخشی از نقطه ورود برنامه است که به زمان اجرا، سمت استقرار و سمت اجرا متصل است. ادغام VoidZero و Cloudflare فقط این موضوع را واضح‌تر می‌کند: دور بعدی رقابت پلتفرم بیشتر و بیشتر شبیه رقابت برای گردش کار پیش‌فرض خواهد شد. هر کسی که این زنجیره را به آرامی ببندد، شانس بیشتری برای تصمیم گیری در مورد اینکه برنامه ابتدا بر چه پایه ای رشد خواهد کرد، خواهد داشت.