การกลับมาของลูกค้าคอมพิวเตอร์เซิร์ฟเวอร์?

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

แต่เมื่อเร็ว ๆ นี้การพัฒนาของ HTML5, CSS และโดยเฉพาะอย่างยิ่ง JavaScript คือนักพัฒนาชั้นนำที่จะนำสติปัญญาที่แท้จริงและการประมวลผลที่แท้จริงในหน้าเว็บของตัวเอง โดยเฉพาะอย่างยิ่งเราได้เห็นการเพิ่มขึ้นของเฟรมเวิร์กที่ใช้ JavaScript ฝั่งไคลเอ็นต์ซึ่งทำให้การสร้างส่วนหน้าอัจฉริยะที่ทำงานได้ง่ายขึ้นภายในเว็บเบราว์เซอร์ที่ทันสมัย เบราว์เซอร์ที่เกี่ยวข้องนั้นโดยทั่วไปจะใช้เครื่องยนต์ Webkit รวมถึง Chrome และ Safari แต่แอพส่วนใหญ่ดูเหมือนจะทำงานได้ดีใน Firefox และ Internet Explorer เวอร์ชันปัจจุบันเช่นกัน คุณท้ายด้วยเว็บเพจที่ซับซ้อนมากขึ้นที่เปลี่ยนแปลงแบบไดนามิกดึงข้อมูลจากเซิร์ฟเวอร์ตามต้องการ

โดยเฉพาะกรอบ MVC สามกรอบที่ดูเหมือนจะได้รับความสนใจมากที่สุด: Backbone.js, Ember.js และ Angular.js (MVC ย่อมาจาก model-view-controller - โดยพื้นฐานแล้วมันคือสถาปัตยกรรมที่อยู่เบื้องหลังการประมวลผลเว็บไคลเอ็นต์ "js" หมายถึง JavaScript) โดยพื้นฐานแล้วนี่เป็นวิธีที่ได้รับความนิยมอย่างมากใน AJAX (Asynchronous JavaScript และ XML) เป็นเช่นนั้น แต่การเป็นผู้ใหญ่มากขึ้นและเกือบเป็นมาตรฐาน แนวคิดคือทำให้สถานะและความฉลาดในเบราว์เซอร์มีมากขึ้นจากนั้นให้เบราว์เซอร์เชื่อมต่อกับ REST API บนฝั่งเซิร์ฟเวอร์

Backbone อาจเป็นพื้นฐานที่สุดและน้อยที่สุดของเฟรมเวิร์กเหล่านี้ มันถูกใช้ในขอบเขตต่าง ๆ โดยเว็บไซต์ยอดนิยมมากมาย Ember เติบโตจากกรอบการทำงานที่เรียกว่า Sproutcore ที่ Apple สำรองไว้และเป็นกรอบการทำงานที่ครอบคลุมมากขึ้นที่ออกแบบมาเพื่อให้คุณสามารถใช้งานแอพพลิเคชั่นสไตล์เดสก์ท็อป มักใช้กับ Bootstrap ซึ่งเป็นชุดเทมเพลตสำหรับ HTML และ CSS ที่สร้างโดยพนักงาน Twitter แองกูลาร์เป็นทางเลือกของ Google ที่ดูเหมือนจะอยู่ที่ไหนสักแห่งระหว่างกัน - บางคนคิดว่ามันมีความยืดหยุ่นมากกว่าหรืออย่างน้อยก็มีความเห็นน้อยกว่า Ember แต่มีความครอบคลุมมากกว่า Backbone (หมายเหตุ Google กำลังผลักดันให้นักพัฒนาใช้ Angular เพื่อปรับปรุงคุณภาพการเข้ารหัส แต่ภายในใช้ชุดเฟรมเวิร์กที่แตกต่างและเป็นกรรมสิทธิ์จริง ๆ ) แม้กระทั่ง Microsoft ได้เพิ่ม hooks ลงใน Visual Studio สำหรับเฟรมเวิร์กเหล่านี้

นี่คือเว็บมีทางเลือกมากมาย สิ่งที่น่าสนใจอีกอย่างหนึ่งที่ฉันได้ยินเมื่อเร็ว ๆ นี้คือ Meteor ออกแบบมาเพื่อทำงานกับ JavaScript ทั้งในฝั่งไคลเอ็นต์และเซิร์ฟเวอร์ แต่ตอนนี้ยังเร็วมากและฉันยังไม่รู้ผู้ใช้จริง ๆ ในขณะเดียวกันนักพัฒนาจำนวนมากกำลังเล่นกับ Node.js ซึ่งมักจะใช้สำหรับการใช้งาน JavaScript ฝั่งเซิร์ฟเวอร์

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

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

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

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

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