Manifest ซึ่งเป็นโซลูชันไมโครแบ็กเอนด์แบบไฟล์เดียวใหม่ ได้จุดประกายการถกเถียงที่สำคัญในชุมชนนักพัฒนาเกี่ยวกับแนวทางการทำให้การพัฒนาแบ็กเอนด์ง่ายขึ้น ออกแบบมาสำหรับการสร้างต้นแบบอย่างรวดเร็ว ไมโครเซอร์วิส และแอปพลิเคชันที่เน้น CRUD Manifest มีเป้าหมายที่จะมอบคุณสมบัติแบ็กเอนด์ที่จำเป็นในไฟล์เดียวซึ่งสามารถผสานเข้ากับโค้ดเบสที่มีอยู่ได้โดยตรง อย่างไรก็ตาม ชุมชนได้ตั้งคำถามสำคัญเกี่ยวกับโมเดลความปลอดภัย การใช้งานฐานข้อมูล และข้อจำกัดของคุณสมบัติต่างๆ
ข้อกังวลด้านความปลอดภัยชี้ให้เห็นถึงความท้าทายในการนำไปใช้
นักพัฒนาที่ตรวจสอบ Manifest ได้ระบุปัญหาด้านความปลอดภัยหลายประการที่อาจก่อให้เกิดความเสี่ยงที่สำคัญสำหรับผู้ใช้ หนึ่งในประเด็นที่น่ากังวลมากที่สุดที่ถูกกล่าวถึงซ้ำๆ คือระบบสิทธิ์เริ่มต้น ซึ่งอนุญาตการเข้าถึงสาธารณะโดยอัตโนมัติสำหรับการกระทำใดๆ ที่ไม่มีนโยบายระบุไว้ จุดอันตราย นี้ ตามที่ผู้แสดงความคิดเห็นรายหนึ่งอธิบาย หมายความว่านักพัฒนาต้องระมัดระวังอย่างยิ่งในการกำหนดสิทธิ์อย่างชัดเจนสำหรับทุกเอนทิตีและการกระทำ มิฉะนั้นอาจเสี่ยงต่อการเปิดเผยข้อมูลที่ละเอียดอ่อนและการดำเนินการต่างๆ ให้กับผู้ใช้ที่ไม่ได้รับการยืนยันตัวตน
ปัญหาความปลอดภัยอีกประการหนึ่งที่ถูกระบุในตอนแรกคือการใช้ SHA-3 สำหรับการแฮชรหัสผ่านแทนที่จะเป็นอัลกอริทึมที่เหมาะสมกว่าซึ่งออกแบบมาโดยเฉพาะสำหรับการจัดเก็บรหัสผ่าน ในขณะที่ทีม Manifest ได้อัปเดตเป็น bcrypt แล้ว การมองข้ามนี้ไม่ได้สะท้อนในเอกสารของพวกเขาจนกระทั่งสมาชิกในชุมชนชี้ให้เห็น ซึ่งทำให้เกิดคำถามเกี่ยวกับแนวทางที่เน้นความปลอดภัยเป็นอันดับแรกของโครงการ
คุณลักษณะสำคัญของ Manifest:
- ระบบการยืนยันตัวตน
- การตรวจสอบข้อมูล
- ความสามารถในการจัดเก็บ
- การปรับขนาดรูปภาพ
- แผงควบคุมสำหรับผู้ดูแลระบบ
- จุดเชื่อมต่อแบบไดนามิก
- REST API
- JavaScript SDK
- เว็บฮุค
ข้อจำกัดที่ชุมชนระบุ:
- โมเดลสิทธิ์การเข้าถึงเริ่มต้น (เข้าถึงได้แบบสาธารณะเว้นแต่จะระบุเป็นอย่างอื่น)
- ขาดการล็อคฐานข้อมูลที่เหมาะสม
- ไม่มีเครื่องมือสำหรับการย้ายข้อมูล (อยู่ระหว่างการพัฒนา)
- เคยใช้ SHA-3 สำหรับการแฮชรหัสผ่าน (ปัจจุบันอัปเดตเป็น bcrypt)
- โครงสร้างไดเรกทอรีที่ซับซ้อนแม้จะมีการตลาดแบบ "ไฟล์เดียว"
โซลูชันที่คล้ายกันที่ถูกกล่าวถึง:
- PocketBase
- PostgREST
- Prisma + PostgREST
การใช้งานฐานข้อมูลก่อให้เกิดคำถามเกี่ยวกับความน่าเชื่อถือ
การวิเคราะห์ทางเทคนิคของโค้ดเบส Manifest เผยให้เห็นข้อกังวลเกี่ยวกับการใช้งานฐานข้อมูลพื้นฐาน นักพัฒนาคนหนึ่งสังเกตเห็นการขาดกลไกการล็อคที่เหมาะสม โดยเตือนว่าการรันหลายอินสแตนซ์พร้อมกันอาจทำให้ข้อมูลเสียหาย ปัญหาสถาปัตยกรรมพื้นฐานนี้บ่งชี้ถึงปัญหาความน่าเชื่อถือที่อาจเกิดขึ้นสำหรับแอปพลิเคชันที่มีผู้ใช้หรือกระบวนการพร้อมกัน
ดูเหมือนว่ามันไม่ได้ใช้การล็อค ดังนั้นการรันสองอินสแตนซ์จะทำให้ 'ฐานข้อมูล' ของคุณเสียหาย... น่าจะดีกว่าถ้าใช้ sqlite แทน!
การขาดเครื่องมือการย้ายข้อมูล (migration tools) ยังถูกเน้นย้ำว่าเป็นข้อจำกัดที่สำคัญ แม้ว่านักพัฒนา Manifest ได้ตอบกลับว่าการซิงโครไนซ์ฐานข้อมูลในปัจจุบันจัดการกับการเปลี่ยนแปลงโครงสร้าง โดยมีแผนที่จะพัฒนาการย้ายข้อมูลที่เหมาะสมในอนาคต
การเปรียบเทียบกับโซลูชันที่มีอยู่
ผู้แสดงความคิดเห็นหลายคนได้เปรียบเทียบระหว่าง Manifest กับเครื่องมือที่คล้ายกันเช่น PocketBase, PostgREST และเฟรมเวิร์กแบบดั้งเดิม PocketBase ปรากฏเป็นทางเลือกที่ถูกกล่าวถึงบ่อยซึ่งมีแนวทางแบ็กเอนด์ที่เรียบง่ายคล้ายกันแต่มีการใช้งานที่สมบูรณ์กว่า นักพัฒนาหลายคนแบ่งปันประสบการณ์เชิงบวกในการใช้ PocketBase สำหรับโครงการขนาดเล็ก ซึ่งบ่งชี้ว่าอาจเป็นตัวเลือกที่น่าเชื่อถือมากกว่าสำหรับการใช้งานจริงในปัจจุบัน
ทีม Manifest เน้นย้ำว่าจุดแตกต่างของผลิตภัณฑ์ของพวกเขาคือการใช้โค้ดเป็นหลัก ซึ่งช่วยให้นักพัฒนาสามารถทำงานใน IDE ของตนและใช้ประโยชน์จากเครื่องมือ AI เช่น GitHub Copilot หรือ Cursor เพื่อสร้างแบ็กเอนด์ แนวทางที่เน้นโค้ดเป็นอันดับแรกนี้ โดยใช้ DSL ที่อิงจาก YAML ถูกเน้นย้ำว่าเป็นมิตรกับ AI เป็นพิเศษเมื่อเทียบกับบริการแบ็กเอนด์ที่ใช้ UI แม้ว่าบางคนจะตั้งคำถามถึงความจำเป็นของการใช้อิโมจิในการประกาศเอนทิตี
โครงสร้างโครงการและประสบการณ์นักพัฒนา
นักพัฒนาบางคนแสดงความกังวลเกี่ยวกับการจัดระเบียบโครงการ โดยสังเกตว่าแม้จะทำการตลาดว่าเป็นไมโครแบ็กเอนด์ไฟล์เดียว แต่ repository GitHub ของ Manifest มีไฟล์และการพึ่งพามากมาย ผู้แสดงความคิดเห็นคนหนึ่งได้แบ่งปันวิธีการประเมินคุณภาพของโครงการโดยวัดว่าพวกเขาต้องเข้าไปในลำดับชั้นของไดเรกทอรีลึกแค่ไหนก่อนที่จะพบโค้ดการใช้งานจริง ซึ่งบ่งชี้ว่า Manifest ไม่ได้ทำได้ดีตามเกณฑ์นี้
แนวทางการกำหนดค่าที่อิงจาก YAML ได้รับข้อเสนอแนะที่หลากหลาย ในขณะที่บางคนชื่นชมความเรียบง่าย คนอื่นๆ ตั้งคำถามเกี่ยวกับตัวเลือกการออกแบบ เช่น การใช้อิโมจิที่ดูเหมือนจะเป็นข้อบังคับในการประกาศเอนทิตี ซึ่งไม่ได้อธิบายไว้ในเอกสาร ทีม Manifest ยอมรับว่าพวกเขาสามารถปรับปรุงเอกสารเกี่ยวกับการตัดสินใจในการออกแบบเหล่านี้ได้
แม้จะมีข้อกังวลเหล่านี้ นักพัฒนาหลายคนแสดงความสนใจในแนวคิดและศักยภาพในการใช้ประโยชน์สำหรับโครงการขนาดเล็ก ต้นแบบ และ MVP ทีม Manifest มีส่วนร่วมอย่างแข็งขันกับข้อเสนอแนะ ยอมรับปัญหา และบ่งชี้ถึงแผนการปรับปรุง
เช่นเดียวกับโครงการในระยะเบต้าอื่นๆ Manifest นำเสนอแนวทางที่น่าสนใจในการทำให้การพัฒนาแบ็กเอนด์ง่ายขึ้น แต่ต้องพิจารณาข้อจำกัดปัจจุบันอย่างรอบคอบก่อนนำไปใช้ในสิ่งที่นอกเหนือจากโครงการทดลอง การตอบสนองของทีมต่อข้อเสนอแนะจากชุมชนบ่งชี้ถึงศักยภาพในการเติบโตและปรับปรุงเมื่อโครงการพัฒนาขึ้น
อ้างอิง: manifest