ใน React แอปพลิเคชัน isomorphic หมายถึงแอปพลิเคชันที่ใช้โค้ดทั้งหมดหรือบางส่วนร่วมกันระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ และยังอาจเรียกว่าแอปพลิเคชัน JavaScript สากลก็ได้ แอปพลิเคชัน isomorphic ไม่ต้องการการเรนเดอร์เนื้อหาฝั่งเบราว์เซอร์ แต่บรรลุความสมดุลระหว่างฝั่งเซิร์ฟเวอร์และ การเรนเดอร์ฝั่งเบราว์เซอร์ สร้างเนื้อหาการเรนเดอร์บนเซิร์ฟเวอร์ และอนุญาตให้ผู้ใช้ดูเพจพร้อมข้อมูลโดยเร็วที่สุด
สภาพแวดล้อมการทำงานของบทช่วยสอนนี้: ระบบ Windows 10, รีแอคเวอร์ชัน 17.0.1, คอมพิวเตอร์ Dell G3
แอปพลิเคชัน Isomorphic หรือที่เรียกว่าแอปพลิเคชัน JavaScript สากล หมายถึงแอปพลิเคชันที่ใช้โค้ดร่วมกันทั้งหมด (หรือบางส่วน) ระหว่างไคลเอนต์และเซิร์ฟเวอร์ ด้วยการเรียกใช้โค้ด JavaScript ของแอปพลิเคชันบนฝั่งเซิร์ฟเวอร์ หน้าเว็บจึงสามารถเติมเนื้อหาล่วงหน้าก่อนที่จะถูกส่งไปยังเบราว์เซอร์ ดังนั้นผู้ใช้สามารถเห็นเนื้อหาก่อนที่ JavaScript ของเบราว์เซอร์จะทำงานด้วยซ้ำ เมื่อ JavaScript ในเครื่องทำงาน มันจะเข้ามาแทนที่การโต้ตอบและการนำทางที่ตามมา ทำให้ผู้ใช้สามารถได้รับประสบการณ์การโต้ตอบที่ราบรื่นในแอปพลิเคชันหน้าเดียวผ่านการโหลดครั้งแรกที่รวดเร็วและการแสดงผลหน้าฝั่งเซิร์ฟเวอร์
มอร์ฟิซึ่มคืออะไร
ด้วยการเพิ่มขึ้นอย่างกะทันหันของ Node.js การพัฒนาส่วนหน้าและส่วนหลังจึงมีรากฐานของภาษาการเขียนโปรแกรมที่ได้มาตรฐาน กลไกการพึ่งพาของบุคคลที่สาม ฯลฯ ล้วนมีโอกาสที่จะตระหนักถึงการรวมส่วนหน้าและส่วนหลังเข้าด้วยกัน -จบ. React เป็นคนแรกที่เป็นผู้นำเทรนด์นี้ และแนวคิดเรื่อง isomorphism ได้แพร่กระจายอย่างกว้างขวางมากขึ้น
สิ่งที่ผู้อ่านต้องเข้าใจคือแอปพลิเคชันแบบ isomorphic ไม่ต้องการการเรนเดอร์เนื้อหาฝั่งเบราว์เซอร์ แต่ต้องการความสมดุลระหว่างการเรนเดอร์ฝั่งเซิร์ฟเวอร์และฝั่งเบราว์เซอร์ แล้วจะเข้าใจความสมดุลนี้ได้อย่างไร?
สร้างเนื้อหาการเรนเดอร์บนเซิร์ฟเวอร์เพื่อให้ผู้ใช้สามารถดูเพจที่ให้ข้อมูลได้โดยเร็วที่สุด นอกเหนือจากเนื้อหาคงที่แล้ว แอปพลิเคชันที่สมบูรณ์ยังรวมถึงการตอบสนองต่อเหตุการณ์ต่างๆ การโต้ตอบของผู้ใช้ ฯลฯ ซึ่งหมายความว่าจะต้องดำเนินการสคริปต์ JavaScript บนฝั่งเบราว์เซอร์เพื่อทำงานให้เสร็จสิ้น เช่น การผูกเหตุการณ์และการจัดการการโต้ตอบแบบอะซิงโครนัส
จากมุมมองของประสิทธิภาพและประสบการณ์ผู้ใช้ การเรนเดอร์ฝั่งเซิร์ฟเวอร์ควรแสดงข้อมูลหลักและข้อมูลพื้นฐานที่สำคัญที่สุดของเพจ ในขณะที่ฝั่งเบราว์เซอร์จำเป็นต้องเรนเดอร์เพจเพิ่มเติม การเชื่อมโยงเหตุการณ์ และฟังก์ชันที่ได้รับการปรับปรุงอื่น ๆ เพื่อการโต้ตอบ สิ่งที่เรียกว่ามอร์ฟฟิซึมหมายความว่าส่วนหน้าและส่วนหลังใช้ชุดโค้ดหรือตรรกะร่วมกัน ในชุดโค้ดหรือตรรกะนี้ สถานการณ์ในอุดมคติคือการตัดสินโครงสร้าง DOM ที่มีอยู่และโครงสร้างที่จะแสดงผลในระหว่างกระบวนการเรนเดอร์เพิ่มเติมใน ฝั่งเบราว์เซอร์จะเหมือนเดิมหรือไม่ หากเป็นเช่นนั้น โครงสร้าง DOM จะไม่ถูกเรนเดอร์ใหม่ มีเพียงการโยงเหตุการณ์เท่านั้น
จากมิตินี้ ไอโซมอร์ฟิซึมจะแตกต่างจากการเรนเดอร์ฝั่งเซิร์ฟเวอร์ Isomorphism เป็นเหมือนจุดตัดระหว่างการเรนเดอร์ฝั่งเซิร์ฟเวอร์และเรนเดอร์ฝั่งเบราว์เซอร์ มันชดเชยความแตกต่างระหว่างฝั่งเซิร์ฟเวอร์และฝั่งเบราว์เซอร์ เพื่อที่จะเหมือนกัน ชุดของรหัสหรือตรรกะสามารถรวมเป็นหนึ่งเดียวได้ แกนกลางของมอร์ฟิซึมคือ "รหัสชุดเดียวกัน" ซึ่งเป็นอีกมิติหนึ่งที่แยกออกจากมุมที่ปลายทั้งสองข้าง
ข้อดีและข้อเสียของมอร์ฟิซึม
ข้อดีของมอร์ฟิซึมมีดังนี้:
ประสิทธิภาพที่ดีขึ้น ประสิทธิภาพที่นี่ส่วนใหญ่หมายถึงการเรนเดอร์ที่เร็วขึ้น เวลาแสดงหน้าจอแรกเร็วขึ้น ไฟล์น้อยลง และขนาดไฟล์เล็กลง
รองรับการเพิ่มประสิทธิภาพ SEO หลังจากได้รับคำขอแล้ว เซิร์ฟเวอร์จะส่งคืนเอกสาร HTML ที่ค่อนข้างสมบูรณ์ซึ่งมีเนื้อหาเริ่มต้น ซึ่งเอื้อต่อโปรแกรมรวบรวมข้อมูลของเครื่องมือค้นหาในการรับข้อมูลและปรับปรุงอันดับการแสดงผลการค้นหา ในขณะเดียวกัน เวลาในการโหลดหน้าเว็บที่เร็วขึ้นจะช่วยปรับปรุงอันดับการแสดงผลการค้นหาด้วย
การนำไปปฏิบัติมีความยืดหยุ่นมากขึ้น การแสดงผลฝั่งเซิร์ฟเวอร์จะแสดงเฉพาะเนื้อหาเริ่มต้นของหน้าเท่านั้น และเบราว์เซอร์ยังคงต้องติดตามผลเพื่อนำเสนอหน้าขั้นสุดท้ายให้เสร็จสมบูรณ์ ด้วยวิธีนี้ การเรนเดอร์ฝั่งเซิร์ฟเวอร์และการเรนเดอร์ฝั่งเบราว์เซอร์ยังคงสมดุลได้ และสามารถนำโค้ดกลับมาใช้ซ้ำได้ในระดับสูง
บำรุงรักษาได้มากขึ้น เนื่องจากด้วยความช่วยเหลือของไลบรารี เช่น React เราจึงสามารถใช้โค้ดซ้ำได้หลากหลาย โดยหลีกเลี่ยงความจำเป็นที่เซิร์ฟเวอร์และเบราว์เซอร์จะต้องรักษาโค้ดหรือตรรกะสองชุดในเวลาเดียวกัน ส่งผลให้ปริมาณโค้ดโดยรวมน้อยลงและค่าบำรุงรักษาก็ลดลง
เป็นมิตรกับรุ่นล่างมากขึ้น เนื่องจากการเรนเดอร์เนื้อหาครั้งแรกเสร็จสมบูรณ์บนฝั่งเซิร์ฟเวอร์ จึงเป็นมิตรกับโมเดลระดับล่างมากกว่า และจะไม่ทำให้เกิดหน้าจอสีขาวเมื่อโหลดเพจ
เป็นมิตรกับสภาพแวดล้อมเครือข่ายที่รุนแรงมากขึ้น ในวิธีการแยกส่วนหน้าและส่วนหลังแบบดั้งเดิม เนื้อหาของหน้าจะแสดงหลังจากดาวน์โหลดและดำเนินการสคริปต์ JavaScript ทั้งหมดแล้วเท่านั้น เพิ่มความยากในการแสดงผลเนื้อหาพื้นฐานของหน้าอย่างไม่ต้องสงสัย ในเรื่องนี้ การใช้งานแบบไอโซมอร์ฟิกมีข้อดีอย่างชัดเจน
ประสบการณ์การใช้งานที่ดีขึ้น เพื่อให้สมดุลระหว่างเนื้อหาการเรนเดอร์ฝั่งเซิร์ฟเวอร์และฝั่งเบราว์เซอร์อย่างสมเหตุสมผลมากขึ้น เราสามารถออกแบบส่วนหลักที่สำคัญของเพจให้แล้วเสร็จบนฝั่งเซิร์ฟเวอร์ ในขณะที่ส่วนโต้ตอบที่สำคัญน้อยกว่าสามารถเรนเดอร์โดยเบราว์เซอร์หรือหลังจาก มีการแสดงเนื้อหาที่สำคัญมากขึ้น การนำไปปฏิบัติจะช่วยปรับปรุงประสบการณ์ผู้ใช้อย่างมาก
ข้อเสียของมอร์ฟิซึมมีดังนี้:
ตรรกะการประมวลผลฝั่งเซิร์ฟเวอร์เพิ่มขึ้น ความซับซ้อนเพิ่มขึ้น
เซิร์ฟเวอร์ไม่สามารถใช้โค้ดฝั่งเบราว์เซอร์ซ้ำได้อย่างสมบูรณ์
เพิ่มเวลา TTFB (Time To First Byte) บนฝั่งเซิร์ฟเวอร์ เวลา TTFB หมายถึงเวลาที่เบราว์เซอร์เริ่มต้นคำขอเครือข่ายเริ่มต้นจนถึงเวลาที่ได้รับไบต์แรกจากเซิร์ฟเวอร์ ประกอบด้วยเวลาการเชื่อมต่อ TCP เวลาในการส่งคำขอ HTTP และเวลาที่จะได้รับไบต์แรกของข้อความตอบกลับ เนื่องจากการได้มาของข้อมูลและการเรนเดอร์เนื้อหาเริ่มต้นของเพจจะลดความเร็วของการส่งคืนเซิร์ฟเวอร์อย่างหลีกเลี่ยงไม่ได้
ขยายความรู้ของคุณ:
การออกแบบสถาปัตยกรรมส่วนหน้าและส่วนหลังและแนวคิดการเรนเดอร์ฝั่งเซิร์ฟเวอร์
แนวคิดเรื่องการเรนเดอร์หรือดรอปอินฝั่งเซิร์ฟเวอร์กำลังได้รับความนิยมมากขึ้นเรื่อยๆ ก่อนที่จะทำความเข้าใจวิธีการใช้การเรนเดอร์ฝั่งเซิร์ฟเวอร์ตาม React เราจำเป็นต้องมีความเข้าใจโดยรวมเกี่ยวกับการเรนเดอร์ฝั่งเซิร์ฟเวอร์ "ในอดีตและปัจจุบัน" ในระดับสถาปัตยกรรม: เหตุใดแนวคิดดังกล่าวจึงปรากฏขึ้น แก้ไขได้หลังจากนำแนวคิดนี้ไปใช้ การเรนเดอร์ฝั่งเซิร์ฟเวอร์ และข้อดีและข้อเสียของวิธีการอื่นคืออะไร
วิวัฒนาการของเทคโนโลยีความร่วมมือส่วนหน้าและส่วนหลัง
ในช่วงเริ่มต้นของการพัฒนาเว็บ การออกแบบสถาปัตยกรรมนั้นเรียบง่ายและตรงไปตรงมา โดยเฉพาะอย่างยิ่ง เพจนี้ถูกสร้างขึ้นบนฝั่งเซิร์ฟเวอร์โดย JSP, PHP และวิศวกรอื่นๆ และเบราว์เซอร์มีหน้าที่รับผิดชอบในการแสดงเพจเท่านั้น ในขณะนั้น วิศวกรส่วนหน้าจำเป็นต้องเพิ่มเอฟเฟกต์โต้ตอบแบบไดนามิกให้กับเพจแบบคงที่เท่านั้น และแทบไม่เกี่ยวข้องกับตรรกะข้อมูล ฯลฯ ในขณะที่วิศวกรส่วนหลังมีหน้าที่รับผิดชอบเนื้อหาของเพจ นั่นคือ เมื่อผู้ใช้ ร้องขอเพจ ส่วนแบ็คเอนด์ก็ประมวลผลและส่งคืนเพจสแตติกที่สมบูรณ์ โดยทั่วไปกระบวนการเหล่านี้อาศัยเอ็นจิ้นเทมเพลตในการทำให้เสร็จสมบูรณ์ ในเวลานั้น ยังไม่มีตำแหน่งวิศวกรส่วนหน้าแยกต่างหาก แม้ว่าจะมีข้อบกพร่องของแนวทางนี้ชัดเจน เช่น การแบ่งความรับผิดชอบระหว่างส่วนหน้าและส่วนหลังไม่ชัดเจน
หากบุคลากรส่วนหน้าพัฒนาเทมเพลต ส่วนหน้าจะขึ้นอยู่กับสภาพแวดล้อมแบ็คเอนด์อย่างมาก ทำให้ยากต่อการเพิ่มประสิทธิภาพการพัฒนาให้สูงสุด ในเวลาเดียวกัน ค่าใช้จ่ายในการสื่อสารเกี่ยวกับรูปแบบข้อมูลจะค่อนข้างสูง นอกจากนี้ โมเดลสถาปัตยกรรมดังกล่าวยังมีพื้นที่จำกัดมากสำหรับการพัฒนาเทคโนโลยีส่วนหน้าและการใช้ความสามารถของเบราว์เซอร์
ด้วยการพัฒนาอย่างรวดเร็วของเทคโนโลยีส่วนหน้า โดยเฉพาะอย่างยิ่งการเกิดขึ้นของเทคโนโลยี เช่น AJAX และ Node.js โมเดลสถาปัตยกรรมที่แยกส่วนหน้าและส่วนหลังได้ถือกำเนิดขึ้น ในโหมดนี้ การแบ่งงานระหว่างส่วนหน้าและส่วนหลังมีความชัดเจนมากและจุดการทำงานร่วมกันที่สำคัญที่ปลายทั้งสองคืออินเทอร์เฟซ AJAX มาดูหน้าการเข้าถึงของผู้ใช้เป็นตัวอย่างเพื่อทำความเข้าใจโมเดลนี้ทีละขั้นตอน ดังแสดงในรูปด้านล่าง