คู่มือนักพัฒนาในการปรับปรุงโครงสร้างโครงการในการใช้งาน Meteor

ในช่วงไม่กี่ปีที่ผ่านมา มีจำนวนเฟรมเวิร์ก JavaScript ที่พร้อมใช้งานเพิ่มขึ้นอย่างมาก ตั้งแต่ AngularJS ที่ทดลองจริงไปจนถึงคะแนนของเฟรมเวิร์กที่ออกมาทุกเดือน มีความหลากหลายที่น่าประทับใจให้เลือก สิ่งที่ดึงดูดความสนใจของฉันเมื่อสองสามปีก่อนคือเฟรมเวิร์กที่เรียกว่า Meteor Meteor ตั้งเป้าที่จะเป็นแพลตฟอร์มที่สมบูรณ์สำหรับการพัฒนาแอพ JavaScript ไม่เหมือนกับเฟรมเวิร์กส่วนใหญ่ สำหรับผู้ที่ยังใหม่กับ Meteor เราขอแนะนำให้คุณตรวจสอบจากเว็บไซต์ของพวกเขา บทความนี้จะไม่ใช่การแนะนำของ Meteor เราจะสำรวจวิธีง่ายๆ ในการแนะนำโครงสร้างในโครงการ Meteor แทน

ข้อดีอย่างหนึ่งของ Meteor ก็คือ มันง่ายมากที่จะสร้างต้นแบบแอปพลิเคชัน JavaScript ที่ซับซ้อนได้อย่างรวดเร็วด้วย เนื่องจาก Meteor เป็นลูกผสมของการสร้างเทมเพลตและการแสดงผลส่วนหน้าร่วมกับเซิร์ฟเวอร์ที่ใช้โหนดซึ่งมีปฏิสัมพันธ์กับ MongoDB (โซลูชันแบบรวมศูนย์) การตั้งค่าเริ่มต้นส่วนใหญ่ที่จำเป็นสำหรับการสร้างเว็บแอปแบบฟูลสแตกจึงเสร็จสิ้นแล้วสำหรับคุณ อย่างไรก็ตาม ความง่ายในการพัฒนาที่ให้มานั้นอาจเป็นกับดัก มันง่ายที่จะตกอยู่ในแนวปฏิบัติที่ไม่ดีและจบลงด้วยรหัสที่ไม่มีโครงสร้างที่สับสนเมื่อสร้างแอพ Meteor ฉันมีข้อเสนอแนะเล็กน้อยเกี่ยวกับวิธีการหลีกเลี่ยงสิ่งนี้

นั่งร้าน: ลำดับชั้นไดเรกทอรีที่จัดการได้ใน Meteor

อันดับแรก การรักษาโครงสร้างโฟลเดอร์ที่แนะนำไว้เป็นสิ่งสำคัญเมื่อสร้างแอปพลิเคชันของคุณ Meteor ให้คุณวางไฟล์ไว้ที่ใดก็ได้ภายในโฟลเดอร์โปรเจ็กต์ตามค่าเริ่มต้น - คุณสามารถมีโค้ดทั้งหมดของคุณในไฟล์เดียวได้หากต้องการ แม้ว่าสิ่งนี้อาจใช้ได้ผลสำหรับโปรเจ็กต์ Hackathon แต่ความซับซ้อนที่เกิดขึ้นในระดับการผลิตตามปกติ แอปที่ปรับขนาดได้นั้นจัดการได้ยากหากไม่มีโครงสร้างเสียง

เพื่อแก้ปัญหานี้ ฉันแนะนำให้ตรวจสอบเหล็กแพ็คเกจ npm ของ Chris Mather แพ็คเกจมีตัวเลือกการกำหนดค่าที่หลากหลาย ดังนั้นจึงเป็นการยากที่จะอธิบายที่นี่ แต่โดยทั่วไปแล้ว มันจะสร้างโครงสร้างโครงการที่จะมีลักษณะดังนี้:

 my-app/ |- .iron/ |- config.json |- bin/ |- build/ |- config/ |- development/ |- env.sh |- settings.json |- app/ |- client/ |- collections/ |- lib/ |- stylesheets/ |- templates/ |- head.html |- lib/ |- collections/ |- controllers/ |- methods.js |- routes.js |- packages/ |- private/ |- public/ |- server/ |- collections/ |- lib |- methods.js |- publish.js |- bootstrap.js

