𝗧𝘂𝗿𝘀𝗼 𝗹𝗶𝗯𝗦𝗤𝗟 𝘃𝘀 𝗖𝗹𝗼𝘂𝗱𝗳𝗹𝗮𝗿𝗲 𝗗𝟭
การเลือกฐานข้อมูลสำหรับ Astro monorepo ขึ้นอยู่กับเวิร์กโฟลว์ (workflow) ของคุณ
เมื่อเร็วๆ นี้ ผมได้สร้างฐานข้อมูลที่ใช้ร่วมกันสำหรับเว็บไซต์ Astro SSG สามแห่ง โดยมีสองทางเลือกคือ: Turso (libSQL) หรือ Cloudflare D1
ผมเลือก Turso
และนี่คือเหตุผลว่าทำไมความแตกต่างในเชิงปฏิบัติถึงมีความสำคัญ
Cloudflare D1 ถูกสร้างขึ้นมาเพื่อ Cloudflare Workers หากคุณใช้ Workers สำหรับการทำ server-side rendering ตัว D1 จะเป็นผู้ชนะ เพราะมันทำงานอยู่ในที่เดียวกับที่โค้ดของคุณรันอยู่
แต่การตั้งค่าของผมต่างออกไป เว็บไซต์ของผมเป็น Astro 5 SSG แบบ static บน Cloudflare Pages ผมไม่ได้ใช้ Workers แต่ ETL pipeline ของผมรันบน GitHub Actions
การใช้ D1 จาก GitHub Actions นั้นทำได้ยาก คุณต้องใช้ Cloudflare API หรือ Wrangler CLI ซึ่งไม่มีตัวไหนที่ให้ไฟล์ SQLite ในเครื่องเพื่อใช้ query ระหว่างการพัฒนาได้เลย ผลที่ตามมาคือคุณต้องเชื่อมต่อกับฐานข้อมูลระยะไกล (remote database) ในทุกๆ การทดสอบ
Turso แก้ปัญหานี้ด้วยแพ็กเกจ @libsql/client ซึ่งรองรับการใช้ URL โดย URL นั้นจะเป็นลิงก์ระยะไกลหรือพาธของไฟล์ในเครื่อง (local file path) ก็ได้
โค้ดของผมมีลักษณะดังนี้:
URL จะเป็นลิงก์ Turso ระยะไกลใน CI ส่วนบนแล็ปท็อปของผม ตัว client จะเปิดไฟล์ในเครื่อง โดยที่แพ็กเกจ, query และ schema ยังคงเหมือนเดิมทุกประการ
เส้นทางการทำงานของโค้ด (code path) จึงเหมือนกันเป๊ะ
สิ่งนี้ช่วยให้ผมสามารถ:
- รันสคริปต์ ETL ในเครื่องได้
- ตรวจสอบฐานข้อมูลด้วย SQLite viewer ใดก็ได้
- รัน migrations ด้วยฟังก์ชันเดียวกับที่ใช้ใน production
ผมไม่จำเป็นต้องใช้ Docker ไม่ต้องใช้ flag พิเศษ และใช้ SQL ชุดเดียวกันได้ทุกที่
ผมใช้วิธีแบบ idempotent สำหรับการทำ migrations โดยโค้ดของผมจะตรวจสอบก่อนว่ามี table อยู่แล้วหรือไม่ก่อนที่จะสร้างใหม่ ซึ่งช่วยให้สามารถรันซ้ำได้อย่างปลอดภัย
เมื่อไหร่ที่คุณควรเลือก D1? หากคุณใช้ Cloudflare Workers สำหรับการค้นหา (search) หรือ API routes ตัว D1 จะดีกว่า เพราะการเชื่อมต่อจะเร็วกว่าเนื่องจากทำงานอยู่ภายใน datacenter เดียวกัน
แต่สถาปัตยกรรมของผมเป็นแบบ static ทั้งหมด เนื่องจากผมไม่ได้ใช้ Workers ข้อได้เปรียบหลักของ D1 จึงหายไป
ข้อแลกเปลี่ยนในปัจจุบัน:
- ประสิทธิภาพการเขียน (Write performance): ETL ของผมรันงานทีละอย่าง ผมยังไม่ได้ทดสอบการเขียนแบบพร้อมกัน (concurrent writes) ด้วยความเร็วสูง
- การเปลี่ยน schema: การเพิ่มคอลัมน์นั้นง่าย แต่การเปลี่ยนชื่อคอลัมน์ต้องใช้ความระมัดระวังมากขึ้น
- ราคา: ทั้งคู่มี free tier ที่ใจดีมาก สำหรับเว็บไซต์สามแห่ง ค่าใช้จ่ายของผมคือศูนย์
การเลือกฐานข้อมูลไม่ใช่เป้าหมายหลัก แต่การที่สามารถสลับไปใช้ไฟล์ในเครื่องได้ (local file fallback) คือเหตุผลที่ผมเลือก Turso เพราะมันทำให้การพัฒนาง่ายขึ้น