ข้อดี / ข้อเสียระหว่างการเน้นการประมวลผลฝั่งไคลเอ็นต์หรือฝั่งเซิร์ฟเวอร์

เหตุใดฉันจึงต้องการเขียนเว็บแอปที่มีการประมวลผลฝั่งเซิร์ฟเวอร์จำนวนมาก

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

ฉันเห็นการเขียนแอปพลิเคชันบนเว็บน้อยมากนอกเหนือจากการเขียนฝั่งเซิร์ฟเวอร์และจัดการกับฝั่งไคลเอ็นต์เป็นมุมมองเท่านั้น ทำไมฉันถึงต้องการทำเช่นนี้? ข้อดีอย่างเดียวที่ฉันเห็นคือฉันสามารถเขียนเป็นภาษาใดก็ได้ที่ฉันต้องการ ( http://www.paulgraham.com/avg.html )

มีสองประเด็นที่สำคัญคือ

1. สิ่งแรกนั้นง่าย - คุณมักไม่รู้ว่ามีทรัพยากรประเภทใดในฝั่งไคลเอ็นต์ หากต้องการ 1.5GB ในการประมวลผลบางสิ่งคุณสามารถผลักสิ่งนั้นลงบนเบราว์เซอร์ไคลเอนต์ที่ไม่รู้จัก (IE, Safari, Opera, Firefox และอื่น ๆ ) บนแพลตฟอร์มไคลเอนต์ที่ไม่รู้จักหรือไม่? ลูกค้าจะชื่นชมระบบหมาของเขาเมื่อคุณเอาชนะมันได้หรือไม่?

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

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

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

ฝั่งไคลเอ็นต์กับฝั่งเซิร์ฟเวอร์

การประมวลผลด้านไคลเอนต์สอดคล้องกับมาตรฐาน REST ที่เป็นที่นิยมเช่นเดียวกับ MVC ซึ่งต่างจากวิธีการใช้เพจและ SOAP การเกิดขึ้นของแนวโน้มเหล่านี้และมุ่งเน้นไปที่ AJAX และ Html-RIA การเขียนสคริปต์ด้านไคลเอนต์กำลังได้รับความนิยมมากขึ้นเรื่อย ๆ อย่างไรก็ตามเนื่องจากความกังวลด้านความปลอดภัยและความสามารถของลูกค้าการเขียนสคริปต์ฝั่งไคลเอ็นต์จึงมีช่องทางเฉพาะและไม่ควรใช้สำหรับทุกสิ่ง

การพิจารณา:

โทรศัพท์มือถือ

หากกลุ่มเป้าหมายขนาดใหญ่ของคุณจะเป็นผู้ใช้มือถือการประมวลผลจำนวนมากควรถูกทิ้งไว้ที่เซิร์ฟเวอร์

ความสอดคล้องข้ามเบราว์เซอร์

มาตรฐานเว็บมาไกลและอาจไม่เป็นปัญหามากนัก แต่นักพัฒนาเว็บทุกคนรู้ว่า IE 6,7 และ 8 และบางครั้ง Safari สามารถทำตัวตลกในฝั่งไคลเอ็นต์ - ฟังก์ชั่นบางอย่างอาจไม่ทำงานเนื่องจาก ข้อ จำกัด ด้านความปลอดภัยและอื่น ๆ เนื่องจากมาตรฐานที่ไม่ได้ใช้ สิ่งสำคัญคือต้องทราบว่าผู้ใช้สามารถกำหนดค่าเบราว์เซอร์ให้มีข้อ จำกัด บางอย่างหรือปิดการประมวลผลฝั่งไคลเอ็นต์โดยสมบูรณ์ (ไม่มี javascript!) หากความสอดคล้องเป็นข้อกำหนดสำหรับผู้ใช้ 100% (และโดยเฉพาะอย่างยิ่งถ้าคุณกำลังทำอะไรที่นอกรีต) ฝั่งเซิร์ฟเวอร์เป็นสิ่งสำคัญที่สุด

ความปลอดภัย

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

UI / UX

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

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

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

อย่างไรก็ตามฉันเชื่อว่าตรรกะบางอย่างสามารถทำได้ในระดับลูกค้าเพื่อประสบการณ์ UI ที่ดีขึ้น

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

มีเส้นแบ่งที่นี่ ตรรกะการตรวจสอบง่าย ๆ ตกลงตรรกะธุรกิจหลักไม่ตกลง

1. ก่อนอื่นคุณต้องเข้าใจสถาปัตยกรรมของเว็บแอปพลิเคชั่นส่วนใหญ่ถ้าไม่ใช่ทั้งหมดนั้นเป็นแบบ 3 ระดับ:

   a) ลูกค้า / การนำเสนอ - HTML และ Javascript อาจมี ActiveX / Flash / Java Applets / Silverlight ฉันจะออกไปที่ขาและเพิ่มแอปพลิเคชั่นมือถือที่สื่อสารกับเซิร์ฟเวอร์แบ็กเอนด์ โดยทั่วไปบทบาทของเลเยอร์นี้คือการจัดให้มีอินเทอร์เฟซสำหรับผู้ใช้ของระบบเพื่อโต้ตอบกับมัน

   b) ตรรกะทางธุรกิจ - PHP / RoR / Java ที่ซึ่งข้อมูลจากไคลเอ็นต์ถูกรวบรวมประมวลผลและจัดเก็บและที่ซึ่งคำขอของลูกค้าสำหรับข้อมูลถูกประมวลผลและส่งกลับไปยังลูกค้า

   c) Backend Data Store - จัดเก็บข้อมูลถาวรสำหรับข้อมูลระบบ

