เทคนิคอันชาญฉลาดสำหรับการโฮสต์ฐานข้อมูล SQLite บนแพลตฟอร์มแบบสแตติกอย่าง GitHub Pages ต้องเผชิญกับอุปสรรคสำคัญ: ปัญหาความเข้ากันได้ของเบราว์เซอร์ที่ทำให้ผู้ใช้จำนวนมากไม่สามารถใช้งานแนวทางใหม่นี้สำหรับเว็บไซต์สแตติกที่ขับเคลื่อนด้วยฐานข้อมูลได้
วิธีการนี้ซึ่งเคยถูกสาธิตครั้งแรกในปี 2021 ทำการคอมไพล์ SQLite เป็น WebAssembly และนำระบบไฟล์เสมือนมาใช้ที่ดึงข้อมูลส่วนย่อยของฐานข้อมูลผ่านคำขอ HTTP Range ซึ่งทำให้สามารถสอบถามชุดข้อมูลขนาดใหญ่ (สูงถึง 670MB ในตัวอย่างเดิม) ในขณะที่โหลดเฉพาะข้อมูลที่จำเป็นสำหรับแต่ละคำถามเท่านั้น แนวทางนี้เคยสัญญาว่าจะขจัดความต้องการเซิร์ฟเวอร์แบ็กเอนด์สำหรับเว็บไซต์สแตติกที่มีข้อมูลจำนวนมาก แต่การอภิปรายในชุมชนล่าสุดเผยให้เห็นปัญหาการทำงานที่แพร่หลาย
แนวทางทางเทคนิคดั้งเดิม:
- คอมไพล์ SQLite เป็น WebAssembly ผ่าน Emscripten
- ระบบไฟล์เสมือนที่ใช้ HTTP Range requests
- ขนาดเพจ 1 KiB เพื่อการแบ่งส่วนข้อมูลที่เหมาะสม
- ระบบดึงข้อมูลล่วงหน้าด้วยการขยายขนาดคำขอแบบทวีคูณ
- การดำเนินการฐานข้อมูลแบบอ่านอย่างเดียวบนโฮสต์แบบคงที่
บั๊กคำขอ Range ใน Firefox
ผู้ใช้หลายคนรายงานว่าพบข้อผิดพลาดเครือข่ายเมื่อพยายามรันตัวอย่าง SQLite โดยผู้ใช้ Firefox ได้รับผลกระทบเป็นพิเศษ ปัญหาหลักเกิดจากวิธีที่ Firefox จัดการกับคำขอ HTTP Range สำหรับเนื้อหาที่ถูกบีบอัด
มันคงจะน่าสนใจกว่าถ้าตัวอย่างทุกตัว อย่างน้อยสำหรับผม ไม่ส่งกลับค่า
[error: NetworkError: A network error occurred.]
ปัญหานี้เกี่ยวข้องกับการตีความข้อกำหนด HTTP ที่คลุมเครือเกี่ยวกับการเข้ารหัสเนื้อหา Firefox เพิ่ม 'identity' เข้าไปในรายการการเข้ารหัสที่รองรับใน Accept-Headers ในขณะที่เบราว์เซอร์อื่นแทนที่รายการด้วย 'identity' เมื่อ GitHub Pages ได้รับคำขอแบบ range จาก Firefox มันอาจส่งกลับส่วนย่อยของไฟล์ที่ถูกบีบอัดซึ่งทำให้เครื่องมือ SQLite ไม่สามารถอ่านได้ พฤติกรรมนี้ไม่ได้เกิดขึ้นเสมอมา – ผู้ใช้หลายคนระบุว่าตัวอย่างเคยทำงานได้อย่างถูกต้องในเวอร์ชัน Firefox ก่อนหน้า
ปัญหาความเข้ากันได้ของเบราว์เซอร์หลัก:
- Firefox: บั๊กของ HTTP Range request กับเนื้อหาที่ถูกบีบอัด (Bug 1874840)
- Safari: มีรายงานความล้มเหลวที่ไม่สม่ำเสมอจากผู้ใช้บางคน
- Chrome/Chromium: โดยทั่วไปทำงานได้อย่างถูกต้อง
- Edge: โดยทั่วไปทำงานได้อย่างถูกต้อง
ความกังวลเรื่องความน่าเชื่อถือข้ามเบราว์เซอร์
ปัญหาความเข้ากันได้นี้ไม่ได้จำกัดอยู่แค่ Firefox เท่านั้น ผู้ใช้ Safari บางส่วนก็รายงานความล้มเหลวเช่นกัน แม้ว่าปัญหาดูเหมือนจะไม่สม่ำเสมอเท่าในเบราว์เซอร์ของ Apple ความท้าทายพื้นฐานอยู่ที่ว่าเบราว์เซอร์ต่างกันตีความข้อกำหนดคำขอ HTTP range อย่างไร และผู้ให้บริการโฮสติ้งแบบสแตติกจัดการกับคำขอเหล่านี้อย่างไร GitHub Pages แม้จะยอดเยี่ยมสำหรับเนื้อหาแบบสแตติกทั่วไป อาจไม่สามารถจัดการกับการรวมกันเฉพาะของคำขอ range และการบีบอัดที่ระบบไฟล์เสมือน HTTP ของ SQLite ต้องการได้อย่างเหมาะสม
แนวทางทางเลือกเริ่มปรากฏ
แม้จะมีความท้าทายด้านความเข้ากันได้ แนวคิดดั้งเดิมก็ได้สร้างแรงบันดาลใจให้เกิดทางเลือกที่น่าสนใจหลายอย่าง DuckDB WASM ได้รับความนิยมมากขึ้นในฐานะตัวแทนสมัยใหม่ที่ให้ฟังก์ชันการทำงานคล้ายกันด้วยการรองรับเบราว์เซอร์ที่อาจดีกว่า นักพัฒนารายหนึ่งแบ่งปันประสบการณ์การใช้ DuckDB WASM บน GitHub Pages เพื่อแสดงแนวโน้มทางธุรกิจ แม้ว่าพวกเขาจะระบุว่าเวลาโหลดครั้งแรกอยู่ที่ประมาณ 10 วินาทีสำหรับชุดข้อมูลขนาดใหญ่
ทีมพัฒนาหลักของ SQLite ได้เพิ่มการรองรับ WebAssembly ในการแจกจ่ายของพวกเขาแล้ว โดยอ้างอิงถึงโครงการชุมชนก่อนหน้านี้เป็นแรงบันดาลใจ อีกแนวทางหนึ่งใช้ IndexedDB เป็นแบ็กเอนด์จัดเก็บข้อมูลถาวร โดยถือว่าฐานข้อมูลท้องถิ่นของเบราว์เซอร์เป็นบล็อกดิสก์เสมือนสำหรับการทำงานของ SQLite การพัฒนาต่างๆ เหล่านี้ชี้ให้เห็นว่าแนวคิดหลักยังคงมีคุณค่า แม้ว่าการนำไปใช้ดั้งเดิมจะเผชิญกับอุปสรรคด้านความเข้ากันได้ของเบราว์เซอร์
เทคโนโลยีทางเลือก:
- DuckDB WASM: ทางเลือกสมัยใหม่ที่มีการรองรับเบราว์เซอร์ที่ดีกว่า
- Official SQLite WASM: ตอนนี้รวมการรองรับ WebAssembly แล้ว
- absurd-sql: ใช้ IndexedDB เป็นแบ็กเอนด์สำหรับจัดเก็บข้อมูล
- sqlite-wasm-http: การแจกจ่ายอย่างเป็นทางการของ SQLite ที่มีการรองรับ HTTP
ข้อจำกัดในทางปฏิบัติและวิธีแก้ปัญหา
สำหรับนักพัฒนาที่กำลังพิจารณาแนวทางนี้ ปัญหาความเข้ากันได้ของเบราว์เซอร์สร้างอุปสรรคจริง การใช้เทคนิคนี้ต้องมีการทดสอบอย่างรอบคอบในหลายเบราว์เซอร์และอาจต้องมีกลไกสำรองสำหรับผู้ใช้ที่ได้รับผลกระทบ การนำไปใช้บางส่วนต้องยอมโหลดไฟล์ทั้งหมดเมื่อคำขอ range ล้มเหลว แม้ว่าสิ่งนี้จะขัดกับวัตถุประสงค์สำหรับชุดข้อมูลขนาดใหญ่ก็ตาม ฉันทามติในชุมชนชี้ให้เห็นว่าแม้ในทางทฤษฎีจะสง่างาม แต่การนำไปใช้ในทางปฏิบัติต้องการความแข็งแกร่งมากขึ้นสำหรับการใช้งานในสภาพแวดล้อมจริง
การพัฒนาที่ต่อเนื่องในพื้นที่นี้แสดงให้เห็นถึงความสนใจอย่างต่อเนื่องในการขยายขีดจำกัดของการโฮสติ้งแบบสแตติก เมื่อมาตรฐานเว็บพัฒนาขึ้นและพฤติกรรมของเบราว์เซอร์มีความสม่ำเสมอมากขึ้น เทคนิคเหล่านี้อาจในที่สุดก็จะบรรลุความน่าเชื่อถือที่จำเป็นสำหรับการยอมรับในวงกว้าง สำหรับตอนนี้ นักพัฒนาต้องชั่งน้ำหนักระหว่างศักยภาพนวัตกรรมกับความกังวลด้านความเข้ากันได้ที่เป็นจริงอย่างมากที่ข้อเสนอแนะจากชุมชนได้เน้นย้ำ