มีข้อได้เปรียบอะไรบ้างจากการใช้การแสดงผลหน้าฝั่งเซิร์ฟเวอร์

19

ฉันกำลังพัฒนาแอปพลิเคชันเว็บและฉันได้เขียนทั้งเว็บไซต์ใน html / js / css และในแบ็กเอนด์ฉันมี servlets ที่โฮสต์บริการ RESTFUL บางส่วน ตรรกะการนำเสนอทั้งหมดทำผ่านการรับออบเจ็กต์ json และแก้ไขมุมมองผ่านจาวาสคริปต์

แอปพลิเคชันนั้นเป็นเครื่องมือค้นหาเป็นหลัก แต่จะมีบัญชีผู้ใช้ที่มีบทบาทแตกต่างกัน

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

มันคือ: ความเร็ว? การพัฒนาและขั้นตอนการทำงานง่ายขึ้น? เข้าถึงไลบรารีที่มีอยู่หรือไม่ มากกว่า? ถูกทุกข้อ?

javascript web-applications frameworks

— user1303881
แหล่งที่มา

4

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

— Oded

2

@Oded - ทำไมการรักษาความปลอดภัยจึงง่ายขึ้นเมื่อคุณแสดงผลหน้าเว็บกับ API ฉันคิดอยู่เสมอว่าสิ่งที่คุณต้องทำคือการเทียบเคียงด้วยวิธีใดวิธีหนึ่ง แต่มันง่ายกว่า (อย่างน้อยสำหรับฉัน) ที่จะจำไม่ได้ว่าต้องไว้ใจลูกค้าเมื่อทำ API ฉันถามเพราะถ้าฉันมองสิ่งที่ฉันอยากรู้

— psr

1

@psr เขาอาจไม่อ้างถึงความปลอดภัยของข้อมูลมากเท่ากับความปลอดภัยของผู้ใช้ (เช่นการหาประโยชน์ MITM) เพียงแค่เดาว่า

— maple_shaft

1

@psr - ตกลง แต่เพียงเมื่อวานนี้ผมได้ตอบคำถามที่ OP มีสตริงการเชื่อมต่อที่ฝังอยู่ใน JS แล้ว ...

— Oded

1

@maple_shaft - MITM เป็นสิ่งที่คิด แต่อีกครั้งฉันไม่แน่ใจว่าทำไมมันสร้างความแตกต่างสำหรับ API กับเซิร์ฟเวอร์ที่สร้าง HTML ฉันคิดว่า API จะสะดวกกว่าในการเขียนโปรแกรมดังนั้นมันจะแตกง่ายขึ้นเล็กน้อย แต่ฉันสงสัยว่าคุณหมายถึงอะไร

— psr

16

การแสดงผล HTML ฝั่งเซิร์ฟเวอร์:

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

* เมื่อความต้องการของ UI เหมาะสมกับกรอบงานที่ดี

การแสดงผล HTML ฝั่งไคลเอ็นต์:

การใช้แบนด์วิดท์ต่ำ
การแสดงผลหน้าเว็บเริ่มต้นช้าลง อาจไม่เห็นด้วยในเบราว์เซอร์เดสก์ท็อปที่ทันสมัย หากคุณต้องการรองรับ IE6-7 หรือเบราว์เซอร์มือถือจำนวนมาก (mobile webkit ไม่เลว) คุณอาจพบปัญหาคอขวด
การสร้าง API อันดับแรกหมายถึงลูกค้าสามารถเป็นแอพที่เป็นกรรมสิทธิ์ลูกค้าแบบบางเว็บเซอร์วิสอื่น ๆ ได้อย่างง่ายดาย
พึ่งพาความเชี่ยวชาญของ JS
บางครั้งการพัฒนาเร็วขึ้น **

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

นอกจากนี้คุณยังอาจพิจารณารูปแบบไฮบริดที่มีการดำเนินงานที่แบ็กเอนด์ไฟใช้ front-end / templating ระบบแบ็กเอนด์เช่นหนวด

— peteorpeter
แหล่งที่มา

1

โอ้โหลืมโอกาสในการแคชอย่างสมบูรณ์!

— Michael K

"สำหรับ" แอป "มาตรฐานคุณสมบัติ UI มากมายถูกสร้างไว้ล่วงหน้า" ไม่เกี่ยวข้องทั้งเซิร์ฟเวอร์และไคลเอนต์มีสิ่งนั้น

— Raynos

@ Raynos เขาไม่ได้เอ่ยถึงการใช้เฟรมเวิร์กฝั่งไคลเอ็นต์แต่ถ้าเขาใช้อยู่นั่นเป็นจุดที่ดี

— peteorpeter

1

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

— user1303881

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

— null

3

การสร้าง HTML ฝั่งเซิร์ฟเวอร์:

ง่ายต่อการตรวจแก้จุดบกพร่อง;
ไม่มีปัญหากับความเข้ากันได้ของเบราว์เซอร์
ด้วยการสร้างฝั่งเซิร์ฟเวอร์แบบเต็มหน้าแบบคลาสสิกมันยากที่จะแคช HTML แม้ว่าจะมีชิ้นส่วนที่ไม่เปลี่ยนแปลงขนาดใหญ่ (วิธีแก้ปัญหาคือการดึงแฟรกเมนต์ HTML ผ่านการโทร AJAX)
ไม่ใช้ประโยชน์จาก caching-proxies และ CDNs สำหรับ HTML แบบไดนามิก;

