แอปพลิเคชั่นหน้าเดียว: ข้อดีและข้อเสีย [ปิด]

ฉันเคยอ่านเกี่ยวกับสปาและข้อดีแล้ว ฉันพบว่าพวกเขาส่วนใหญ่ไม่มั่นใจ มี 3 ข้อได้เปรียบที่กระตุ้นความสงสัยของฉัน

คำถาม: คุณสามารถทำหน้าที่เป็นผู้สนับสนุนของ SPA และพิสูจน์ได้ว่าฉันผิดเกี่ยวกับสามข้อความแรก?

                              === ADVANTAGES ===

1. SPA นั้นดีมากสำหรับเว็บไซต์ที่ตอบสนองได้ดีมาก:

การเรนเดอร์ฝั่งเซิร์ฟเวอร์นั้นยากที่จะนำไปใช้กับสถานะกลางทั้งหมด - สถานะมุมมองขนาดเล็กไม่ได้จับคู่กับ URL ได้ดี

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

เกิดอะไรขึ้นกับการถือเลเยอร์โมเดลสำหรับผู้ที่ไม่ใช่สปา SPA เป็นสถาปัตยกรรมที่เข้ากันได้กับ MVC เพียงด้านเดียวหรือไม่

2. ด้วย SPA เราไม่จำเป็นต้องใช้ข้อความค้นหาพิเศษไปยังเซิร์ฟเวอร์เพื่อดาวน์โหลดหน้าต่างๆ

ฮะและผู้ใช้สามารถดาวน์โหลดได้กี่หน้าในระหว่างการเยี่ยมชมเว็บไซต์ของคุณ สองสาม? มีปัญหาด้านความปลอดภัยอื่นปรากฏขึ้นและคุณต้องแยกหน้าเข้าสู่ระบบหน้าผู้ดูแลระบบ ฯลฯ ออกเป็นหน้าอื่น ๆ ในทางกลับกันมันขัดแย้งกับสถาปัตยกรรม SPA

3. อาจเป็นข้อได้เปรียบอื่น ๆ ? ไม่ได้ยินเรื่องอื่นเลย ..

                            === DISADVANTAGES ===

1. ลูกค้าจะต้องเปิดใช้งานจาวาสคริปต์
2. เพียงหนึ่งจุดเข้าสู่ไซต์
3. ความปลอดภัย

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

มาดูหนึ่งในไซต์สปาที่ได้รับความนิยมมากที่สุดของ GMail

1. SPA นั้นดีมากสำหรับเว็บไซต์ที่ตอบสนองได้ดีมาก:

การแสดงผลด้านเซิร์ฟเวอร์เป็นไม่ยากอย่างที่มันเคยเป็นด้วยเทคนิคง่ายๆเช่นการรักษา #hash ใน URL หรือเมื่อเร็ว ๆ นี้HTML5 pushStateด้วยวิธีนี้สถานะที่แน่นอนของแอปพลิเคชันเว็บจะถูกฝังใน URL ของหน้า เช่นเดียวกับใน GMail ทุกครั้งที่คุณเปิดเมลแท็กแฮชพิเศษจะถูกเพิ่มเข้าไปใน URL หากคัดลอกและวางไปที่หน้าต่างเบราว์เซอร์อื่นสามารถเปิดอีเมลเดียวกันได้ (หากพวกเขาสามารถรับรองความถูกต้อง) วิธีการนี้แมปโดยตรงกับสายอักขระแบบสอบถามแบบดั้งเดิมมากขึ้นความแตกต่างเป็นเพียงการดำเนินการ ด้วย HTML5 pushState () คุณสามารถกำจัด#hashและใช้ URL คลาสสิกอย่างสมบูรณ์ซึ่งสามารถแก้ไขได้บนเซิร์ฟเวอร์ในคำขอแรกจากนั้นโหลดผ่าน ajax ในคำขอถัดไป

2. ด้วย SPA เราไม่จำเป็นต้องใช้ข้อความค้นหาพิเศษไปยังเซิร์ฟเวอร์เพื่อดาวน์โหลดหน้าต่างๆ

