Cloudflare เขียน module registry ของ Workers ใหม่: ทำไมการเปลี่ยนจากพาธเป็น URL ถึงปลดล็อกความเข้ากันได้กับ Node.js

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

ปัญหาของระบบเดิม: ตัวระบุโมดูลไม่ใช่ URL

ระบบเดิมของ Workers ปฏิบัติกับตัวระบุโมดูลเหมือนพาธในระบบไฟล์ ไม่ใช่ URL ผลที่ตามมาคือความสามารถมาตรฐานของ JavaScript หลายอย่างทำงานไม่ได้ เช่น import.meta.url และ import.meta.resolve() การแปลงตัวระบุแบบสัมพัทธ์ก็ไม่ได้ทำตามกฎการแปลง URL มาตรฐาน และโปรโตคอลอย่าง node: ถูกจัดการเป็นเพียงคำนำหน้าสตริงที่เขียนเงื่อนไขพิเศษไว้

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

ระบบใหม่: URL เป็นตัวระบุ คอมไพล์เมื่อถูกเรียก และแบ่งปันแคช

ระบบที่เขียนใหม่ใช้ URL เป็นรูปแบบตัวระบุ และออกแบบให้การคอมไพล์แบบขี้เกียจกับการแบ่งปันแคชเป็นคุณสมบัติพื้นฐานตั้งแต่แรก ไม่ใช่สิ่งที่มาเติมทีหลัง โมดูลจะถูกคอมไพล์เมื่อถูก import ครั้งแรกเท่านั้น แคชของโค้ดถูกแบ่งปันข้าม isolate ที่รัน Worker เดียวกัน และตัวระบุถูกแปลงเป็น URL จริงที่รองรับทั้ง query string และ fragment

ผลข้างเคียงที่สำคัญคือเรื่องอัตลักษณ์ของโมดูล เมื่อ query string และ fragment ต่างกัน ระบบจะถือว่าเป็นอินสแตนซ์คนละตัวกัน ซึ่งตรงกับพฤติกรรมมาตรฐานและทำให้ผลลัพธ์คาดเดาได้

ความเข้ากันได้กับ Node.js ที่ได้เพิ่มมา

การเปลี่ยนฐานคิดครั้งนี้ปลดล็อกหลายอย่างพร้อมกัน ได้แก่ import.meta.url, import.meta.main และ import.meta.resolve() ที่ทำงานได้จริง พฤติกรรมของ require(esm) ที่เป็นไปตามกฎของ Node.js การตรวจสอบ import attribute ที่ถูกต้อง โดยปฏิเสธชนิดที่ไม่รองรับอย่าง text การรองรับการนำเข้า WebAssembly แบบ source phase ด้วยรูปแบบ import source wasmModule from './add.wasm' และคลาสของข้อผิดพลาดที่สอดคล้องกันไม่ว่าจะ import ด้วยวิธีใด

สิ่งที่นักพัฒนาต้องทำเอง

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

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

บทเรียนที่นำไปใช้ได้แม้ไม่ได้ใช้ Workers

กรณีนี้เป็นตัวอย่างที่ดีของการเลือกฐานคิดผิดตั้งแต่ต้นแล้วต้องจ่ายทีหลัง การมองตัวระบุโมดูลเป็นพาธแทนที่จะเป็น URL ดูเหมือนรายละเอียดเล็ก ๆ ในตอนออกแบบ แต่กลายเป็นข้อจำกัดที่ทำให้รองรับมาตรฐานใหม่ไม่ได้เป็นปี ๆ บทเรียนคือเมื่อมีมาตรฐานกลางอยู่แล้ว การเลือกทำตามมาตรฐานตั้งแต่แรกมักถูกกว่าการประดิษฐ์รูปแบบของตัวเอง

สำหรับทีมพัฒนาเว็บในไทยที่ใช้ Workers หรือกำลังพิจารณาย้ายระบบขึ้นแพลตฟอร์มไร้เซิร์ฟเวอร์ การเปิดแฟล็กนี้ในสภาพแวดล้อมทดสอบก่อนคือขั้นตอนที่ควรทำ เพราะพฤติกรรมการแปลงตัวระบุที่เปลี่ยนไปอาจกระทบไลบรารีที่พึ่งพารูปแบบเดิม และควรตรวจให้ครบก่อนใช้กับระบบจริง ทีมงาน Smart Cyber Tech รับทำเว็บไซต์และเว็บแอปพลิเคชัน React และ Next.js รวมถึงวางระบบบนแพลตฟอร์มขอบเครือข่ายให้รองรับผู้ใช้จำนวนมากโดยคุมค่าใช้จ่ายได้ ปรึกษาได้ที่ แบบฟอร์มติดต่อ