คำนำ
เมื่อแยกด้านหน้าและด้านหลังสิ้นสุดลงประเด็นแรกที่ฉันให้ความสนใจคือการเรนเดอร์นั่นคือทำงานในระดับมุมมอง
ในรูปแบบการพัฒนาแบบดั้งเดิมเบราว์เซอร์และเซิร์ฟเวอร์ได้รับการพัฒนาโดยสองทีมทั้งด้านหน้าและด้านหลัง แต่เทมเพลตอยู่ในพื้นที่ที่คลุมเครือระหว่างทั้งสอง ดังนั้นจึงมี logics ที่ซับซ้อนมากขึ้นเรื่อย ๆ บนเทมเพลตซึ่งในที่สุดก็ยากที่จะรักษา
และเราเลือก NodeJS เป็นชั้นกลางของด้านหน้าและด้านหลัง ลองใช้ NodeJS เพื่อล้างงานในระดับมุมมอง
สิ่งนี้ทำให้การแบ่งงานระหว่างด้านหน้าและด้านหลังสิ้นสุดลงอย่างชัดเจนทำให้โครงการได้รับการดูแลรักษาได้ดีขึ้นและบรรลุประสบการณ์การใช้งานที่ดีขึ้น
บทความนี้
งานแสดงผลเป็นสัดส่วนที่มีขนาดใหญ่มากของการทำงานประจำวันของนักพัฒนาส่วนหน้าและเป็นส่วนที่ง่ายที่สุดที่จะสับสนกับการพัฒนาด้านหลัง
เมื่อมองย้อนกลับไปในช่วงไม่กี่ปีที่ผ่านมาของการพัฒนาเทคโนโลยีส่วนหน้างานในระดับมุมมองได้ผ่านการเปลี่ยนแปลงมากมายเช่น:
แบบฟอร์มส่งการรีเฟรชแบบเต็มหน้า => AJAX Local Refresh
ความต่อเนื่องด้านเซิร์ฟเวอร์ + MVC => การเรนเดอร์ฝั่งไคลเอ็นต์ + MVC
การเปลี่ยนหน้าแบบดั้งเดิมการเปลี่ยนแปลง => แอปพลิเคชันหน้าเดียว
สามารถสังเกตได้ว่าในช่วงไม่กี่ปีที่ผ่านมาทุกคนมีแนวโน้มที่จะย้ายสิ่งนี้จากเซิร์ฟเวอร์สิ้นสุดไปยังจุดสิ้นสุดของเบราว์เซอร์
ฝั่งเซิร์ฟเวอร์มุ่งเน้นไปที่บริการและให้ข้อมูลอินเทอร์เฟซ
ประโยชน์ของการแสดงผลของเบราว์เซอร์
เราทุกคนรู้ถึงประโยชน์ของการแสดงผลด้านเบราว์เซอร์เช่น
1. กำจัดการมีเพศสัมพันธ์และความสับสนระหว่างตรรกะทางธุรกิจและตรรกะการนำเสนอในเอ็นจิ้นเทมเพลต Java
2. สำหรับแอปพลิเคชันหลายขั้วมันง่ายต่อการเชื่อมต่อ สองเทมเพลตที่แตกต่างกันทางด้านเบราว์เซอร์เพื่อนำเสนอแอปพลิเคชันที่แตกต่างกัน
3. การแสดงผลหน้าไม่เพียง แต่ HTML แต่การเรนเดอร์ที่ปลายด้านหน้าสามารถให้ฟังก์ชั่นในรูปแบบที่เป็นส่วนประกอบได้อย่างง่ายดาย (HTML + JS + CSS) เพื่อให้ส่วนประกอบส่วนหน้าไม่จำเป็นต้องพึ่งพาโครงสร้าง HTML ที่สร้างโดยเซิร์ฟเวอร์
4. กำจัดการพึ่งพาการพัฒนาและกระบวนการกระจายกลับ
5. การปรับร่วมที่สะดวกสบาย
ข้อเสียที่เกิดจากการแสดงผลของเบราว์เซอร์
แต่ในขณะที่เพลิดเพลินกับผลประโยชน์เรายังต้องเผชิญกับข้อเสียของการแสดงผลด้านเบราว์เซอร์เช่น:
1. เทมเพลตถูกคั่นด้วยไลบรารีที่แตกต่างกัน เทมเพลตบางส่วนจะถูกวางไว้บนฝั่งเซิร์ฟเวอร์ (Java) ในขณะที่บางส่วนจะถูกวางไว้ที่ด้านเบราว์เซอร์ (JS) ภาษาแม่แบบด้านหน้าและด้านหลังไม่ได้เชื่อมต่อ
2. คุณต้องรอเทมเพลตและส่วนประกอบทั้งหมดที่จะโหลดบนเบราว์เซอร์ก่อนที่การแสดงผลสามารถเริ่มต้นได้และคุณไม่สามารถอ่านได้ทันที
3. จะมีหน้าจอสีขาวรอการแสดงผลเป็นครั้งแรกซึ่งไม่เอื้อต่อประสบการณ์การใช้งานของผู้ใช้
4. เมื่อพัฒนาแอปพลิเคชันหน้าเดียวเส้นทางส่วนหน้าไม่ตรงกับเส้นทางฝั่งเซิร์ฟเวอร์ซึ่งเป็นปัญหาในการจัดการ
5. เนื้อหาที่สำคัญทั้งหมดจะรวมอยู่ที่ส่วนหน้าซึ่งไม่เอื้อต่อ SEO
ไตร่ตรองถึงคำจำกัดความของด้านหน้าและด้านหลัง
ในความเป็นจริงเมื่อเราใช้การแสดงผลจากฝั่งเซิร์ฟเวอร์ (Java) ไปยังฝั่งเบราว์เซอร์ (JS) จุดประสงค์ของเราคือการแบ่งความรับผิดชอบด้านหน้าและด้านหลังอย่างชัดเจนและไม่จำเป็นต้องแสดงเบราว์เซอร์
เป็นเพราะในรูปแบบการพัฒนาแบบดั้งเดิมเซิร์ฟเวอร์จะถูกปล่อยออกมาและถึงเบราว์เซอร์ดังนั้นเนื้อหาการทำงานในส่วนหน้าสามารถ จำกัด เฉพาะด้านเบราว์เซอร์เท่านั้น
ดังนั้นหลายคนได้พิจารณาแล้วว่า Backend = Server Frontend = ด้านเบราว์เซอร์เช่นเดียวกับภาพด้านล่าง
ในโครงการ Midway Midway กำลังดำเนินการโดย Taobao Ued โดยการสร้างชั้นกลางของ NodeJS ในกลางเบราว์เซอร์ Java เราพยายามแยกแยะความแตกต่างของสายการแข่งขันด้านหน้าและด้านหลังอีกครั้งสำหรับความรับผิดชอบในการทำงานแทนที่จะเป็นสภาพแวดล้อมของฮาร์ดแวร์ (เซิร์ฟเวอร์และเบราว์เซอร์)
ดังนั้นเราจึงมีโอกาสแบ่งปันเทมเพลตและเส้นทางซึ่งเป็นรัฐที่เหมาะที่สุดในการแบ่งส่วนหน้าและส่วนหลังของแรงงาน
Taobao Midway Midway
ในโครงการ Midway เราย้ายบรรทัดที่กำหนดขอบเขตด้านหน้าและด้านหลังสิ้นสุดจากเบราว์เซอร์ไปยังฝั่งเซิร์ฟเวอร์
ด้วยเลเยอร์ NodeJS ที่ควบคุมได้อย่างง่ายดายโดยส่วนหน้าและทั่วไปกับเบราว์เซอร์การแยกส่วนหน้าจะเสร็จสมบูรณ์ได้ชัดเจนยิ่งขึ้น
นอกจากนี้ยังเป็นไปได้ที่จะอนุญาตให้มีการพัฒนาส่วนหน้าเพื่อตัดสินใจวิธีแก้ปัญหาที่เหมาะสมที่สุดสำหรับสถานการณ์ที่แตกต่างกัน แทนที่จะเป็นทุกสิ่งที่ได้รับการจัดการทางด้านเบราว์เซอร์
การแบ่งความรับผิดชอบ
มิดเวย์ไม่ใช่โครงการที่ส่วนหน้าพยายามคว้างานแบ็คเอนด์ จุดประสงค์คือการตัดพื้นที่ที่คลุมเครือของแม่แบบอย่างชัดเจนและได้รับการแบ่งแยกที่ชัดเจนขึ้น
Backend (Java) มุ่งเน้นไปที่
1. ชั้นบริการ
2. รูปแบบข้อมูลและความเสถียรของข้อมูล
3. ตรรกะทางธุรกิจ
front-end มุ่งเน้นไปที่
1. UI Layer
2. ตรรกะการควบคุมการแสดงผลตรรกะ
3. การโต้ตอบประสบการณ์ผู้ใช้
และไม่ยึดติดกับความแตกต่างระหว่างเซิร์ฟเวอร์หรือเบราว์เซอร์อีกต่อไป
การแบ่งปันแม่แบบ
ในรูปแบบการพัฒนาแบบดั้งเดิมเบราว์เซอร์และเซิร์ฟเวอร์ได้รับการพัฒนาโดยสองทีมทั้งด้านหน้าและด้านหลัง แต่เทมเพลตอยู่ในพื้นที่ที่คลุมเครือระหว่างทั้งสอง ดังนั้นจึงมี logics ที่ซับซ้อนมากขึ้นเรื่อย ๆ บนเทมเพลตซึ่งในที่สุดก็ยากที่จะรักษา
ด้วย nodejs นักเรียนแบ็กเอนด์สามารถมุ่งเน้นไปที่การพัฒนาตรรกะทางธุรกิจและข้อมูลในเลเยอร์ Java นักเรียนส่วนหน้ามุ่งเน้นไปที่การพัฒนาตรรกะการควบคุมและการแสดงผล และคุณสามารถเลือกเทมเพลตเหล่านี้ด้วยตัวคุณเองเพื่อแสดงผลทางฝั่งเซิร์ฟเวอร์ (NodeJs) หรือด้านเบราว์เซอร์
การใช้ภาษาเทมเพลตเดียวกัน xtemplate และ JavaScript เอ็นจิ้นการเรนเดอร์เดียวกัน
แสดงผลลัพธ์เดียวกันในสภาพแวดล้อมการเรนเดอร์ที่แตกต่างกัน (ฝั่งเซิร์ฟเวอร์, เบราว์เซอร์พีซี, เบราว์เซอร์มือถือ, มุมมองเว็บ ฯลฯ )
การแบ่งปันเส้นทาง
นอกจากนี้เนื่องจากเลเยอร์ NodeJS คุณสามารถควบคุมการกำหนดเส้นทางได้อย่างระมัดระวังมากขึ้น
หากคุณต้องการกำหนดเส้นทางด้านเบราว์เซอร์ในส่วนหน้าคุณสามารถกำหนดค่าการกำหนดเส้นทางฝั่งเซิร์ฟเวอร์ในเวลาเดียวกันเพื่อที่จะสามารถเปลี่ยนหน้าเว็บในด้านเบราว์เซอร์หรือหน้าเว็บบนฝั่งเซิร์ฟเวอร์และคุณสามารถรับเอฟเฟกต์การเรนเดอร์ที่สอดคล้องกัน
ในเวลาเดียวกันปัญหา SEO ก็ถูกจัดการเช่นกัน
การปฏิบัติของการแบ่งปันแม่แบบ
โดยปกติเมื่อเราแสดงเทมเพลตบนเบราว์เซอร์กระบวนการจะไม่มีอะไรมากไปกว่า
ป้อนเครื่องยนต์เทมเพลตในเบราว์เซอร์ (XTMPleate, Juicer, Handlerbar ฯลฯ )
โหลดเทมเพลตเก็บถาวรที่ด้านเบราว์เซอร์วิธีการอาจเป็น
พิมพ์บนหน้าโดยใช้ <script type = "js/tpl"> ... </script>
ใช้เครื่องมือโหลดโมดูลเพื่อโหลดคลังเก็บแม่แบบ (kissy, requirejs ฯลฯ )
อื่น
รับข้อมูลและใช้เอ็นจิ้นเทมเพลตเพื่อสร้าง HTML
แทรก HTML ลงในตำแหน่งที่ระบุ
กระบวนการข้างต้นสามารถเห็นได้ว่าหากคุณต้องการที่จะบรรลุการแบ่งปันเทมเพลตข้ามส่วนปลายโฟกัสจะอยู่ในการเลือกโมดูลที่สอดคล้องกัน
มีมาตรฐานโมดูลยอดนิยมมากมายในตลาดเช่น KMD, AMD และ CommonJS ตราบใดที่การเก็บถาวรเทมเพลต NODEJS สามารถส่งออกไปยัง NodeJS จะสิ้นสุดผ่านข้อกำหนดของโมดูลที่สอดคล้องกันการแชร์เทมเพลตพื้นฐานสามารถทำได้
ชุดบทความที่ตามมาจะหารือเกี่ยวกับพร็อกซีและการแบ่งปันโมเดลต่อไป
การอภิปรายกรณี
เนื่องจากชั้นกลางของ Midway Island มีคำตอบที่ดีกว่าสำหรับคำถามที่ผ่านมาเช่น
แอปพลิเคชั่นที่ซับซ้อนในกรณีที่ 1 (เช่นตะกร้าสินค้าหน้าสั่งซื้อ)
สถานะ: HTML ทั้งหมดจะแสดงผลที่ส่วนหน้าและเซิร์ฟเวอร์จะให้เฉพาะอินเทอร์เฟซ
ปัญหา: เมื่อเข้าสู่หน้าจะมีหน้าจอสีขาวสั้น ๆ
คำตอบ:
ป้อนหน้าเป็นครั้งแรกแสดงหน้าเต็มในด้าน nodejs และดาวน์โหลดเทมเพลตที่เกี่ยวข้องในพื้นหลัง
การโต้ตอบที่ตามมาการรีเฟรชบางส่วนที่สมบูรณ์ทางด้านเบราว์เซอร์
การใช้เทมเพลตเดียวกันจะให้ผลลัพธ์เดียวกัน
กรณีที่ 2 แอปพลิเคชันหน้าเดียว
สถานะ: ใช้เฟรมเวิร์ก MVC ด้านไคลเอนต์เพื่อเปลี่ยนหน้าในเบราว์เซอร์
ปัญหา: การเรนเดอร์และการเปลี่ยนหน้าทั้งคู่เสร็จสมบูรณ์ทางด้านเบราว์เซอร์ เมื่อคุณเข้าสู่ URL โดยตรงหรือรีเฟรช F5 เนื้อหาเดียวกันไม่สามารถนำเสนอได้โดยตรง
คำตอบ:
แบ่งปันการตั้งค่าเส้นทางเดียวกันที่ด้านเบราว์เซอร์และด้าน nodejs
เมื่อเปลี่ยนหน้าเว็บด้านเบราว์เซอร์ให้เปลี่ยนเส้นทางและแสดงเนื้อหาหน้าเว็บที่ด้านเบราว์เซอร์
เมื่อป้อน URL เดียวกันโดยตรงให้ใช้เฟรมหน้า + การแสดงเนื้อหาหน้าเว็บที่ด้าน nodejs
ไม่ว่าคุณจะเปลี่ยนหน้าบนเบราว์เซอร์หรือป้อน URL เดียวกันโดยตรงเนื้อหาที่คุณเห็นจะเหมือนกัน
นอกเหนือจากการเพิ่มประสบการณ์และลดความซับซ้อนเชิงตรรกะ นอกจากนี้ยังแก้ไขปัญหา SEO
กรณีการท่องเว็บบริสุทธิ์สามหน้า
สถานะ: หน้าให้ข้อมูลเฉพาะการโต้ตอบน้อยลงหรือไม่มีเลย
ปัญหา: HTML ถูกสร้างขึ้นทางฝั่งเซิร์ฟเวอร์ CSS และ JS ถูกวางไว้ในที่อื่นและมีการพึ่งพาซึ่งกันและกัน
คำตอบ:
ผ่าน NodeJS การจัดการแบบครบวงจรของ HTML + CSS + JS
หากคุณต้องการขยายไปยังแอปพลิเคชันที่ซับซ้อนหรือแอปพลิเคชันหน้าเดียวในอนาคตคุณสามารถถ่ายโอนได้อย่างง่ายดาย
เคสหน้าเทอร์มินัลสี่ข้าม
สถานะ: แอปพลิเคชันเดียวกันจำเป็นต้องนำเสนออินเทอร์เฟซและการโต้ตอบที่แตกต่างกันที่จุดสิ้นสุดที่แตกต่างกัน
ปัญหา: การจัดการ HTML ไม่ใช่เรื่องง่ายและ HTML ที่แตกต่างกันมักจะถูกสร้างขึ้นบนฝั่งเซิร์ฟเวอร์และการประมวลผลที่แตกต่างกันจะทำในด้านเบราว์เซอร์
คำตอบ:
หน้าข้ามเทอร์มินัลเป็นปัญหาการแสดงผลและจัดการโดยส่วนหน้า
ผ่านบริการ NodeJS Layer และ Backend โซลูชั่นที่ดีที่สุดสามารถออกแบบมาสำหรับแอพพลิเคชั่นที่ซับซ้อนประเภทนี้
สรุป
การเกิดขึ้นของเทคโนโลยีเช่น AJAX, MVC ฝั่งไคลเอ็นต์, SPA, ข้อมูลสองทางที่มีผลผูกพันในอดีตล้วน แต่พยายามแก้ปัญหาคอขวดที่พบในการพัฒนาส่วนหน้าในเวลานั้น
การเกิดขึ้นของเลเยอร์ระดับกลางของ NodeJS ก็เป็นความพยายามที่จะแก้ข้อ จำกัด ว่าส่วนหน้านั้น จำกัด อยู่ที่เบราว์เซอร์ในปัจจุบัน
บทความนี้มุ่งเน้นไปที่การแบ่งปันเทมเพลตส่วนหน้าและส่วนหลังและหวังว่าจะดึงดูดความสนใจ มาพูดคุยกับคุณถึงวิธีการปรับปรุงเวิร์กโฟลว์ของเราและร่วมมือกับ Back-end เพื่อทำงานที่ดีขึ้นในส่วนหน้าภายใต้สถาปัตยกรรมชั้นกลางของ NodeJS