แพลตฟอร์มรันไทม์เริ่มแข่งขันกันเพื่อเข้าร่วมกลุ่มเครื่องมือแบบฟูลสแต็ค

ทันทีที่โปรเจ็กต์เริ่มแตะ SSR งานเบื้องหลัง พื้นที่เก็บข้อมูลอ็อบเจ็กต์ และการแสดงตัวอย่างการปรับใช้ในเวลาเดียวกัน เครื่องมือสร้างจะเปิดเผยขอบเขตดั้งเดิมในไม่ช้า vite dev รับผิดชอบในการรันเพจ ส่งคืนการจัดการเฟรมเวิร์กการทดสอบ ปรับใช้ CLI เพื่อออนไลน์ และเพิ่มชั้นกาวให้กับเลเยอร์การปรับรันไทม์ ในตอนแรก ชุดของสิ่งต่างๆ เหล่านี้พอทนได้ แต่เมื่อโปรเจ็กต์แยกการดีบักในเครื่องและรันไทม์ที่ใช้งานจริงออก ปัญหาก็เริ่มคลี่คลาย: สามารถทำงานได้ในเครื่อง แต่การแสดงตัวอย่างล้มเหลว เมื่อเวอร์ชันอะแดปเตอร์ได้รับการอัปเกรด การผูกคิวและหน่วยเก็บข้อมูลจะไม่เข้ากันอีกต่อไป คำสั่งยังคงเหมือนเดิม และฉันรู้แล้วว่าแต่ละเลเยอร์อาจมีปัญหาแยกจากกัน

การเปลี่ยนแปลงที่ชัดเจนที่สุดในห่วงโซ่เครื่องมือในช่วงสองปีที่ผ่านมาก็คือแพลตฟอร์มไม่พอใจกับ “ขั้นตอนสุดท้ายของการปรับใช้” อีกต่อไป พวกเขาเริ่มก้าวไปข้างหน้า โดยนำการพัฒนาในเครื่อง การจำลองรันไทม์ การทดสอบผลตอบรับ และคำสั่งที่เผยแพร่มาไว้ในลิงก์เดียวกัน ด้วยการควบรวมกิจการของ VoidZero เข้ากับ Cloudflare เมื่อเร็ว ๆ นี้ สิ่งที่ควรค่าแก่การรับชมไม่ใช่ข่าวการเข้าซื้อกิจการ แต่เป็นสัญญาณที่ชัดเจนยิ่งขึ้น: แพลตฟอร์มรันไทม์เริ่มแข่งขันโดยตรงเพื่อเข้าสู่ห่วงโซ่เครื่องมือแบบฟูลสแต็ก

เมื่อเครื่องมือสร้างถึงรันไทม์ ขอบเขตของแพลตฟอร์มจะเคลื่อนไปข้างหน้า

ในแง่ดั้งเดิม ความรับผิดชอบของเครื่องมือสร้างมีความชัดเจนมาก: อ่านซอร์สโค้ด สร้างบันเดิล และส่งมอบให้กับระบบถัดไปเพื่อประมวลผล การแบ่งงานครั้งนี้ไม่เพียงพออีกต่อไป ตราบใดที่แอปพลิเคชันมีการกำหนดเส้นทางฝั่งเซิร์ฟเวอร์ ฐานข้อมูล คิว พื้นที่จัดเก็บอ็อบเจ็กต์ และฟังก์ชัน Edge ความสมบูรณ์ของการก่อสร้างไม่ได้หมายความว่าการส่งมอบเสร็จสมบูรณ์ ยังคงมีส่วนของรันไทม์ซีแมนทิกส์ทั้งหมดที่ต้องจัดเรียง

จุดที่ง่ายที่สุดสำหรับโปรเจ็กต์ประเภทนี้ที่จะติดขัดไม่ใช่ว่า Bundler จะเร็วเพียงพอหรือไม่ แต่สิ่งที่รันในเครื่องในเวลานี้จะเป็นรันไทม์เดียวกันกับที่ตั้งค่าไว้ทางออนไลน์หรือไม่ ตราบใดที่คำตอบคือไม่ วงจรการพัฒนาก็จะหนักขึ้นเรื่อยๆ เพื่อเติมเต็มช่องว่างนี้ แพลตฟอร์มจะหาทางดึงเซิร์ฟเวอร์ dev เข้าสู่รันไทม์ของตัวเองอย่างแน่นอน และทำให้ “การเขียนโค้ดในเครื่อง” และ “เรียกใช้ออนไลน์” ให้เป็นโมเดลเดียวกัน

ดังนั้นการเปลี่ยนแปลงที่เราเห็นตอนนี้จึงไม่ใช่แค่แพลตฟอร์มที่จัดเตรียมอะแดปเตอร์สำหรับเฟรมเวิร์กบางอย่างอีกต่อไป แต่ในทางกลับกัน CLI ของแพลตฟอร์ม ปลั๊กอินรันไทม์ และสภาพแวดล้อมภายในเครื่องก็ถูกสร้างในเชิงรุกให้เป็นรูปแบบห่วงโซ่เครื่องมือที่นักพัฒนาคุ้นเคยอยู่แล้ว ด้วยวิธีนี้ทางเข้าจะเปลี่ยนไป แพลตฟอร์มไม่รอให้ขั้นตอน deploy ปรากฏขึ้นอีกต่อไป ได้เข้าสู่ตลาดแล้วตั้งแต่ dev, build, test และแม้แต่รูปแบบพร้อมท์ข้อผิดพลาด