จำนวนหน้าที่ผู้ใช้ดาวน์โหลดระหว่างการเยี่ยมชมเว็บไซต์ของฉัน จริงๆแล้วมีกี่เมล์ที่อ่านเมื่อเขา / เธอเปิดบัญชีเมล์ของเขา / เธอ ฉันอ่าน> 50 ครั้งเดียว ตอนนี้โครงสร้างของอีเมลก็เกือบจะเหมือนกัน หากคุณจะใช้รูปแบบการเรนเดอร์ฝั่งเซิร์ฟเวอร์เซิร์ฟเวอร์จะทำการเรนเดอร์มันในทุกคำร้องขอ (กรณีทั่วไป) - ความกังวลด้านความปลอดภัย - คุณควร / ไม่ควรแยกหน้าสำหรับผู้ดูแลระบบ / การเข้าสู่ระบบที่ขึ้นอยู่กับโครงสร้างของเว็บไซต์ของคุณที่จะใช้ paytm.com เช่นกันการทำเว็บไซต์ SPA ไม่ได้หมายความว่าคุณเปิดจุดสิ้นสุดทั้งหมดสำหรับทุก ผู้ใช้ฉันหมายถึงฉันใช้แบบฟอร์มรับรองความถูกต้องกับเว็บไซต์สปาของฉัน - ในเฟรมเวิร์ก SPA ที่มีการใช้งานมากที่สุด Angular JS ผู้พัฒนาสามารถโหลดทั้ง html temple จากเว็บไซต์เพื่อให้สามารถทำได้ขึ้นอยู่กับระดับการพิสูจน์ตัวตนของผู้ใช้ การโหลด html ล่วงหน้าสำหรับทุกประเภทการรับรองความถูกต้อง '

3. อาจมีข้อได้เปรียบอื่น ๆ ? ไม่ได้ยินเรื่องอื่นเลย ..

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

ข้อดีที่ฉันคิดได้คือ:

1. การแสดงผล html เห็นได้ชัดว่าต้องใช้ทรัพยากรบางอย่างในขณะนี้ผู้ใช้ทุกคนที่เยี่ยมชมไซต์ของคุณกำลังทำสิ่งนี้อยู่ นอกจากนี้ยังไม่เพียง แต่การเรนเดอร์หลักเท่านั้นที่ทำในฝั่งไคลเอ็นต์แทนที่จะเป็นฝั่งเซิร์ฟเวอร์
2. ปัญหาเวลาวันที่ - ฉันแค่ให้เวลา UTC กับลูกค้าเป็นรูปแบบที่กำหนดไว้ล่วงหน้าและไม่สนใจเกี่ยวกับเขตเวลาที่ฉันปล่อยให้จาวาสคริปต์จัดการ นี่เป็นข้อได้เปรียบที่ดีมากที่ฉันต้องเดาโซนเวลาตามสถานที่ที่ได้รับจากผู้ใช้ IP
3. สำหรับฉันแล้วรัฐได้รับการดูแลเป็นอย่างดีใน SPA เพราะเมื่อคุณตั้งค่าตัวแปรแล้วคุณจะรู้ว่ามันจะอยู่ที่นั่น สิ่งนี้ให้ความรู้สึกในการพัฒนาแอพมากกว่าหน้าเว็บ สิ่งนี้ช่วยได้มากในการทำเว็บไซต์เช่น foodpanda, flipkart, amazon เพราะถ้าคุณไม่ได้ใช้สถานะฝั่งไคลเอ็นต์คุณกำลังใช้เซสชันราคาแพง
4. เว็บไซต์มีการตอบสนองอย่างมาก - ฉันจะยกตัวอย่างมากสำหรับการลองทำเครื่องคิดเลขในเว็บไซต์ที่ไม่ใช่สปา (ฉันรู้ว่ามันแปลก)

อัปเดตจากความคิดเห็น

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

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

ฉันเป็นนักปฏิบัติดังนั้นฉันจะพยายามมองเรื่องนี้ในแง่ของต้นทุนและผลประโยชน์

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

ข้อดี

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

ข้อเสีย