การสร้าง HTML ฝั่งไคลเอ็นต์:

การดีบักยากขึ้น
ปัญหาบางอย่างกับเบราว์เซอร์ที่ล้าสมัย;
ไม่มีปัญหาการแคชแม่แบบ HTML ฝั่งไคลเอ็นต์;
การใช้ประโยชน์จากแคช - พร็อกซีและ CDN สำหรับ HTML- แม่แบบและรหัส JS;
การใช้เครือข่ายที่ต่ำกว่ามาก

โปรดทราบว่าการสร้างฝั่งไคลเอ็นต์นั้นเป็นวิธีที่ทำในกรณีที่ไซต์มือถือประสบความสำเร็จเนื่องจากเห็นได้ชัดว่ามันมีประสิทธิภาพมากขึ้นกับเบราว์เซอร์ที่ทันสมัย (เบราว์เซอร์ที่ใช้ WebKit มี 70-80% ของตลาดมือถือ)

LinkedIn มีบทความเกี่ยวกับข้อดีของวิธีการฝั่งไคลเอ็นต์โดยใช้dust.jsเป็นตัวอย่าง: "การปล่อย JSP ในฝุ่น: ย้าย LinkedIn ไปยังแม่แบบฝั่งไคลเอ็นต์ของ dust.js"

— vartec
แหล่งที่มา

1

+1 บนมาร์ทโฟนที่ทันสมัย (ใช้โทรศัพท์มือถือเป็นหลัก WebKit) JS ไม่น่าจะคอขวดในขณะที่แบนด์วิดธ์มือถือเครือข่ายคือ

— peteorpeter

1

ขึ้นอยู่กับความต้องการของคุณ หากคุณต้องการโซลูชันที่มีความหน่วงแฝงต่ำและมีประสิทธิภาพสูงซึ่งขึ้นอยู่กับงานเล็ก ๆ จำนวนมากคุณอาจไปกับโครงสร้างที่คล้ายกับสิ่งที่คุณอธิบาย วิธีแก้ปัญหาที่พบบ่อยที่สุดใน Java, PHP และ C # ไม่ได้เป็นค่าเริ่มต้น

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

ความปลอดภัย (ตามที่Odedระบุไว้) - คุณไม่ต้องการเปิดเผยเครือข่ายของคุณต่อสาธารณะ! โดยปกติแล้วอินเทอร์เฟซเดียวกับระบบของคุณจากภายนอกควรเป็น https ไปยังเซิร์ฟเวอร์ของคุณ
ความสะดวกในการพัฒนา - คุณจริงๆ, จริงๆ , จริงๆไม่ต้องการที่จะเขียน SQL ใน Javascript และภาษาที่ออกแบบมาสำหรับนำเสนอเว็บไม่ทำงานได้ดีกับ RDBs พวกเขาไม่มีแนวความคิดของรัฐเช่น

ดังนั้นเมื่อคุณต้องการฐานข้อมูลคุณใช้ภาษาที่สนุกกับพวกเขาเช่น Java, C #, PHP, ฯลฯ วิธีที่ง่ายที่สุดในการสร้างหน้าจะกลายเป็นดังนี้: คุณใช้ภาษา templating (PHP ที่มีชื่อเสียงที่สุด, แต่ JSP และ ASP เป็นอีกสองภาษาที่พบบ่อยมาก) เพื่อสร้างหน้า ภาษาจัดทำโครงสร้างที่เรียกไปยังโมดูลอื่น ใน PHP นี่เป็นปกติในหน้าหรือในไฟล์ PHP อื่นโดยใช้รูปแบบ MVC ใน JSP คุณใช้ scriptlets หรือ JSP Expression Language โมดูลอื่น ๆ เหล่านี้สามารถทำงานหนักในการเชื่อมต่อกับฐานข้อมูลปฏิบัติตรรกะและคืนค่าไปยังเลเยอร์มุมมองของคุณ ผลลัพธ์ที่ได้คือหน้า HTML ที่สร้างขึ้นสร้างการแสดงผลบนเซิร์ฟเวอร์และส่งไปยังลูกค้า

เมื่อฐานข้อมูลของคุณอยู่ในเครือข่ายเดียวกันกับโปรแกรมแสดงผลหน้าคุณจะได้รับประสิทธิภาพที่ดีขึ้นเช่นกัน ลูกค้าจะต้องทำหนึ่งคำขอและรับหน้า - คุณอาจต้องทำคำขอ 10-15 DB ก่อนที่คุณจะมีข้อมูลทั้งหมดที่ผู้ใช้ต้องการ เวลาแฝงของมิลลิวินาทีในเครือข่ายของคุณจะเป็นวินาทีต่อนาทีหากลูกค้าต้องทำทั้งหมด

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

— Michael K
แหล่งที่มา