อย่างไรก็ตาม สำหรับบางโปรเจ็กต์ โครงสร้างโฟลเดอร์และไฟล์เช่นนี้อาจใช้เกินความจำเป็น ไม่ใช่ทุกโปรเจ็กต์จะต้องมีระดับการจัดระเบียบที่ละเอียดนี้ โดยมีการแยกคอลเล็กชัน เมธอด และโค้ดเผยแพร่บนเซิร์ฟเวอร์ สำหรับผู้ที่ไม่มีโปรเจ็กต์ใหญ่เกินไปหรือเพียงแค่ไม่ต้องการติดตั้งและเรียนรู้แพ็คเกจ npm อื่น ผมขอแนะนำโครงสร้างโฟลเดอร์พื้นฐานนี้:

องค์ประกอบหลักคือโฟลเดอร์สาธารณะที่มีไฟล์ต่างๆ เช่น favicon และทรัพย์สินแบบคงที่อื่นๆ และโฟลเดอร์ไคลเอ็นต์ ทั่วไป และเซิร์ฟเวอร์ โฟลเดอร์ไคลเอนต์และเซิร์ฟเวอร์ควร (แน่นอน) มีรหัสที่ทำงานบนไคลเอนต์และเซิร์ฟเวอร์ตามลำดับ โฟลเดอร์ทั่วไปประกอบด้วยรหัสที่ต้องสามารถเข้าถึงได้ทั้งไคลเอ็นต์และเซิร์ฟเวอร์ ตัวอย่างนี้คือ Schema code ซึ่งเราจะพูดถึงกันในอีกสักครู่

มีสองวิธีในการดำเนินการระดับต่ำสุดขององค์กร: วิธีหนึ่งคือตามประเภทไฟล์ และวิธีที่สองคือตามฟังก์ชัน การจัดระเบียบตามประเภทไฟล์หมายความว่าในโฟลเดอร์ไคลเอนต์/เทมเพลตของคุณ ตัวอย่างเช่น คุณจะมีสามโฟลเดอร์ - หนึ่งโฟลเดอร์สำหรับไฟล์ JavaScript หนึ่งโฟลเดอร์สำหรับ CSS และอีกหนึ่งโฟลเดอร์สำหรับ HTML โฟลเดอร์ HTML จะมีไฟล์ HTML ของเทมเพลตทั้งหมด เช่น Login.html, Main.html และอื่นๆ โฟลเดอร์ JavaScript และ CSS จะมีไฟล์เทมเพลตตามประเภทตามลำดับ ในทางกลับกัน การจัดระเบียบตามฟังก์ชัน หมายถึงการจัดระเบียบตามแนวคิดที่ไฟล์รวบรวมไว้ ตัวอย่างเช่น ในไคลเอนต์/เทมเพลต ฉันจะมีโฟลเดอร์ "เข้าสู่ระบบ" พร้อมไฟล์ JavaScript, CSS และ HTML ทั้งหมดที่เชื่อมโยงกับกระบวนการเข้าสู่ระบบของแอป ฉันชอบการจัดระเบียบตามฟังก์ชัน เพราะช่วยให้คุณเข้าใจได้ชัดเจนยิ่งขึ้นว่าคุณสามารถค้นหาไฟล์หรือโค้ดบางส่วนได้จากที่ใด อย่างไรก็ตาม มันไม่ได้เป็นเพียงภาพขาวดำเท่านั้น และบุคคลและทีมส่วนใหญ่จะใช้วิธีผสมกันเพื่อจัดโครงสร้างไฟล์และโฟลเดอร์ของตน

สคีมา: แอปของคุณต้องการแม้ว่าฐานข้อมูลของคุณจะไม่ต้องการ

โครงสร้างประเภทที่สองที่ฉันต้องการอภิปรายเกี่ยวข้องกับฐานข้อมูล บทความนี้อนุมานว่าคุณกำลังใช้ MongoDB หากคุณไม่เป็นเช่นนั้น แนวคิดก็อาจจะยังคงใช้อยู่ แต่เฉพาะจะไม่ใช้ ผู้ที่ใช้ MongoDB ทราบดีว่าช่วยให้เราจัดเก็บข้อมูลของเราเป็นแบบไม่มีโครงสร้างได้ เนื่องจาก MongoDB เป็นฐานข้อมูลที่เก็บเอกสาร NoSQL จึงไม่มีสคีมาตายตัวสำหรับ "ประเภท" ของข้อมูล อิสระนี้หมายความว่าคุณไม่ต้องกังวลเกี่ยวกับการทำให้แน่ใจว่าอ็อบเจกต์ทั้งหมดได้รับมาตรฐานให้อยู่ในรูปแบบที่เข้มงวด อันที่จริง ข้อมูลทั้งหมดของแอปของคุณอาจถูกรวมเข้าเป็นคอลเล็กชันเดียวได้หากต้องการ อย่างไรก็ตาม เมื่อพูดถึงการสร้างแอปที่มีคุณภาพระดับโปรดักชัน นี่ไม่ใช่สิ่งที่ต้องการจริงๆ เพื่อจัดการและเพิ่มคุณสมบัติที่มีประโยชน์ เช่น การตรวจสอบคำขอเขียน เราสามารถใช้แพ็คเกจ Meteor ที่ยอดเยี่ยมสองแพ็คเกจ: SimpleSchema และ Collection2 ของ Aldeed