เจ้าหน้าที่ขยายการเสียดสีเล็กๆ น้อยๆ ทั้งหมดในห่วงโซ่เครื่องมือที่สามารถทนได้

เมื่อเรื่องนี้อยู่ในขั้นตอนการพัฒนาด้วยตนเองเท่านั้น ก้าวนี้ก็ไม่ใช่เรื่องเร่งด่วนมากนัก ผู้คนจะจำได้ว่าคำสั่งใดที่ต้องรันมากกว่าหนึ่งครั้ง ข้อผิดพลาดใดที่เป็นเพียงปัญหาสิ่งแวดล้อม และอะแดปเตอร์ตัวใดที่ทำให้กระตุกเป็นครั้งคราว หลังจากที่ตัวแทนเข้ามา ความคลุมเครือเหล่านี้โดยพื้นฐานแล้วจะกลายเป็นต้นทุน

เอเจนต์จะดึงเซิร์ฟเวอร์ dev ขึ้นมาซ้ำๆ รันการทดสอบอีกครั้ง อ่านข้อผิดพลาด เปลี่ยนโค้ด และตรวจสอบอีกครั้ง คำสั่งที่ไม่สอดคล้องกัน บันทึกที่ผิดปกติ และพฤติกรรมรันไทม์ที่ไม่สอดคล้องกัน ข้อบกพร่องเล็กๆ น้อยๆ เหล่านี้ที่ได้รับการแก้ไขก่อนหน้านี้ด้วยประสบการณ์จะกลายเป็นลูปที่ไม่สิ้นสุดในลูปการดำเนินการโดยตรง แน่นอนว่า ความเร็วในการสร้าง ความเร็วในการทดสอบ และความเร็วของ Lint ก็มีความสำคัญเช่นกัน แต่สิ่งที่มีค่ามากกว่าก็คือลิงก์ทั้งหมดมีข้อจำกัดแบบรวมหรือไม่: CLI ชุดเดียวกัน โมเดลการกำหนดค่าชุดเดียวกัน เอาต์พุตข้อผิดพลาดประเภทเดียวกัน และความสัมพันธ์ในการแมปโลคัลและเวอร์ชันที่ใช้งานจริงเดียวกัน

นี่คือเหตุผลว่าทำไมสถานะของเครื่องมืออย่าง Vite จึงเปลี่ยนไป เดิมทีพวกมันเป็นเพียงอุปกรณ์ที่มีประโยชน์ที่สุดในชั้นโครงสร้างส่วนหน้า แต่ตอนนี้พวกมันค่อยๆ กลายเป็นพื้นฐานสำหรับ Agent ที่ขับได้อย่างเสถียรง่ายที่สุด รวดเร็ว ง่ายดาย และเข้ากันได้อย่างกว้างขวาง ข้อดีเหล่านี้ใช้เพื่อประสบการณ์การพัฒนาเป็นหลัก แต่ตอนนี้มีประโยชน์ต่อความน่าเชื่อถือในการดำเนินการโดยตรง ตราบใดที่แพลตฟอร์มแนบความสามารถรันไทม์เข้ากับลูปเริ่มต้นนี้ แพลตฟอร์มจะไม่เพียงได้รับเป้าหมายในการนำไปใช้งาน แต่ยังได้รับชุดการสร้างแอปพลิเคชันและพฤติกรรมการตรวจสอบทั้งหมดอีกด้วย

สิ่งที่มีค่าจริงๆ ไม่ใช่การจัดตำแหน่งของกรอบงาน แต่เป็นผู้ที่จะดึงขั้นตอนการทำงานเริ่มต้นออกไป

เพียงดูหัวข้อข่าว ก็เป็นเรื่องง่ายที่จะตีความการกระทำต่างๆ เช่น การลงทุนเชิงนิเวศน์ หรือเป็นแพลตฟอร์มที่ต้องการเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังบริการโฮสติ้งของตนเอง การเปลี่ยนแปลงทางวิศวกรรมที่ละเอียดอ่อนมากขึ้นนั้นแท้จริงแล้วในอีกระดับหนึ่ง: เมื่อโครงร่างเริ่มต้นของโครงการ รันไทม์ท้องถิ่นเริ่มต้น วงการทดสอบเริ่มต้น และคำสั่งการปล่อยเริ่มต้นทั้งหมดตกอยู่ในห่วงโซ่เครื่องมือเดียวกัน หน่วยของการแข่งขันแพลตฟอร์มจะเปลี่ยนจาก “เครื่องจักรที่มีราคาถูกกว่า” เป็น “ใครเป็นคนแรกที่กำหนดวิธีการสร้างแอปพลิเคชัน”