2. ดังนั้นคุณจะทำการตรวจสอบในทุกชั้น ทำไม?

   a) ฝั่งไคลเอ็นต์ - ตรวจสอบให้แน่ใจว่าผู้ใช้ป้อนข้อมูลที่ถูกต้องฟิลด์ที่จำเป็น ฯลฯ

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

   c) Backend Data Store - ข้อ จำกัด ช่วยให้มั่นใจได้ว่าข้อมูลมีรูปแบบที่ดีสำหรับการจัดเก็บและการดึงข้อมูลในภายหลัง

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

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

เมื่อคุณสร้างพฤติกรรมของคุณอย่างสมบูรณ์ในฝั่งไคลเอ็นต์ (พูดกับ Javascript) SEO อาจกลายเป็นปัญหาได้

Websolutions ที่เก็บไว้ที่ฝั่งเซิร์ฟเวอร์จะสามารถเก็บเนื้อหาที่โพสต์ไว้ใน URL ที่ระบุได้ง่ายขึ้น (โดยปกติคือ RESTful) ในลักษณะที่เครื่องมือค้นหาสามารถมองเห็นได้

นอกจากนี้ยังหมายถึงผู้เข้าชมสามารถคั่นหน้าเฉพาะ คุณเคยลองใช้ Facebook บ้างไหม?

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

เหตุผลก็คือความมั่นคง

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

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

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

ทางออกของฉัน? ฉันทำการประมวลผลมากที่สุดเท่าที่จะทำได้ในฝั่งเซิร์ฟเวอร์และฝั่งไคลเอ็นต์เป็นเพียง wrapper ขนาดเบาที่ส่งข้อมูลไปยังเซิร์ฟเวอร์และรับข้อมูลจากเซิร์ฟเวอร์ในรูปแบบของ JSON และ HTML แฟรกเมนต์ หลีกเลี่ยง XML; ใช้ JSON แทน

ฉันไม่ได้ทำเทมเพลตฝั่งไคลเอ็นต์ ฉันแสดงเนื้อหาบนเซิร์ฟเวอร์ให้เป็นส่วนย่อยของ HTML ที่ฉันกำหนดให้โดยใช้.innerHTMLแอตทริบิวต์ให้กับองค์ประกอบตัวแทนต่างๆในฝั่งไคลเอ็นต์ สิ่งนี้ทำให้เทคโนโลยีสแต็คง่ายที่สุดเท่าที่จะเป็นไปได้เพราะฉันไม่ต้องการเทมเพลตเอ็นจิ้นสองอัน (Java one และ JavaScript หนึ่ง)

ข้อเสียเปรียบคือความล่าช้าของความเร็วที่เห็นได้ชัด ครึ่งวินาทีของความหน่วงแฝงไม่ใช่เรื่องผิดปกติระหว่างทวีป

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

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