แพ็คเกจ SimpleSchema ตามชื่อที่แนะนำ ช่วยให้คุณตรวจสอบวัตถุในแอพของคุณได้ ตรวจสอบเอกสารบน GitHub แพ็คเกจ Collection2 บูตสแตรปออกจาก SimpleSchema และให้คุณนำสคีมาที่เหมาะสมมาไว้ในคอลเลกชั่น Meteor สิ่งนี้เปิดใช้งานคือการตรวจสอบความถูกต้องอัตโนมัติของคำขอเขียนฝั่งเซิร์ฟเวอร์และไคลเอ็นต์ไปยังคอลเลกชันใดๆ ที่มีสคีมาแนบอยู่ แพ็คเกจทั้งสองนี้มีความลึกซึ้งและปรับแต่งได้ ดังนั้นจึงเป็นการยากที่จะทำความเข้าใจอย่างสมบูรณ์ในสองสามย่อหน้า แต่ฉันแนะนำให้คุณดูรายละเอียด readmes ที่ Aldeed ได้รวบรวมไว้สำหรับรายละเอียดเฉพาะ ฉันจะพูดถึงวิธีที่ฉันได้รับคุณค่าจากแพ็คเกจเหล่านี้ หนึ่งในสิ่งที่ดีที่สุดที่พวกเขาเปิดใช้งานคือการตรวจสอบความถูกต้องของการป้อนแบบฟอร์มของผู้ใช้ สิ่งนี้มีประโยชน์สำหรับการตรวจสอบเอกสารผู้ใช้ Meteor (จากแพ็คเกจบัญชี) ตามค่าเริ่มต้น ผู้ใช้ Meteor มีสคีมาที่ซับซ้อนอย่างน่าประหลาดใจ นี่คือภาพส่วนหนึ่งจากโค้ดที่ Aldeed ใจดีให้ใช้ได้:

 Schema.UserProfile = new SimpleSchema({ firstName: { type: String, optional: true }, lastName: { type: String, optional: true }, birthday: { type: Date, optional: true }, gender: { type: String, allowedValues: ['Male', 'Female'], optional: true }, organization : { type: String, optional: true }, website: { type: String, regEx: SimpleSchema.RegEx.Url, optional: true }, bio: { type: String, optional: true }, country: { type: Schema.UserCountry, optional: true } });

นั่นเป็นเพียงสคีมาสำหรับอ็อบเจ็กต์โปรไฟล์ของผู้ใช้ ความพยายามที่จะตรวจสอบความถูกต้องของวัตถุ User ทั้งหมดจะเป็นเรื่องที่ยุ่งเหยิงหากไม่มีแพ็คเกจที่สร้างขึ้นตามวัตถุประสงค์เช่น SimpleSchema แม้ว่าฟิลด์ทั้งหมดเหล่านี้จะไม่ปรากฎในรูปภาพ หากคุณต้องการให้ User schema ที่ตรวจสอบความถูกต้องถูกต้อง อาจจะไม่เป็นเช่นนั้น และสิ่งต่างๆ เช่น "Schema.UserCountry" จะเปลี่ยนเส้นทางไปยัง schema อื่นๆ เพื่อตรวจสอบความถูกต้อง โดยการแนบสคีมานี้เข้ากับออบเจกต์ผู้ใช้และรวมสิ่งนี้เข้ากับฟอร์มของเรา ซึ่งอาจใช้แพ็คเกจอย่าง Aldeed AutoForm ทำให้เราสามารถควบคุมสิ่งที่ไม่ได้ทำและไม่รวมอยู่ในฐานข้อมูลของเราได้อย่างดี ประหยัดเวลาและแรงงานด้วย แบบจำลองแนวคิดของวิธีจัดการข้อมูลในแอปพลิเคชันของเรา ซึ่งสามารถชี้และอภิปรายในเงื่อนไขที่เป็นรูปธรรมได้

