การคิดและฝึกฝนการแยกส่วนหน้าโดยใช้การพัฒนาแบบเต็มรูปแบบ

คำนำ

เพื่อที่จะแก้ปัญหาต่าง ๆ ที่เกิดจากรูปแบบการพัฒนาเว็บแบบดั้งเดิมเราได้พยายามหลายครั้ง แต่เนื่องจากช่องว่างทางกายภาพระหว่างด้านหน้าและด้านหลังสิ้นสุดการแก้ปัญหาที่เราลองทำนั้นคล้ายกัน การเรียนรู้จากความเจ็บปวดวันนี้เราคิดใหม่คำจำกัดความของ "ด้านหน้าและด้านหลัง" และแนะนำ nodejs ซึ่งคุ้นเคยกับนักเรียนส่วนหน้าพยายามสำรวจโหมดการแยกส่วนหน้าใหม่ล่าสุด

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

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

1. การแยกส่วนหน้าคืออะไร?

ในระหว่างการสนทนาครั้งแรกภายในกลุ่มฉันพบว่าทุกคนมีความเข้าใจที่แตกต่างกันในการแยกส่วนหน้า เพื่อให้แน่ใจว่าพวกเขาสามารถหารือเกี่ยวกับช่องทางเดียวกันเราจะบรรลุข้อตกลงเกี่ยวกับสิ่งที่ "การแยกส่วนหน้า-แบ็กเอนด์" คืออะไร

ตัวอย่างของการแยกส่วนหน้าที่ทุกคนเห็นด้วยคือสปา (แอปพลิเคชันหน้าเดียว) ข้อมูลงานนำเสนอทั้งหมดที่ใช้โดยแบ็กเอนด์ผ่านอินเตอร์เฟสแบบอะซิงโครนัส (AJAX/JSONP) และ Front-end จะแสดงเท่านั้น

ในแง่หนึ่งสปาจะประสบความสำเร็จในการแยกส่วนหน้า แต่มีสองปัญหากับวิธีนี้:

ในบรรดาบริการเว็บสปามีสัดส่วนน้อยมาก ในหลาย ๆ สถานการณ์นอกจากนี้ยังมีโหมดไฮบริดแบบซิงโครนัส/ซิงโครนัส + แบบอะซิงโครนัสและสปาไม่สามารถใช้เป็นโซลูชันทั่วไปได้

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

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

front-end: รับผิดชอบในการดูและเลเยอร์คอนโทรลเลอร์

แบ็กเอนด์: รับผิดชอบเฉพาะเลเยอร์แบบจำลองการประมวลผลธุรกิจ/ข้อมูล ฯลฯ

เหตุใดการแบ่งความรับผิดชอบนี้จะถูกกล่าวถึงในภายหลัง

2. ทำไมเราควรแยกด้านหน้าและด้านหลัง

เกี่ยวกับปัญหานี้บทความของ Yu Bo อธิบายอย่างครอบคลุมในวิวัฒนาการของโมเดล R&D เว็บ ลองทบทวนสั้น ๆ :

2.1 สถานการณ์ที่ใช้งานได้สำหรับรูปแบบการพัฒนาที่มีอยู่

รูปแบบการพัฒนาที่กล่าวถึงโดย Yu Bo แต่ละคนมีสถานการณ์ที่เกี่ยวข้องของตัวเองและไม่มีใครมาแทนที่อีกอย่างหนึ่งอย่างสมบูรณ์

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

AJAX เป็นรูปแบบการพัฒนาสปาหลักซึ่งเหมาะสำหรับการพัฒนาสถานการณ์ประเภทแอพ แต่เหมาะสำหรับการสร้างแอพเท่านั้นเพราะ SEO และปัญหาอื่น ๆ ยากที่จะแก้ไข สำหรับระบบหลายประเภทวิธีการพัฒนานี้หนักเกินไป

2.2 ความรับผิดชอบด้านหน้าและด้านหลังไม่ชัดเจน

