หยุดสร้างฐานข้อมูล
(sqlsync.dev)ความซับซ้อนของการจัดการข้อมูล
- วิศวกรฟรอนต์เอนด์เริ่มตระหนักถึงความจำเป็นในการแคชข้อมูลจาก API
- ในช่วงแรกเริ่มจากการจัดเก็บข้อมูลแบบง่าย ๆ แต่เมื่อมีคำขอฟีเจอร์เพิ่มขึ้น ก็ต้องเริ่มทำ data cache, manual index, optimistic mutations, recursive cache invalidation และอื่น ๆ
- ฟีเจอร์เหล่านี้มีลักษณะคล้ายกับการทำงานภายในของฐานข้อมูล และในแอปพลิเคชันฟรอนต์เอนด์ที่ซับซ้อน สุดท้ายก็มักจะกลายเป็นการสร้างฐานข้อมูลเฉพาะโดเมนขึ้นมาเอง
พื้นฐานของแคช
- เริ่มจากการเก็บผลลัพธ์ของคำขอ API ไว้ในตัวแปรภายในเครื่อง
- ในเว็บแอปพลิเคชันที่ใช้ declarative framework จะเก็บข้อมูลไว้ในตัวแปรเพื่อหลีกเลี่ยงการเรียก API ที่ไม่จำเป็น
- ขั้นถัดไปคือการย้ายแคชไปไว้ในชั้นที่สูงขึ้น หรือย้ายออกไปไว้นอก UI tree
เพิ่มความเร็วด้วยดัชนี
- การจัดระเบียบข้อมูลในรูปแบบเฉพาะช่วยลดงานของแอปพลิเคชันและปรับปรุงประสบการณ์ผู้ใช้ได้
- พบว่าการปรับข้อมูลฝั่งฟรอนต์เอนด์ให้เหมาะสมมีความคล้ายกับกลไกภายในของ storage ในฐานข้อมูล
- ปรับปรุงโครงสร้างข้อมูลด้วยการเก็บข้อมูลตาม ID และสร้างดัชนีที่ช่วยให้ค้นหารายการตามวันที่ได้อย่างรวดเร็ว
การเปลี่ยนแปลงแบบมองโลกในแง่ดี
- คือการจำลองผลของการกระทำบางอย่างในเครื่องโดยไม่ต้องรอการตอบกลับจากเซิร์ฟเวอร์
- ทำให้อินเทอร์เฟซผู้ใช้ดูเหมือนตอบสนองได้ทันที แต่ถ้าผลลัพธ์จากเซิร์ฟเวอร์ออกมาต่างกัน UI ก็ต้องย้อนกลับการเปลี่ยนแปลง
- มีความท้าทาย เช่น การทำซ้ำตรรกะระหว่างไคลเอนต์กับเซิร์ฟเวอร์ การจัดการข้อผิดพลาดแบบอะซิงโครนัส และการปรับการเปลี่ยนแปลงให้สอดคล้องกันแม้แอปจะถูกรีสตาร์ต
การทำให้แคชใช้ไม่ได้แบบเรียกซ้ำ
- ข้อมูลอาจปรากฏอยู่หลายตำแหน่งในแคช และหลังอัปเดตแล้วจำเป็นต้อง invalidate แคชให้ถูกต้องเพื่อให้ตรงกับสถานะบนเซิร์ฟเวอร์
- UI ต้องรู้ว่าส่วนใดของแคชเกี่ยวข้องกับ mutation แต่ละรายการ ซึ่งอาจเปราะบางมากขึ้นเมื่อระบบมีขนาดใหญ่ขึ้น
- เมื่อใช้ร่วมกับ optimistic mutations การทำซ้ำตรรกะของเซิร์ฟเวอร์เพื่อคาดการณ์การเปลี่ยนแปลงฝั่งเซิร์ฟเวอร์จากฝั่งไคลเอนต์จะยิ่งยากขึ้น
กำลังสร้างฐานข้อมูลอยู่หรือไม่?
- ในแอปพลิเคชันฟรอนต์เอนด์ที่มีความซับซ้อนมากพอ สุดท้ายแล้วก็มักต้องสร้างความสามารถด้านการจัดการข้อมูลจำนวนมาก ซึ่งดึงเวลาออกจากการทำสิ่งที่ทำให้ผู้ใช้พึงพอใจและแก้ปัญหาทางธุรกิจจริง ๆ
- บทความนี้เสนอทางเลือกแทนสแตกฐานข้อมูลที่ปรับให้เหมาะกับฟรอนต์เอนด์
แนะนำ SQLSync
- ผู้เขียนได้พัฒนา SQLSync ซึ่งเป็นสแตกฐานข้อมูลที่ปรับให้เหมาะกับฟรอนต์เอนด์และสร้างบน SQLite
- SQLSync ถูกออกแบบมาเพื่อแก้ปัญหาการจัดการข้อมูล และช่วยให้นักพัฒนามุ่งเน้นไปที่ฟีเจอร์เฉพาะตัวของแอปพลิเคชันได้
- SQLSync มี durable cache, ความสามารถเต็มรูปแบบของ SQLite, optimistic mutations, smart cache invalidation และ reactive queries
ความเห็นของ GN⁺
ประเด็นสำคัญที่สุดของบทความนี้คือ เมื่อความซับซ้อนของแอปพลิเคชันฟรอนต์เอนด์เพิ่มขึ้น นักพัฒนามักลงเอยด้วยการสร้างความสามารถที่คล้ายฐานข้อมูลขึ้นมาเอง งานลักษณะนี้ใช้เวลาของนักพัฒนาไปมาก และทำให้หลุดจากการพัฒนาฟีเจอร์ที่สร้างคุณค่าให้ผู้ใช้จริง ๆ สแตกฐานข้อมูลที่ปรับให้เหมาะกับฟรอนต์เอนด์อย่าง SQLSync นำเสนอแนวทางใหม่ที่น่าสนใจในการแก้ปัญหานี้ เหตุผลที่บทความนี้น่าสนใจคือมันชี้ให้เห็นปัญหาเชิงรากฐานของแนวทางจัดการข้อมูลแบบเดิม และมองหาแนวทางใหม่ที่ช่วยให้นักพัฒนาทำงานได้อย่างมีประสิทธิภาพมากขึ้น
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เข้าใจเพื่อนที่เป็นผู้สร้างโปรเจ็กต์นี้
ประสบการณ์กับซอฟต์แวร์จัดการโปรเจ็กต์ของบริษัทเก่า
ปัญหาที่หายไปเมื่อเลิกใช้ SPA
ความเห็นจากผู้สร้าง SQLSync
อย่าให้ mental model ที่ไม่ตรงกับความเป็นจริงแก่ผู้ใช้
หลักการที่ว่าสิ่งที่วัดได้ย่อมถูกจัดการ และความผิดพลาดจาก sunk cost
ปัญหาการซิงก์สถานะระหว่างไคลเอนต์กับเซิร์ฟเวอร์
การเปรียบเทียบกับไลบรารี ORM
ความแตกต่างระหว่างฐานข้อมูลฝั่งฟรอนต์เอนด์และแบ็กเอนด์
ความพยายามที่คล้ายกันผ่าน SignalDB