บทบาท: สำหรับยุค 401 และ 403

คำแนะนำสุดท้ายที่ฉันมีสำหรับการจัดโครงสร้างและปรับปรุงโปรเจ็กต์ Meteor คือแพ็คเกจบทบาทของอลันนิ่ง นี่คือระบบการให้สิทธิ์สำหรับ Meteor และช่วยให้คุณตรวจสอบระดับการเข้าถึงของผู้ใช้สำหรับส่วนใดๆ ของเว็บแอปของคุณได้ สิทธิ์จะถูกแนบมากับโปรไฟล์ผู้ใช้ในรูปแบบของสตริงซึ่งจะถูกตรวจสอบในภายหลังหรือทำให้ใช้งานไม่ได้เมื่อผู้ใช้พยายามเข้าถึงวิธีการใดๆ ของ Meteor หรือข้อมูลที่เผยแพร่ไปยังไคลเอนต์ ตัวอย่างเช่น:

 if (Roles.userIsInRole(Meteor.userId(), "admin")) { tabsArr.push({ name: "Users", slug: "users" }); }

แม้ว่าแกนหลักของระบบจะค่อนข้างเรียบง่าย แต่ก็อนุญาตให้มีการอนุญาตที่ซับซ้อนและละเอียดสำหรับส่วนใด ๆ ของแอปพลิเคชันของคุณ เนื่องจากบทบาททั้งหมดถูกจัดเก็บเป็นสตริง คุณจึงสามารถตั้งค่าระบบที่ลึกเท่าที่คุณต้องการ - "admin", "admin.division1.manage", "admin.division1.manage.group2" และอื่นๆ

ปัญหาเกี่ยวกับเสรีภาพที่แพ็คเกจนี้อนุญาตคือการติดตามระบบบทบาทที่ละเอียดมากอาจเป็นเรื่องยาก แพ็คเกจมีฟังก์ชันต่างๆ เช่น “getAllRoles” ซึ่งเรียกเอาบทบาททั้งหมดที่คุณสร้างขึ้นตามชื่อ แต่ขึ้นอยู่กับคุณที่จะติดตามว่าความหมายทั้งหมดคืออะไร และเมื่อใดควรมีบทบาทที่กำหนด ถูกนำมาใช้ และสำหรับผู้ที่สงสัยว่า "บทบาท" กับ "การอนุญาต" แตกต่างกันอย่างไร สำหรับจุดประสงค์ของแพ็คเกจนี้ ไม่มีอะไรแตกต่างกันเลย

ห่อ

น่าเสียดาย เนื่องจากความกว้างของบทความ (แต่ละแพ็คเกจที่กล่าวถึงในที่นี้สมควรได้รับบทช่วยสอนของตัวเอง) จึงเป็นไปไม่ได้ที่จะลงรายละเอียดเกี่ยวกับแพ็คเกจใดโดยเฉพาะ แต่ฉันหวังว่าฉันจะให้ความกระจ่างเกี่ยวกับวิธีการทำงานเพื่อ "มาตรฐาน" ” แอปพลิเคชั่น Meteor ที่คุณมั่นใจจะทำงานได้ดีทั้งในด้านการผลิตและในขนาดต่างๆ หากคุณกำลังมองหาข้อมูลเพิ่มเติม ลองดูลิงค์ที่ฉันโพสต์และดูอีกสิ่งหนึ่งที่ไม่ได้ทำในบทความนี้ แต่มีประโยชน์ที่จะมีในแอป Meteor: แพ็คเกจ Restivus ซึ่งช่วยให้คุณ เพื่อแสดง REST API สำหรับแอปของคุณอย่างง่ายดาย

เพื่อเป็นการปฏิเสธความรับผิดชอบ ฉันไม่ใช่ผู้เขียนแพ็คเกจใด ๆ เหล่านี้ และฉันขออภัยหากฉันได้นำเสนอคุณสมบัติหรือจุดมุ่งหมายของแพ็คเกจใด ๆ อย่างไม่ถูกต้อง ขอบคุณสำหรับการอ่านและฉันหวังว่าบทความนี้จะเป็นประโยชน์กับคุณ อย่าลังเลที่จะติดต่อฉันหากมีคำถามใด ๆ หรือแสดงความคิดเห็นด้านล่าง