ในระบบที่มีตรรกะทางธุรกิจที่ซับซ้อนเรากลัวที่จะรักษารหัสผสมกับด้านหน้าและด้านหลัง เนื่องจากไม่มีข้อ จำกัด รหัสของเลเยอร์อื่น ๆ ของ MVC อาจปรากฏในแต่ละเลเยอร์ เมื่อเวลาผ่านไปไม่มีการบำรุงรักษาเลย

แม้ว่าการแยกด้านหน้าและด้านหลังไม่สามารถแก้ปัญหานี้ได้อย่างสมบูรณ์ แต่ก็สามารถบรรเทาได้อย่างมาก เพราะมันรับประกันจากระดับกายภาพที่คุณไม่สามารถทำได้

2.3 ปัญหาประสิทธิภาพการพัฒนา

เว็บของ Taobao นั้นขึ้นอยู่กับ MVC Framework Webx และสถาปัตยกรรมกำหนดว่าส่วนหน้าสามารถพึ่งพาส่วนหลังเท่านั้น

ดังนั้นรูปแบบการพัฒนาของเรายังคงที่ส่วนหน้าเขียนการสาธิตแบบคงที่และส่วนหลังแปลเป็นเทมเพลต VM ฉันจะไม่พูดถึงปัญหากับโมเดลนี้และฉันถูกวิพากษ์วิจารณ์มาเป็นเวลานาน

นอกจากนี้ยังเจ็บปวดที่จะพัฒนาโดยตรงตามสภาพแวดล้อมส่วนหลังและเป็นปัญหาในการกำหนดค่าติดตั้งและใช้งาน เพื่อแก้ปัญหานี้เราได้คิดค้นเครื่องมือต่าง ๆ เช่น Vmarket แต่ส่วนหน้ายังคงต้องเขียน VMS และพึ่งพาข้อมูลแบ็คเอนด์ดังนั้นประสิทธิภาพจึงยังไม่สูง

นอกจากนี้แบ็กเอนด์ไม่สามารถกำจัดจุดสนใจที่แข็งแกร่งในการแสดงผลและมุ่งเน้นไปที่การพัฒนาของชั้นตรรกะทางธุรกิจ

2.4 ข้อ จำกัด เกี่ยวกับประสิทธิภาพส่วนหน้า

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

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

3. จะแยกด้านหน้าและด้านหลังได้อย่างไร?

จะแยกด้านหน้าและด้านหลังได้อย่างไร? ในความเป็นจริงมีคำตอบในส่วนแรก:

front-end: รับผิดชอบในการดูและเลเยอร์คอนโทรลเลอร์

แบ็กเอนด์: รับผิดชอบเลเยอร์โมเดลการประมวลผลธุรกิจ/ข้อมูล ฯลฯ

ลองจินตนาการว่าถ้าผู้ควบคุมส่วนหน้าตัวควบคุมเราสามารถออกแบบ URL ได้เราสามารถตัดสินใจได้ว่าจะซิงโครไนซ์การแสดงผลบนเซิร์ฟเวอร์ตามฉากหรือเอาท์พุทข้อมูล JSON ตามข้อมูลเลเยอร์มุมมองและเรายังสามารถทำ bigpipe, comet, ซ็อกเก็ต ฯลฯ ตามความต้องการของชั้นนำเสนอ มันเป็นวิธีการใช้งานทั้งหมดที่กำหนดโดยข้อกำหนด

3.1 การพัฒนา "เต็มสแต็ค" ตาม nodejs

หากคุณต้องการใช้เลเยอร์ของตัวเลขด้านบนคุณจะต้องใช้บริการเว็บอย่างหลีกเลี่ยงไม่ได้เพื่อช่วยให้เราตระหนักถึงสิ่งที่เราทำก่อนและหลังแบ็กเอนด์ดังนั้นจึงมีชื่อ "การพัฒนาแบบเต็มสแต็คตาม NodeJS"

ภาพนี้ดูเรียบง่ายและเข้าใจง่าย แต่ยังไม่ได้ลองและจะมีคำถามมากมาย