ความแตกต่างนี้ไม่น้อย สามารถเปรียบเทียบราคาในแนวนอนได้ เมื่อเวิร์กโฟลว์ถูกเขียนลงในคลังสินค้า สคริปต์ CI และนิสัยของทีมแล้ว การเปลี่ยนแปลงก็ไม่ใช่เรื่องง่าย หากแพลตฟอร์มสามารถรับช่วงขั้นตอนสุดท้ายของการปรับใช้เท่านั้น เกณฑ์การย้ายข้อมูลจะไม่สูง หากแพลตฟอร์มได้ยึดครองเส้นทางทั้งหมดตั้งแต่ dev ถึง deploy การโยกย้ายจะส่งผลต่อสภาพแวดล้อมภายในเครื่อง ลักษณะการใช้คำสั่ง ลิงก์แสดงตัวอย่าง วิธีการแก้ไขจุดบกพร่อง และสคริปต์การดำเนินการของตัวแทน มักเป็นชั้นนี้ที่ก่อให้เกิดความเหนียวจริงๆ

คลื่นแห่งการเคลื่อนไหวล่าสุดนี้ยังดึงเอาสิ่งอื่นออกมา: ห่วงโซ่เครื่องมือแบบฟูลสแตกกำลังให้คำจำกัดความ “เป็นกลาง” ใหม่ ในอดีต ความเป็นกลางมีความหมายมากกว่าที่จะไม่ขึ้นอยู่กับกรอบงานและทำงานบนชุดรวมที่แตกต่างกัน ปัจจุบันข้อกำหนดความเป็นกลางมีความเข้มงวดมากขึ้น ต้องเสียบปลั๊กความสามารถของแพลตฟอร์ม แต่ตัวห่วงโซ่เครื่องมือไม่สามารถสร้างเป็นโปรโตคอลส่วนตัวของแพลตฟอร์มได้ ใครก็ตามที่สามารถเก็บเลเยอร์นามธรรมที่ไม่เชื่อเรื่องพระเจ้าของผู้ให้บริการไว้ได้ในขณะที่ใช้งานประสบการณ์เริ่มต้นของตนเอง มีแนวโน้มที่จะได้รับโบนัสการเข้าชมรอบถัดไปมากขึ้น

เส้นทางนี้เหมาะสำหรับทีมที่ถูกขัดขวางโดยความซับซ้อนในการส่งมอบเท่านั้น

ไม่ใช่ทุกโครงการที่ต้องใส่ใจกับการโต้แย้งทางเข้าประเภทนี้ สำหรับไซต์แบบคงที่ แบ็กเอนด์ขนาดเล็ก หรือบริการที่มีแบบฟอร์มการปรับใช้เพียงรูปแบบเดียว การแยกการก่อสร้าง การทดสอบ และการปรับใช้ต่อไปอาจไม่เสียหาย เมื่อโครงการมีขนาดใหญ่ ปัญหาประเภทนี้จะเกิดขึ้นอย่างรวดเร็ว:

• ความแตกต่างระหว่างการพัฒนาในท้องถิ่นและรันไทม์ออนไลน์เริ่มใช้เวลานานในการแก้ไขปัญหาซ้ำแล้วซ้ำเล่า
• SSR, คิวงาน, พื้นที่จัดเก็บอ็อบเจ็กต์ และการเชื่อมโยงฐานข้อมูลทั้งหมดจะปรากฏในคลังสินค้าเดียวกัน
• ทีมต่างๆ อาศัยสภาพแวดล้อมการแสดงตัวอย่าง คำสั่งนั่งร้าน และเทมเพลต CI สำหรับการส่งมอบการทำงานร่วมกันอยู่แล้ว
• เจ้าหน้าที่มีส่วนร่วมในการเขียนโค้ด แก้ไขจุดบกพร่อง และการทดสอบ และความเสถียรของห่วงโซ่เครื่องมือเริ่มส่งผลกระทบโดยตรงต่อเอาท์พุต

ในขั้นตอนนี้ อาจสายไปเล็กน้อยที่จะถือว่าเครื่องมือสร้างเป็นส่วนประกอบเลเยอร์ส่วนหน้าอย่างแท้จริง มันกำลังกลายเป็นส่วนหนึ่งของจุดเริ่มต้นแอปพลิเคชัน ซึ่งเชื่อมต่อกับรันไทม์ ฝั่งปรับใช้ และฝั่งดำเนินการ การควบรวมกิจการของ VoidZero และ Cloudflare ทำให้เรื่องนี้ชัดเจนขึ้นเท่านั้น การแข่งขันแพลตฟอร์มรอบต่อไปจะเหมือนกับการแข่งขันสำหรับเวิร์กโฟลว์เริ่มต้นมากขึ้นเรื่อยๆ ใครก็ตามที่ปิดห่วงโซ่นี้อย่างราบรื่นที่สุดจะมีโอกาสดีกว่าในการตัดสินใจว่าจะพัฒนาแอปพลิเคชันรากฐานใดก่อน