• การตรวจสอบประสิทธิภาพ - มือที่เชื่อมโยงกัน: โซลูชันการตรวจสอบประสิทธิภาพระดับเบราว์เซอร์ส่วนใหญ่ที่ฉันเห็นมุ่งเน้นเฉพาะเวลาโหลดหน้าเว็บเท่านั้นเช่นเวลาถึงไบต์แรกเวลาในการสร้าง DOM, การเดินทางไปกลับรอบเครือข่ายสำหรับ HTML, กิจกรรม onload เป็นต้น post-load ผ่าน AJAX จะไม่ถูกวัด มีวิธีแก้ไขที่ให้คุณใช้รหัสของคุณในการบันทึกการวัดที่ชัดเจนเช่นเมื่อคลิกลิงก์เริ่มตัวจับเวลาจากนั้นสิ้นสุดตัวจับเวลาหลังจากแสดงผลลัพธ์ AJAX และส่งข้อเสนอแนะนั้น ตัวอย่างเช่น New Relic รองรับฟังก์ชั่นนี้ ด้วยการใช้สปาคุณได้ผูกติดกับเครื่องมือที่เป็นไปได้เพียงไม่กี่อย่าง
• การทดสอบความปลอดภัย / การเจาะระบบ - การเชื่อมโยงมือ: การสแกนความปลอดภัยอัตโนมัติอาจมีปัญหาในการค้นหาลิงก์เมื่อเพจทั้งหมดของคุณถูกสร้างขึ้นแบบไดนามิกโดยกรอบงาน SPA อาจมีวิธีแก้ไขปัญหานี้ แต่คุณ จำกัด ตัวเองอีกครั้ง
• Bundling: ง่ายต่อการรับสถานการณ์เมื่อคุณดาวน์โหลดรหัสทั้งหมดที่จำเป็นสำหรับเว็บไซต์ทั้งหมดในการโหลดหน้าแรกซึ่งสามารถทำงานได้อย่างมากสำหรับการเชื่อมต่อที่มีแบนด์วิดท์ต่ำ คุณสามารถรวมไฟล์ JavaScript และ CSS ของคุณเพื่อพยายามโหลดชิ้นงานที่เป็นธรรมชาติมากขึ้นในขณะที่คุณไป แต่ตอนนี้คุณต้องดูแลการจับคู่นั้นและดูไฟล์ที่ไม่ตั้งใจเพื่อดึงผ่านการอ้างอิงที่ไม่เกิดขึ้นจริง (เพิ่งเกิดขึ้นกับฉัน) อีกครั้งแก้ไขได้ แต่มีค่าใช้จ่าย
• การปรับโครงสร้างบิกแบงใหม่: หากคุณต้องการเปลี่ยนแปลงสถาปัตยกรรมที่สำคัญเช่นพูดเปลี่ยนจากกรอบหนึ่งไปอีกกรอบหนึ่งเพื่อลดความเสี่ยงมันเป็นสิ่งที่พึงปรารถนาที่จะทำการเปลี่ยนแปลงเพิ่มเติม นั่นคือเริ่มต้นใช้งานใหม่โยกย้ายบนพื้นฐานเช่นต่อหน้าต่อคุณสมบัติ ฯลฯ แล้วปล่อยเก่าหลัง ด้วยแอพหลายหน้าแบบดั้งเดิมคุณสามารถสลับหนึ่งหน้าจาก Angular เป็น React จากนั้นสลับหน้าอื่นในการวิ่งครั้งต่อไป ด้วยสปามันทั้งหมดหรือเปล่า หากคุณต้องการเปลี่ยนคุณต้องเปลี่ยนแอปพลิเคชันทั้งหมดในครั้งเดียว
• ความซับซ้อนของการนำทาง: มีการใช้เครื่องมือเพื่อช่วยรักษาบริบทการนำทางใน SPA ของเช่น history.js, Angular 2 ซึ่งส่วนใหญ่อาศัยเฟรมเวิร์ก URL (#) หรือ API ประวัติที่ใหม่กว่า หากทุกหน้าเป็นหน้าแยกกันคุณไม่จำเป็นต้องทำอะไรเลย
• ความซับซ้อนของการหารหัส: โดยปกติเราคิดว่าเว็บไซต์เป็นหน้าเว็บ แอพที่มีหลายหน้ามักจะแบ่งพาร์ติชันโค้ดตามหน้าซึ่งช่วยบำรุงรักษา

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

ข้อเสีย

1. ลูกค้าจะต้องเปิดใช้งานจาวาสคริปต์ ใช่นี่เป็นข้อเสียที่ชัดเจนของ SPA ในกรณีของฉันฉันรู้ว่าฉันสามารถคาดหวังให้ผู้ใช้ของฉันเปิดใช้งาน JavaScript ถ้าคุณทำไม่ได้คุณจะทำสปาไม่ได้ นั่นเหมือนกับการพยายามปรับใช้แอป. NET กับเครื่องที่ไม่ได้ติดตั้ง. NET Framework

2. จุดเข้าสู่ไซต์เพียงจุดเดียว ผมแก้ปัญหานี้โดยใช้SammyJS 2-3 วันของการทำงานเพื่อให้การตั้งค่าการกำหนดเส้นทางของคุณถูกต้องและผู้คนจะสามารถสร้างที่คั่นหน้าลึกลงในแอปของคุณที่ทำงานอย่างถูกต้อง เซิร์ฟเวอร์ของคุณจะต้องเปิดเผยจุดปลายเดียว - จุดสิ้นสุด "ให้ HTML + CSS + JS สำหรับแอปนี้" แก่ฉัน (คิดว่าเป็นตำแหน่งดาวน์โหลด / อัปเดตสำหรับแอปพลิเคชันที่เตรียมไว้ล่วงหน้า) - และ JavaScript ฝั่งไคลเอ็นต์ที่คุณเขียนจะ จัดการรายการจริงลงในแอปพลิเคชัน

3. ความปลอดภัยปัญหานี้ไม่ได้มีเฉพาะใน SPAs คุณต้องจัดการกับความปลอดภัยในลักษณะเดียวกับเมื่อคุณมีแอพไคลเอ็นต์เซิร์ฟเวอร์ "โรงเรียนเก่า" (รุ่น HATEOAS ของการใช้ Hypertext เพื่อเชื่อมโยงระหว่างหน้า) เป็นเพียงว่าผู้ใช้กำลังร้องขอมากกว่า JavaScript ของคุณและผลลัพธ์เป็น HTML แทนที่จะเป็น JSON หรือบางรูปแบบข้อมูล ในแอพที่ไม่ใช่สปาคุณต้องรักษาความปลอดภัยของแต่ละหน้าบนเซิร์ฟเวอร์ในขณะที่ในแอพสปาคุณต้องรักษาความปลอดภัยจุดปลายข้อมูล (และหากคุณไม่ต้องการให้ไคลเอ็นต์ของคุณเข้าถึงรหัสทั้งหมดคุณต้องแยกจาวาสคริปต์ที่ดาวน์โหลดได้ออกเป็นส่วนต่าง ๆ ด้วยฉันแค่ผูกมันลงใน SammyJS-based routing ของเราเพื่อให้เบราว์เซอร์ร้องขอเท่านั้น สิ่งที่ลูกค้ารู้ว่าควรเข้าถึงโดยขึ้นอยู่กับภาระเริ่มต้นของบทบาทของผู้ใช้

ข้อดี

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

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

3. ความยืดหยุ่นในการออกแบบ UI ของคุณอาจเป็นข้อได้เปรียบที่สำคัญอื่น ๆ ที่ฉันได้พบ เมื่อฉันกำหนด API ของฉัน (ด้วย SDK ใน JavaScript) ฉันสามารถเขียนส่วนหน้าของฉันใหม่โดยไม่มีผลกระทบกับเซิร์ฟเวอร์นอกเหนือจากไฟล์ทรัพยากรคงที่บางตัว ลองทำด้วยแอป MVC แบบดั้งเดิม! :) (สิ่งนี้จะมีค่าเมื่อคุณมีการปรับใช้แบบสดและความสอดคล้องของ API ที่คุณกังวล)

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

ข้อเสียอย่างหนึ่งที่สำคัญของ SPA - SEO เฉพาะเมื่อเร็ว ๆ นี้ Google และ Bing เริ่มทำดัชนีหน้าเว็บที่ใช้ Ajax โดยการเรียกใช้ JavaScript ในระหว่างการรวบรวมข้อมูลและยังมีหลายกรณีที่หน้าถูกทำดัชนีไม่ถูกต้อง

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

อัปเดต 19.06.16:

นับตั้งแต่ที่เขียนคำตอบนี้เมื่อไม่นานมานี้ฉันได้รับประสบการณ์มากขึ้นกับแอพ Single Page (เช่น AngularJS 1.x) - ดังนั้นฉันจึงมีข้อมูลเพิ่มเติมที่จะแบ่งปัน

ในความคิดของฉันข้อเสียเปรียบหลักของแอปพลิเคชัน SPA คือ SEO ทำให้พวกเขา จำกัด เฉพาะแอป "แดชบอร์ด" เท่านั้น นอกจากนี้คุณจะมีช่วงเวลาที่ยากขึ้นในการแคชเมื่อเทียบกับโซลูชั่นแบบดั้งเดิม ตัวอย่างเช่นในการแคช ASP.NET ทำได้ง่ายมากเพียงแค่เปิด OutputCaching และคุณทำได้ดี: เพจ HTML ทั้งหมดจะถูกแคชตาม URL (หรือพารามิเตอร์อื่น ๆ ) อย่างไรก็ตามใน SPA คุณจะต้องจัดการแคชด้วยตนเอง (โดยใช้วิธีแก้ปัญหาบางอย่างเช่นแคชระดับที่สองแคชแม่แบบและอื่น ๆ )

ฉันต้องการทำให้กรณีสำหรับ SPA ดีที่สุดสำหรับแอปพลิเคชันที่ขับเคลื่อนด้วยข้อมูล แน่นอนว่า gmail นั้นเกี่ยวกับข้อมูลและเป็นตัวเลือกที่ดีสำหรับสปา

แต่ถ้าหน้าของคุณเป็นส่วนใหญ่สำหรับการแสดงผลเช่นหน้าข้อกำหนดในการให้บริการแสดงว่า SPA นั้นมีค่าใช้จ่ายสูงเกินไป

ฉันคิดว่าจุดที่น่าสนใจคือการมีไซต์ที่มีทั้งหน้าสไตล์สปาและแบบคงที่ / MVC ขึ้นอยู่กับหน้าเฉพาะ

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

สถานการณ์นี้ค่อนข้างเหมือนกับการใช้ Flash หลังจากไม่กี่ปีของประสบการณ์จำนวนเว็บไซต์ Flash เท่านั้นลดลงใกล้ศูนย์เนื่องจากปัจจัยการโหลด แต่เป็นองค์ประกอบของหน้ามันยังคงใช้งานอยู่

สำหรับ บริษัท เช่น google, amazon และอื่น ๆ ที่เซิร์ฟเวอร์ทำงานด้วยความจุสูงสุดในโหมด 24/7 ลดการรับส่งข้อมูลหมายถึงเงินจริง - ฮาร์ดแวร์น้อยกว่าพลังงานน้อยกว่าการบำรุงรักษาน้อยลง ลดการใช้งาน CPU จากเซิร์ฟเวอร์ไปยังไคลเอนต์และ SPAs เปล่งประกาย ข้อดีข้อเสียที่มีน้ำหนักเกินโดยไกล ดังนั้น SPA หรือไม่ SPA ขึ้นอยู่กับกรณีการใช้งาน

สำหรับการกล่าวถึงอื่น ๆ อาจไม่ชัดเจนนัก (สำหรับผู้พัฒนาเว็บ) ใช้สำหรับ SPAs: ขณะนี้ฉันกำลังมองหาวิธีที่จะใช้ GUIs ในระบบฝังตัวและสถาปัตยกรรมบนเบราว์เซอร์ดูเหมือนน่าสนใจสำหรับฉัน ตามเนื้อผ้ามีความเป็นไปได้ไม่มากนักสำหรับ UIs ในระบบฝังตัว - Java, Qt, wx, etc หรือเฟรมเวิร์กเชิงพาณิชย์ที่เหมาะสม หลายปีก่อน Adobe พยายามเข้าสู่ตลาดพร้อมแฟลช แต่ดูเหมือนจะไม่ประสบความสำเร็จ

ทุกวันนี้ในขณะที่ "ระบบสมองกลฝังตัว" มีประสิทธิภาพเทียบเท่ากับเมนเฟรมเมื่อหลายปีก่อน UI ที่อิงกับเบราว์เซอร์ที่เชื่อมต่อกับหน่วยควบคุมผ่านทาง REST เป็นวิธีแก้ปัญหาที่เป็นไปได้ ข้อดีคือเครื่องมือจานใหญ่สำหรับ UI โดยไม่มีค่าใช้จ่าย (เช่น Qt ต้องการ 20-30 $ ต่อหน่วยที่ขายโดยคิดค่าสิทธิ์เพิ่ม 3,000-4,000 $ ต่อนักพัฒนา

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

เนื่องจากไคลเอนต์เดียวคือเบราว์เซอร์ในตัวข้อเสียดังกล่าวเช่นความพร้อมใช้งาน JS, การบันทึกด้านเซิร์ฟเวอร์การรักษาความปลอดภัยจะไม่นับรวมอีกต่อไป

2. ด้วย SPA เราไม่จำเป็นต้องใช้ข้อความค้นหาพิเศษไปยังเซิร์ฟเวอร์เพื่อดาวน์โหลดหน้าต่างๆ

ฉันยังต้องเรียนรู้มาก แต่เนื่องจากฉันเริ่มเรียนรู้เกี่ยวกับสปาฉันรักพวกเขา

จุดนี้อาจสร้างความแตกต่างอย่างมาก

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

ให้ฉันนำเสนอสถานการณ์ พิจารณาว่าคุณมี 2 หน้า:

1. หน้าที่มีรายการผลิตภัณฑ์
2. หน้าเพื่อดูรายละเอียดของผลิตภัณฑ์เฉพาะ

พิจารณาว่าคุณอยู่ที่หน้ารายการ จากนั้นคุณคลิกที่ผลิตภัณฑ์เพื่อดูรายละเอียด แอปฝั่งไคลเอ็นต์จะทริกเกอร์คำขอ ajax 2 คำขอ:

1. คำขอให้รับวัตถุ json พร้อมรายละเอียดผลิตภัณฑ์
2. คำขอเพื่อรับเทมเพลต html ที่จะแทรกรายละเอียดผลิตภัณฑ์

จากนั้นแอปฝั่งไคลเอ็นต์จะแทรกข้อมูลลงในเทมเพลต html และแสดงมัน

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

คุณอาจบอกว่าในสปาที่ไม่ใช่เมื่อคุณเปิดรายละเอียดผลิตภัณฑ์คุณเพียง 1 คำขอและในสถานการณ์นี้เราทำ 2 ใช่ แต่คุณจะได้รับประโยชน์จากมุมมองโดยรวมเมื่อคุณสำรวจหลาย ๆ หน้าจำนวนคำขอจะลดลง และข้อมูลที่ถูกถ่ายโอนระหว่างฝั่งไคลเอ็นต์และเซิร์ฟเวอร์ก็จะลดลงเช่นกันเพราะแม่แบบ html จะถูกนำมาใช้ซ้ำ นอกจากนี้คุณไม่จำเป็นต้องดาวน์โหลดทุกคำขอไฟล์ css, รูปภาพ, javascript ทั้งหมดที่มีอยู่ในทุกหน้า

นอกจากนี้ลองพิจารณาว่าภาษาฝั่งเซิร์ฟเวอร์ของคุณคือ Java หากคุณวิเคราะห์คำขอ 2 ข้อที่ฉันกล่าวถึง 1 ข้อมูลการดาวน์โหลด (คุณไม่จำเป็นต้องโหลดไฟล์มุมมองใด ๆ และเรียกเครื่องมือการแสดงผลมุมมอง) และการดาวน์โหลดอื่น ๆ และเทมเพลต html แบบคงที่เพื่อให้คุณสามารถมี HTTP เว็บเซิร์ฟเวอร์ที่สามารถเรียกคืนได้ โดยตรงโดยไม่ต้องโทรไปที่เซิร์ฟเวอร์แอปพลิเคชัน Java ไม่มีการคำนวณใด ๆ !

ในที่สุด บริษัท ใหญ่ ๆ ก็ใช้ SPA: Facebook, GMail, Amazon พวกเขาไม่เล่นพวกเขามีวิศวกรที่ยิ่งใหญ่ที่สุดที่เรียนทั้งหมดนี้ ดังนั้นหากคุณไม่เห็นข้อได้เปรียบคุณสามารถไว้วางใจพวกเขาในตอนแรกและหวังว่าจะค้นพบพวกเขาตามถนน

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

ข้อเสีย : ในทางเทคนิคแล้วการออกแบบและการพัฒนาเริ่มแรกของ SPA นั้นซับซ้อนและสามารถหลีกเลี่ยงได้ เหตุผลอื่นที่ไม่ได้ใช้ SPA นี้อาจเป็น:

• a) ความปลอดภัย: แอปพลิเคชันหน้าเดียวมีความปลอดภัยน้อยกว่าเมื่อเทียบกับหน้าเว็บแบบดั้งเดิมเนื่องจาก cross site scripting (XSS)
• b) Memory Leak: การรั่วไหลของหน่วยความจำใน JavaScript สามารถทำให้คอมพิวเตอร์ที่ทรงพลังทำงานช้าลงได้ ในฐานะที่เป็นเว็บไซต์ดั้งเดิมสนับสนุนให้นำทางระหว่างหน้าดังนั้นหน่วยความจำรั่วใด ๆ ที่เกิดจากหน้าก่อนหน้าเกือบจะถูกชะล้างเหลือทิ้งน้อย
• c) ไคลเอนต์ต้องเปิดใช้งาน JavaScript เพื่อเรียกใช้ SPA แต่ในแอปพลิเคชันหลายหน้า JavaScript สามารถหลีกเลี่ยงได้อย่างสมบูรณ์
• d) SPA มีขนาดที่เหมาะสมทำให้เวลารอนาน เช่นทำงานกับ Gmail ด้วยการเชื่อมต่อที่ช้าลง

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