ในโหมดสปาแบ็กเอนด์ได้จัดเตรียมอินเทอร์เฟซข้อมูลที่ต้องการและสามารถควบคุมส่วนหน้ามุมมองได้แล้ว ทำไมต้องเพิ่มเลเยอร์ NodeJS?

แล้วการเพิ่มอีกหนึ่งเลเยอร์?

การเพิ่มอีกหนึ่งเลเยอร์จะเพิ่มภาระงานของส่วนหน้า?

การเพิ่มอีกหนึ่งชั้นจะนำไปสู่ความเสี่ยงอีกชั้นหนึ่ง จะทำลายมันได้อย่างไร?

Nodejs สามารถทำอะไรได้ทำไมคุณยังต้องการ Java?

ไม่ใช่เรื่องง่ายที่จะอธิบายปัญหาเหล่านี้อย่างชัดเจน ให้ฉันพูดถึงกระบวนการทำความเข้าใจด้านล่าง

3.2 ทำไมต้องเพิ่มเลเยอร์ของ nodejs?

ในขั้นตอนนี้เราส่วนใหญ่พัฒนาโมเดล MVC แบ็กเอนด์ รูปแบบนี้เป็นอุปสรรคต่อประสิทธิภาพของการพัฒนาส่วนหน้าอย่างจริงจังและป้องกันไม่ให้แบ็คเอนด์มุ่งเน้นไปที่การพัฒนาธุรกิจ

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

NodeJs สามารถแก้ปัญหานี้ได้เป็นอย่างดี เราสามารถทำในสิ่งที่การพัฒนาช่วยให้เราทำมาก่อนและทุกอย่างดูเหมือนเป็นธรรมชาติ

3.3 ปัญหาด้านประสิทธิภาพ

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

นอกจากนี้เมื่อเราตัดสินใจที่จะผูกเราสามารถลดความสูญเสียโดยการเพิ่มประสิทธิภาพวิธีการสื่อสารและโปรโตคอลการสื่อสาร

ตัวอย่างเช่น:

หลังจากหน้ารายละเอียดทารก Taobao นั้นคงที่ยังมีข้อมูลจำนวนมากที่ต้องได้รับแบบเรียลไทม์เช่นโลจิสติกส์โปรโมชั่น ฯลฯ เนื่องจากข้อมูลนี้อยู่ในระบบธุรกิจที่แตกต่างกัน

ด้วย nodejs front-end สามารถพร็อกซีคำขอแบบอะซิงโครนัสทั้ง 5 ตัวใน NodeJs และสามารถทำ bigpipe ได้อย่างง่ายดาย การเพิ่มประสิทธิภาพนี้สามารถปรับปรุงประสิทธิภาพการแสดงผลทั้งหมดได้มาก

คุณอาจคิดว่าการส่งคำขอแบบอะซิงโครนัส 5 หรือ 6 ครั้งบนพีซี แต่ในด้านไร้สายมันแพงมากในการสร้างคำขอ HTTP บนโทรศัพท์มือถือของลูกค้า ด้วยการเพิ่มประสิทธิภาพนี้ประสิทธิภาพจะได้รับการปรับปรุงหลายครั้ง

รายละเอียด Taobao ขึ้นอยู่กับการเพิ่มประสิทธิภาพของ NodeJS เราอยู่ในระหว่างดำเนินการ หลังจากเปิดตัวฉันจะแบ่งปันกระบวนการเพิ่มประสิทธิภาพ

3.4 ปริมาณงานส่วนหน้าเพิ่มขึ้นหรือไม่?

เมื่อเทียบกับเพียงแค่การตัดหน้า/การสาธิตมันจะต้องเพิ่มขึ้นอีกเล็กน้อย แต่มีการเชื่อมโยงและการสื่อสารในโหมดปัจจุบัน กระบวนการนี้ใช้เวลามากมีแนวโน้มที่จะเกิดข้อบกพร่องและยากที่จะรักษา

ดังนั้นแม้ว่าปริมาณงานจะเพิ่มขึ้นเล็กน้อย แต่ประสิทธิภาพการพัฒนาโดยรวมจะดีขึ้นอย่างมาก

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

