ในยุคที่ถูกครอบงำด้วยเฟรมเวิร์ก JavaScript ที่ซับซ้อนและสถาปัตยกรรมไมโครเซอร์วิส แนวโน้มที่น่าประหลาดใจกำลังได้รับความนิยมในหมู่นักพัฒนา นั่นคือการย้ายลอจิกของเว็บแอปพลิเคชันลงไปอยู่ในชั้นฐานข้อมูลโดยตรง Derek Sivers ซึ่งเป็นที่รู้จักจากแนวทางที่ไม่เหมือนใครในด้านเทคโนโลยี ได้แชร์วิธีการพัฒนาเว็บที่ให้ความสำคัญกับ PostgreSQL ของเขา ซึ่งได้จุดประกายการอภิปรายอย่างร้อนแรงทั่วทั้งชุมชนนักพัฒนา แนวทางของเขาท้าทายสมมติฐานพื้นฐานเกี่ยวกับตำแหน่งที่ลอจิกทางธุรกิจควรอยู่ในการพัฒนาเว็บแอปพลิเคชันสมัยใหม่
ปรัชญาการให้ความสำคัญกับฐานข้อมูลเป็นอันดับแรก
Sivers ได้สร้างเว็บแอปพลิเคชันที่ให้ความสำคัญกับ PostgreSQL มาเป็นเวลาเก้าปี โดยเริ่มแรกให้ PostgreSQL ส่งกลับข้อมูล JSON ที่จะถูกประมวลผลโดยตัวควบคุม Ruby ต่อมา เขาได้พัฒนาคอนเซปต์นี้ให้ก้าวไกลยิ่งขึ้นด้วยการฝังการแยกวิเคราะห์เทมเพลต Mustache โดยตรงภายในฟังก์ชันของ PostgreSQL ซึ่งหมายความว่าฐานข้อมูลไม่เพียงแต่ส่งข้อมูลเท่านั้น แต่ยังสร้างการตอบสนอง HTML ที่สมบูรณ์พร้อมส่งไปยังเบราว์เซอร์โดยตรง แนวทางนี้ขจัดชั้นมิดเดิลแวร์แบบดั้งเดิมออกไป โดยฟังก์ชัน PostgreSQL จะส่งกลับทั้งส่วนหัว HTTP และเนื้อหา HTML โดยตรง
แอปพลิเคชันของคุณกำลังนั่งอยู่บนเครื่องจักรสำหรับการคำนวณระดับ Ferrari!
มุมมองนี้เน้นย้ำถึงสิ่งที่ผู้สนับสนุนมองว่าเป็นศักยภาพที่ยังไม่ได้ถูกใช้ประโยชน์ของระบบฐานข้อมูลสมัยใหม่ แทนที่จะมองว่าฐานข้อมูลเป็นเพียงที่เก็บข้อมูล พวกเขายืนยันว่าฐานข้อมูลเชิงสัมพันธ์อย่าง PostgreSQL นั้นมีเครื่องจักรสำหรับการคำนวณที่ซับซ้อนซึ่งแอปพลิเคชันส่วนใหญ่ใช้ไม่เต็มที่
องค์ประกอบทางเทคนิคในแนวทางของ Sivers:
- การแยกวิเคราะห์เทมเพลต Mustache ภายใน PostgreSQL
- pgTAP สำหรับการทดสอบฟังก์ชันฐานข้อมูล
- HTTP headers และ status codes ที่ส่งคืนจากฟังก์ชันฐานข้อมูล
- ฐานข้อมูลทดสอบแยกต่างหาก (siverstest) สำหรับการทดสอบแบบแยกส่วน
- การซิงโครไนซ์เทมเพลตจากระบบไฟล์ไปยังตารางฐานข้อมูล
ตัวอย่างในอดีตและปฏิกิริยาในยุคสมัยใหม่
แนวคิดในการวางลอจิกทางธุรกิจในสโตรโปรซีเยอร์ไม่ใช่เรื่องใหม่เสียทีเดียว ผู้แสดงความคิดเห็นหลายคนระลึกถึงแนวทางที่คล้ายกันจากช่วงต้นทศวรรษ 2000 โดยเฉพาะกับฐานข้อมูล Oracle นักพัฒนาคนหนึ่งระบุว่างานแรกของพวกเขาราวปี 2007 เกี่ยวข้องกับการทำงานบนแอปพลิเคชัน Delphi ที่ลอจิกทางธุรกิจทั้งหมดอยู่ในสโตรโปรซีเยอร์ของ Oracle บริบททางประวัติศาสตร์นี้ให้มุมมองที่สำคัญเกี่ยวกับว่าเรากำลังเห็นนวัตกรรมใหม่หรือการค้นพบอีกครั้ง
ปฏิกิริยาจากนักพัฒนาที่มีประสบการณ์จากยุคสโตรโปรซีเยอร์ในทศวรรษ 1990 นั้นหลากหลาย บางคนแสดงความสงสัยจากประสบการณ์อันเลวร้ายกับแอปพลิเคชันฐานข้อมูลที่เชื่อมต่อกันอย่างแน่นหนาและกลายเป็นฝันร้ายในการบำรุงรักษา อย่างไรก็ตาม Sivers และคนอื่นๆ ยืนยันว่า PostgreSQL เป็นกระบวนทัศน์ที่แตกต่างโดยสิ้นเชิง ซึ่งมีความยืดหยุ่นและเป็นมิตรกับนักพัฒนามากกว่าระบบ Oracle ที่เคยทำให้สโตรโปรซีเยอร์มีชื่อเสียงในแง่ลบ
บริบททางประวัติศาสตร์:
- ปลายทศวรรษ 1990: Oracle stored procedures สำหรับ business logic
- ต้นทศวรรษ 2000: การผสมผสานระหว่าง Delphi/Oracle เป็นเรื่องปกติ
- 2007: ยังคงแพร่หลายในสภาพแวดล้อมองค์กร
- 2016: Sivers เริ่มการพัฒนาที่มี PostgreSQL เป็นศูนย์กลาง (9 ปีที่แล้ว)
- 2024: การอภิปรายและการแชร์เฟรมเวิร์กในปัจจุบัน
การนำไปใช้ทางเทคนิคและเครื่องมือสนับสนุน
การนำไปปฏิบัติจริงเกี่ยวข้องกับนวัตกรรมอันชาญฉลาดหลายประการ เทมเพลต HTML ถูกเก็บไว้ในฐานข้อมูลโดยตรง แต่แก้ไขในไฟล์ท้องถิ่น จากนั้นซิงโครไนซ์โดยใช้สคริปต์ที่สร้างขึ้นเอง ฟังก์ชัน PostgreSQL จัดการการแยกวิเคราะห์เทมเพลตโดยใช้ไวยากรณ์ Mustache และส่งกลับการตอบสนอง HTTP ที่สมบูรณ์ซึ่งรวมถึงรหัสสถานะ ส่วนหัว และเนื้อหา HTML ระบบใช้ pgTAP สำหรับการทดสอบ โดยรักษาฐานข้อมูลทดสอบแยกต่างหากเพื่อรับประความน่าเชื่อถือของฟังก์ชันโดยไม่กระทบต่อข้อมูลในสภาพแวดล้อมการผลิต
สถาปัตยกรรมนี้แสดงถึงการลดความซับซ้อนอย่างมากของโมเดลเว็บแอปพลิเคชันสามชั้นแบบดั้งเดิม โดยการยุบชั้นแอปพลิเคชันลงในฐานข้อมูล นักพัฒนาสามารถลดจำนวนส่วนประกอบที่เคลื่อนไหวและจุดล้มเหลวที่อาจเกิดขึ้นได้ แนวทางนี้เหมาะเป็นพิเศษสำหรับแอปพลิเคชันที่มีความสัมพันธ์ของข้อมูลและกฎทางธุรกิจที่ซับซ้อน โดยใช้ประโยชน์จากความสามารถในการจัดการธุรกรรมและคุณสมบัติความสมบูรณ์ของข้อมูลที่แข็งแกร่งของ PostgreSQL
โครงการในชุมชนที่มีแนวคิดคล้ายคลึงกัน
การอภิปรายได้เผยให้เห็นโครงการอื่นๆ อีกหลายโครงการที่กำลังสำรวจพื้นที่ที่คล้ายกัน PostgREST ถูกกล่าวถึงบ่อยครั้งในฐานะโครงการที่สร้าง REST API โดยอัตโนมัติจากโครงสร้างฐานข้อมูล PostgreSQL โดยตรง โครงการอื่นๆ ที่ถูกอ้างอิงรวมถึง SpacetimeDB ซึ่งนำแนวคิดฐานข้อมูลในฐานะเซิร์ฟเวอร์แอปพลิเคชันไปไกลยิ่งขึ้นไปอีก นักพัฒนาคนหนึ่งได้แชร์แนวทางทดลองของตนเองในการให้บริการการรับส่งข้อมูลเว็บโดยตรงจาก SQLite ซึ่งแสดงให้เห็นถึงความสนใจที่กว้างขวางในสถาปัตยกรรมที่ให้ความสำคัญกับฐานข้อมูล
โครงการเหล่านี้มีปรัชญาร่วมกัน นั่นคือ หากฐานข้อมูลของคุณมีความสามารถในการจัดการการดำเนินการที่ซับซ้อนได้อย่างมีประสิทธิภาพ แล้วทำไมต้องเพิ่มชั้นที่ไม่จำเป็นซึ่งนำความซับซ้อนและจุดติดขัดด้านประสิทธิภาพที่อาจเกิดขึ้นมาให้ แนวทางนี้ท้าทายความรู้แบบดั้งเดิมที่ว่าฐานข้อมูลควรเป็นเพียงระบบจัดเก็บข้อมูลที่ทำงานแบบพื้นฐาน ในขณะที่เซิร์ฟเวอร์แอปพลิเคชันจัดการลอจิกทั้งหมด
โปรเจกต์เฟรมเวิร์กเว็บ PostgreSQL ที่สำคัญที่ถูกกล่าวถึง:
- sivers/sivers: เฟรมเวิร์กเว็บ PostgreSQL แบบกำหนดเองของ Derek Sivers ที่ใช้ Mustache templating
- PostgREST: สร้าง REST APIs จาก PostgreSQL schemas โดยอัตโนมัติ
- SpacetimeDB: Database-engine ที่ออกแบบมาโดยเฉพาะสำหรับ application logic
- rumca-js/web_link_browser: ตัวอย่างของเว็บแอปพลิเคชันที่เน้น SQLite เป็นศูนย์กลาง
อนาคตของการพัฒนาเต็มสแต็ก
การสนทนาได้触及 ถึงแนวโน้มที่กว้างขึ้นในการพัฒนาเว็บ ซึ่งรวมถึงการกลับมาของการเรนเดอร์ฝั่งเซิร์ฟเวอร์และการแบ่งงานระหว่างนักพัฒนา Frontend และ Backend ในขณะที่มาตรฐานเว็บพัฒนาขึ้นเพื่อจัดการกับการอัปเดตเนื้อหาแบบไดนามิกโดยไม่ต้องโหลดหน้าใหม่ทั้งหมด นักพัฒนาบางคนตั้งคำถามว่าเรายังต้องการความซับซ้อนในการจัดการสถานะฝั่งไคลเอ็นต์อย่างกว้างขวางอยู่หรือไม่
แนวทางที่ให้ความสำคัญกับฐานข้อมูลมีศักยภาพที่จะเชื่อมช่องว่างระหว่างบทบาทของ Frontend และ Backend ได้ ทำให้นักพัฒนาสามารถมุ่งเน้นไปที่กรณีการใช้งานทางธุรกิจ แทนที่จะเป็นสัญญา API ระหว่างระบบที่แยกจากกัน ซึ่งอาจนำไปสู่ประสบการณ์การพัฒนาที่เหนียวแน่นยิ่งขึ้น และอาจนำไปสู่วงจรการพัฒนาที่เร็วขึ้นสำหรับแอปพลิเคชันบางประเภท
การอภิปรายที่ยังคงดำเนินอยู่ชี้ให้เห็นว่าเราอาจอยู่ที่จุดเริ่มต้นของการประเมินสถาปัตยกรรมเว็บแอปพลิเคชันครั้งใหญ่ ในขณะที่ฐานข้อมูลมีความสามารถมากขึ้นและทีมพัฒนามองหาวิธีลดความซับซ้อน แนวทางที่ใช้ประโยชน์จากความสามารถของฐานข้อมูลอย่างเต็มที่อาจได้รับการยอมรับในวงกว้างมากขึ้น ไม่ว่าสิ่งนี้จะแสดงถึงการเปลี่ยนแปลงพื้นฐานหรือเป็นเพียงแนวทางเฉพาะสำหรับกรณีการใช้งานบางอย่าง ยังคงต้องรอเวลาพิสูจน์ แต่การอภิปรายอย่างจริงจังบ่งชี้ว่าหัวข้อนี้触及 ถึงคำถามสำคัญเกี่ยวกับวิธีการสร้างซอฟต์แวร์ในยุคสมัยใหม่
อ้างอิง: sivers/sivers