ลิงค์นี้จะอธิบายข้อดีและข้อเสียของแอปพลิเคชันหน้าเดียว

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

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

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

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

พยายามอย่าใช้ SPA โดยไม่ได้กำหนดวิธีรักษาความปลอดภัยและความเสถียรของ API ที่ฝั่งเซิร์ฟเวอร์ จากนั้นคุณจะเห็นข้อดีที่แท้จริงของการใช้สปา หากคุณใช้เซิร์ฟเวอร์ RESTful ที่ใช้ OAUTH 2.0 เพื่อความปลอดภัยคุณจะได้รับข้อกังวลพื้นฐานสองประการที่จะช่วยลดต้นทุนในการพัฒนาและบำรุงรักษา

1. สิ่งนี้จะย้ายเซสชั่น (และความปลอดภัย) ไปยังสปาและคลายเซิร์ฟเวอร์ของคุณจากค่าใช้จ่ายทั้งหมด
2. API ของคุณมีทั้งความเสถียรและยืดขยายได้ง่าย

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

ฉันเข้าใจว่านี่เป็นคำถามที่เก่ากว่า แต่ฉันต้องการเพิ่มข้อเสียอีกประการของแอปพลิเคชันหน้าเดียว:

หากคุณสร้าง API ที่ส่งคืนผลลัพธ์ในภาษาข้อมูล (เช่น XML หรือ JSON) แทนที่จะเป็นภาษาการจัดรูปแบบ (เช่น HTML) แสดงว่าคุณกำลังเปิดใช้งานการทำงานร่วมกันของแอปพลิเคชันที่มากขึ้นเช่นในแอปพลิเคชัน ความสามารถในการทำงานร่วมกันดังกล่าวมีประโยชน์อย่างมาก แต่อนุญาตให้ผู้คนเขียนซอฟต์แวร์เพื่อ "ขุด" (หรือขโมย) ข้อมูลของคุณ ข้อเสียนี้เป็นเรื่องปกติสำหรับ API ทั้งหมดที่ใช้ภาษาข้อมูลและไม่ใช่ SPA ทั่วไป (จริง ๆ แล้ว SPA ที่ขอให้เซิร์ฟเวอร์ใช้ HTML ที่แสดงผลล่วงหน้าจะหลีกเลี่ยงสิ่งนี้ แต่มีค่าใช้จ่ายในการแยกโมเดล / มุมมองที่ไม่ดี) ความเสี่ยงที่เกิดจากข้อเสียนี้สามารถบรรเทาได้ด้วยวิธีการต่าง ๆ เช่นการ จำกัด การร้องขอและการบล็อกการเชื่อมต่อเป็นต้น