3.5 วิธีการควบคุมความเสี่ยงที่เกิดขึ้นจากการเพิ่มเลเยอร์โหนด?

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

3.6 โหนดสามารถทำอะไรได้ทำไมคุณยังต้องการ Java?

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

4. การแยกส่วนหน้าของ Taobao ของ Taobao

ภาพด้านบนคือสิ่งที่ฉันเข้าใจเกี่ยวกับการแยกส่วนหน้าและการแยกส่วนหลังของ Taobao และการฝังรากลึกตามโหนดรวมถึงขอบเขตของความรับผิดชอบของโหนด คำอธิบายสั้น ๆ :

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

เซิร์ฟเวอร์อยู่ภายใต้แอปพลิเคชันโหนด

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

เลเยอร์โหนดยังสามารถบรรลุ VMCommon ดั้งเดิม, TMS (อ้างถึงระบบการจัดการเนื้อหา TAOBAO) และข้อกำหนดอื่น ๆ

เฟรมเวิร์กอะไรที่ใช้สำหรับเลเยอร์โหนดขึ้นอยู่กับนักพัฒนาในการตัดสินใจ อย่างไรก็ตามขอแนะนำให้ใช้การรวมกันของ Express + XTEMPLATE ซึ่งสามารถใช้สำหรับปลายด้านหน้าและด้านหลัง

ทุกคนตัดสินใจว่าจะใช้โหนดอย่างไร แต่สิ่งที่น่าตื่นเต้นคือในที่สุดเราก็สามารถใช้โหนดเพื่อใช้วิธีการส่งออกได้อย่างง่ายดายที่เราต้องการ: JSON/JSONP/RESTFUL/HTML/BIGPIPE/Comet/Socket/Synchronous และแบบอะซิงโครนัส มันสามารถทำได้ทุกอย่างที่คุณต้องการและมีการตัดสินใจทั้งหมดตามสถานการณ์ของคุณ

เลเยอร์เบราว์เซอร์ไม่ได้เปลี่ยนไปในสถาปัตยกรรมของเราและเราไม่ต้องการเปลี่ยนความเข้าใจก่อนหน้าของคุณเกี่ยวกับการพัฒนาในเบราว์เซอร์เนื่องจากการแนะนำของโหนด

การแนะนำโหนดเป็นเพียงการส่งมอบส่วนควบคุมส่วนหน้าซึ่งควรควบคุมโดยส่วนหน้า

เรามีสองโครงการในการพัฒนาในรูปแบบนี้ แม้ว่าพวกเขาจะยังไม่ได้เปิดตัว แต่เราได้ลิ้มรสความหวานในแง่ของประสิทธิภาพการพัฒนาและการเพิ่มประสิทธิภาพประสิทธิภาพ

5. เราต้องทำอะไรอีก?

รวมกระบวนการพัฒนาของ Node เข้ากับกระบวนการ SCM ที่มีอยู่ของ Taobao

การก่อสร้างโครงสร้างพื้นฐานเช่นเซสชันเครื่องบันทึกและโมดูลทั่วไปอื่น ๆ

แนวทางการพัฒนาที่ดีที่สุด

เรื่องราวความสำเร็จออนไลน์

ความเข้าใจของทุกคนเกี่ยวกับแนวคิดของการแยกโหนดด้านหน้าและด้านหลังสิ้นสุดลง

ความปลอดภัย

ผลงาน

-

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

6. "เกาะกลาง"

แม้ว่าโมเดล "การพัฒนาแบบเต็มซ้อนบนพื้นฐานของ Nodejs" นั้นน่าตื่นเต้น แต่ก็ยังมีอีกมากที่จะเปลี่ยนการพัฒนาแบบเต็มซ้อนตามโหนดเป็นสิ่งที่ทุกคนสามารถยอมรับได้ โครงการ "มิดเวย์" อย่างต่อเนื่องของเราคือการแก้ปัญหานี้ แม้ว่าเราจะไม่นานมานี้ แต่เราก็เข้าใกล้เป้าหมายของเรามากขึ้น! -