you can't write SQL in Javascript จริงๆ?! คุณเคยดูคำถามเกี่ยวกับ StackOverflow ของ Javascript หรือไม่ ฉันจะขอแตกต่างกันอย่างน่าเสียดาย ได้รับมันเป็นสิ่งที่เลวร้ายที่สุดเพียงอย่างเดียวที่คุณสามารถทำได้ในรหัสลูกค้า แต่ ...

— maple_shaft

... ฉันยังลืมเกี่ยวกับโหนด JS แต่แล้วเซิร์ฟเวอร์ JS ซึ่งเป็นสัตว์ที่แตกต่างอย่างสิ้นเชิงโดยสิ้นเชิง

— maple_shaft

เห็นได้ชัดว่าคุณสามารถ - TIL! เพียงแค่ ... ว้าวแม้ว่า พูดถึงการใช้ภาษาในทางที่ผิด!

— Michael K

2

ส่วนต่อประสาน REST เป็นวิธีที่ไคลเอ็นต์เข้าถึงข้อมูลฐานข้อมูลผ่านวัตถุ json มันไม่ได้เปิดเผยทุกอย่างและแอปพลิเคชันนี้เป็นส่วนหนึ่งของเครือข่ายองค์กรเอกชน ข้อดีอย่างหนึ่งของอินเทอร์เฟซคือความสามารถสำหรับแอปพลิเคชันอื่น ๆ ในองค์กรเพื่อใช้ประโยชน์จากบริการใด ๆ ที่พวกเขาต้องการ จากมุมมองการพัฒนาฉันสามารถปล่อยให้นักพัฒนาส่วนหน้าทำอย่างที่ต้องการใน html / js / css จากนั้นพวกเขาก็สามารถ ping off RESTful interface ที่ออกแบบโดยนักพัฒนาจาวา อย่างไรก็ตามเราส่วนใหญ่มีชุดทักษะแบบผสมผสานและการแบ่งนั้นอาจไม่จำเป็น

— user1303881

3

-1: @MichaelK: คุณกำลังคุยกับชายฟางที่คุณจินตนาการไว้ แต่ไม่มีอะไรเกี่ยวข้องกับชีวิตจริง RESTful ใช้ HTTP ไม่มีใครต้องการเขียน SQL ใน JS นั่นคือสิ่งที่อินเตอร์เฟส RESTful ใช้ RESTful ยังไม่ได้หมายความว่ามีการแมปแบบ 1 ต่อ 1 กับการสืบค้น DB คำตอบของคุณอาจใช้ได้ในปี 1990 แต่เราอยู่ในปี 2012 ในขณะนี้

— vartec

0

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

สำหรับเดสก์ท็อปไคลเอนต์คุณอาจพิจารณาส่ง js + json เพื่อเรนเดอร์เพจบนไคลเอนต์ทำให้สามารถอัพเดตได้แบบไดนามิก ฯลฯ

— 9000
แหล่งที่มา

ในทางปฏิบัติอย่างไรก็ตามสิ่งที่ตรงกันข้ามมักเกิดขึ้นจริง ในความเป็นจริงแล้วโปรเจ็กต์ jQuery Mobile นั้นอิงตามแนวคิดของการเรนเดอร์ฝั่งไคลเอ็นต์

— แหลม

@ Pointy: ใช่สิ่งนี้อาจเป็นวิธีอื่น หนึ่งควรทดสอบวิธีการทำงานของหน้าเฉพาะในลูกค้าโดยเฉพาะ การระบุลิงก์ไปยังทางเลือกอื่น (เช่นลิงก์ 'มือถือ' และ 'เดสก์ท็อป') อาจเป็นประโยชน์สำหรับผู้ใช้เช่นกัน

— 9000

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

— Michael K

@Pointy โครงการ jQuery Mobile นั้นเป็นโค้ดที่น่ากลัวมากซึ่งไม่ควรใช้ ความนิยม! == value

— Raynos

@Raynos เราใช้ Jquery Mobile กับความสำเร็จที่ดีเช่นกัน คุณรู้อะไรบางอย่างที่เราทำไม่ได้? ;)

— Michael K

0

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

— ไวแอตต์บาร์เน็ตต์
แหล่งที่มา

ข้อดีคือแม้ว่าแอพพลิเคชั่นนี้ไม่จำเป็นต้องใช้ SEO เพราะเป็นส่วนตัวฉันยังพัฒนาแอพส่วนบุคคลบางอย่างและนั่นเป็นข้อพิจารณาในเวทีนั้น

— user1303881

Googlebot ตีความ JS / AJAX ค่อนข้างนาน: searchenginewatch.com/article/2122137/ …

— vartec

@vartec: ฉันคิดว่าประโยคสำคัญในบทความนั้นคือ "ตอนนี้สามารถอ่านและทำความเข้าใจความคิดเห็นแบบไดนามิกที่นำมาใช้ผ่าน AJAX และ JavaScript" ฉันสงสัยว่ามันครอบคลุม disqus และ facebook แต่ไม่ใช่การตั้งค่า ajax ที่คุณกำหนดเอง

— ไวแอตต์บาร์เน็ตต์