ทำไมฉันถึงต้องใช้ Node.js? บทช่วยสอนเป็นกรณีๆ ไป

บทนำ

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

ก่อนเจาะลึกโซลูชัน Node.js คุณอาจต้องการอ่านประโยชน์ของการใช้ JavaScript ในสแต็กที่รวมภาษาและรูปแบบข้อมูล (JSON) ไว้เป็นหนึ่งเดียว ซึ่งช่วยให้คุณใช้ทรัพยากรของนักพัฒนาซ้ำได้อย่างเหมาะสมที่สุด เนื่องจากสิ่งนี้มีประโยชน์ของ JavaScript มากกว่า Node.js โดยเฉพาะ เราจึงจะไม่พูดถึงเรื่องนี้มากนัก แต่มันเป็นข้อได้เปรียบหลักในการรวม Node ไว้ในสแต็กของคุณ

ตามที่ Wikipedia ระบุไว้: “Node.js เป็นการคอมไพล์แบบแพ็คเกจของเอ็นจิ้น V8 JavaScript ของ Google, เลเยอร์ที่เป็นนามธรรมของแพลตฟอร์ม libuv และไลบรารีหลัก ซึ่งส่วนใหญ่เขียนด้วย JavaScript” นอกจากนั้น ยังเป็นที่น่าสังเกตว่า Ryan Dahl ผู้สร้าง Node.js มีเป้าหมายที่จะสร้าง เว็บไซต์แบบเรียลไทม์ที่มีความสามารถแบบพุ ช “ได้รับแรงบันดาลใจจากแอปพลิเคชันอย่าง Gmail” ใน Node.js เขาให้เครื่องมือแก่นักพัฒนาซอฟต์แวร์สำหรับการทำงานในกระบวนทัศน์ I/O ที่ขับเคลื่อนด้วยเหตุการณ์แบบไม่มีการบล็อก

ในหนึ่งประโยค: Node.js โดดเด่นในเว็บแอปพลิเคชันแบบเรียลไทม์ที่ใช้เทคโนโลยีพุชผ่านซ็อกเก็ตเว็บ ปฏิวัติอะไรขนาดนั้น? หลังจากกว่า 20 ปีของเว็บไร้สัญชาติที่ใช้กระบวนทัศน์การตอบกลับคำขอไร้สัญชาติ ในที่สุดเราก็มีเว็บแอปพลิเคชันที่มีการเชื่อมต่อแบบสองทางแบบเรียลไทม์ ซึ่งทั้งไคลเอ็นต์และเซิร์ฟเวอร์สามารถเริ่มต้นการสื่อสาร ทำให้พวกเขาแลกเปลี่ยนข้อมูลได้อย่างอิสระ . สิ่งนี้ตรงกันข้ามอย่างสิ้นเชิงกับกระบวนทัศน์การตอบสนองทางเว็บทั่วไป ซึ่งไคลเอนต์เริ่มต้นการสื่อสารเสมอ นอกจากนี้ ทั้งหมดนี้อิงตาม open web stack (HTML, CSS และ JS) ที่ทำงานบนพอร์ตมาตรฐาน 80

อาจมีคนโต้แย้งว่าเรามีสิ่งนี้มาหลายปีแล้วในรูปแบบของ Flash และ Java Applets—แต่ในความเป็นจริง สิ่งเหล่านั้นเป็นเพียงสภาพแวดล้อมแบบแซนด์บ็อกซ์ที่ใช้เว็บเป็นโปรโตคอลการขนส่งที่จะส่งไปยังไคลเอนต์ นอกจากนี้ ยังทำงานโดยแยกส่วนและมักดำเนินการผ่านพอร์ตที่ไม่ได้มาตรฐาน ซึ่งอาจต้องมีการอนุญาตพิเศษและอื่นๆ

ด้วยข้อดีทั้งหมด ขณะนี้ Node.js มีบทบาทสำคัญในกลุ่มเทคโนโลยีของบริษัทชั้นนำหลายแห่งที่พึ่งพาผลประโยชน์ที่เป็นเอกลักษณ์ Node.js Foundation ได้รวบรวมความคิดที่ดีที่สุดว่าทำไมองค์กรต่างๆ ควรพิจารณา Node.js ในการนำเสนอสั้นๆ ที่สามารถพบได้ในหน้ากรณีศึกษาของ Node.js Foundation

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

มันทำงานอย่างไร?

แนวคิดหลักของ Node.js: ใช้ I/O ที่ขับเคลื่อนโดยเหตุการณ์แบบไม่ปิดกั้น เพื่อให้ยังคงน้ำหนักเบาและมีประสิทธิภาพเมื่อเผชิญกับแอปพลิเคชันแบบเรียลไทม์ที่เน้นข้อมูลมากซึ่งทำงานบนอุปกรณ์แบบกระจาย

นั่นเป็นคำหนึ่ง

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

มันทำงานอย่างไรภายใต้ประทุนนั้นค่อนข้างน่าสนใจ เมื่อเทียบกับเทคนิคการให้บริการเว็บแบบเดิมๆ ที่การเชื่อมต่อ (คำขอ) แต่ละครั้งจะสร้างเธรดใหม่ ใช้ RAM ของระบบและในที่สุดก็มีจำนวน RAM สูงสุดที่พร้อมใช้งาน Node.js ทำงานบนเธรดเดียวโดยใช้ I/ ที่ไม่บล็อก การโทรแบบ O ทำให้สามารถรองรับการเชื่อมต่อพร้อมกันหลายหมื่นรายการในลูปเหตุการณ์

การคำนวณอย่างรวดเร็ว: สมมติว่าแต่ละเธรดอาจมีหน่วยความจำ 2 MB ควบคู่ไปกับมัน ทำงานบนระบบที่มี RAM 8 GB ทำให้เราเชื่อมต่อพร้อมกันสูงสุด 4,000 ทางทฤษฎี (การคำนวณนำมาจากบทความของ Michael Abernethy เรื่อง “โหนดคืออะไร” .js?” ซึ่งเผยแพร่บน IBM developerWorks ในปี 2011 น่าเสียดายที่บทความนี้ไม่มีให้บริการอีกต่อไป) บวกกับค่าใช้จ่ายในการสลับบริบทระหว่างเธรดต่างๆ นั่นคือสถานการณ์ที่คุณมักจะเผชิญในเทคนิคการให้บริการเว็บแบบดั้งเดิม โดยการหลีกเลี่ยงทั้งหมดนั้น Node.js บรรลุระดับความสามารถในการขยายของการเชื่อมต่อพร้อมกันมากกว่า 1 ล้านครั้ง และการเชื่อมต่อซ็อกเก็ตเว็บพร้อมกันมากกว่า 600k รายการ

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

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

NPM: ตัวจัดการแพ็คเกจโหนด

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

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

โมดูล npm ที่มีประโยชน์ที่สุดบางส่วนในปัจจุบัน ได้แก่:

• express - Express.js—หรือเพียงแค่ Express—เฟรมเวิร์กการพัฒนาเว็บที่ได้รับแรงบันดาลใจจาก Sinatra สำหรับ Node.js และมาตรฐานตามความเป็นจริงสำหรับแอปพลิเคชัน Node.js ส่วนใหญ่ที่มีอยู่ในปัจจุบัน
• hapi - เฟรมเวิร์กที่เน้นการกำหนดค่าแบบโมดูลาร์และใช้งานง่ายสำหรับการสร้างแอปพลิเคชันเว็บและบริการ
• เชื่อมต่อ - เชื่อมต่อคือเฟรมเวิร์กเซิร์ฟเวอร์ HTTP ที่ขยายได้สำหรับ Node.js โดยให้คอลเลกชันของ "ปลั๊กอิน" ประสิทธิภาพสูงที่เรียกว่ามิดเดิลแวร์ ทำหน้าที่เป็นรากฐานสำหรับ Express
• socket.io และ sockjs - ส่วนประกอบฝั่งเซิร์ฟเวอร์ของส่วนประกอบ websockets ทั่วไปสองส่วนประกอบที่มีอยู่ในปัจจุบัน
• pug (เดิมชื่อ Jade ) - หนึ่งในเครื่องมือสร้างเทมเพลตยอดนิยมที่ได้รับแรงบันดาลใจจาก HAML ซึ่งเป็นค่าเริ่มต้นใน Express.js
• mongodb และ mongojs - ตัวห่อ หุ้ม MongoDB เพื่อจัดเตรียม API สำหรับฐานข้อมูลอ็อบเจ็กต์ MongoDB ใน Node.js
• redis - ไลบรารีไคลเอนต์ Redis
• lodash (ขีดล่าง, lazy.js) - แถบยูทิลิตี้ JavaScript ขีดเส้นใต้เริ่มต้นเกม แต่ถูกโค่นล้มโดยหนึ่งในสองคู่หูของมัน สาเหตุหลักมาจากประสิทธิภาพที่ดีขึ้นและการใช้งานแบบแยกส่วน
• ตลอดไป - อาจเป็นยูทิลิตี้ทั่วไปที่สุดสำหรับทำให้แน่ใจว่าสคริปต์โหนดที่กำหนดทำงานอย่างต่อเนื่อง ช่วยให้กระบวนการ Node.js ของคุณทำงานจริงเมื่อเผชิญกับความล้มเหลวที่ไม่คาดคิด
• bluebird - การใช้งาน Promises/A+ ที่มีคุณสมบัติครบถ้วนพร้อมประสิทธิภาพที่ดีเยี่ยม
• ช่วงเวลา - ไลบรารีวันที่ของ JavaScript สำหรับการแยกวิเคราะห์ ตรวจสอบ จัดการ และจัดรูปแบบวันที่

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

ตัวอย่างตำแหน่งที่ควรใช้ Node.js

แชท

การแชทเป็นแอปพลิเคชันแบบเรียลไทม์ที่มีผู้ใช้หลายคน ตั้งแต่ IRC (ในสมัยก่อน) ผ่านโปรโตคอลที่เป็นกรรมสิทธิ์และเปิดจำนวนมากที่ทำงานบนพอร์ตที่ไม่ได้มาตรฐาน ไปจนถึงความสามารถในการปรับใช้ทุกอย่างใน Node.js ที่มีเว็บซ็อกเก็ตที่ทำงานบนพอร์ตมาตรฐาน 80

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

ลองอธิบายวิธีการทำงาน

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

ทางฝั่งเซิร์ฟเวอร์ เรามีแอปพลิเคชัน Express.js แบบง่ายซึ่งใช้งานสองสิ่ง:

1. ตัวจัดการ GET / คำขอซึ่งให้บริการหน้าเว็บที่มีทั้งกระดานข้อความและปุ่ม 'ส่ง' เพื่อเริ่มต้นการป้อนข้อความใหม่ และ
2. เซิร์ฟเวอร์ websockets ที่รับฟังข้อความใหม่ที่ส่งโดยไคลเอนต์ websocket

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

เมื่อลูกค้ารายหนึ่งโพสต์ข้อความ นี่คือสิ่งที่จะเกิดขึ้น:

1. เบราว์เซอร์จับการคลิกปุ่ม 'ส่ง' ผ่านตัวจัดการ JavaScript เลือกค่าจากฟิลด์อินพุต (เช่น ข้อความ) และส่งข้อความ websocket โดยใช้ไคลเอ็นต์ websocket ที่เชื่อมต่อกับเซิร์ฟเวอร์ของเรา (เริ่มต้นในการเริ่มต้นหน้าเว็บ)
2. องค์ประกอบฝั่งเซิร์ฟเวอร์ของการเชื่อมต่อ websocket รับข้อความและส่งต่อไปยังไคลเอนต์ที่เชื่อมต่ออื่น ๆ ทั้งหมดโดยใช้วิธีการออกอากาศ
3. ลูกค้าทั้งหมดได้รับข้อความใหม่เป็นข้อความพุชผ่านส่วนประกอบฝั่งไคลเอ็นต์ websockets ที่ทำงานภายในหน้าเว็บ จากนั้นพวกเขาจะรับเนื้อหาข้อความและอัปเดตหน้าเว็บโดยเพิ่มข้อความใหม่ต่อท้ายกระดาน

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

API ที่ด้านบนของวัตถุDB

แม้ว่า Node.js จะส่องประกายด้วยแอปพลิเคชันแบบเรียลไทม์ แต่ก็ค่อนข้างเหมาะสมสำหรับการเปิดเผยข้อมูลจากฐานข้อมูลวัตถุ (เช่น MongoDB) ข้อมูลที่จัดเก็บ JSON ช่วยให้ Node.js ทำงานได้โดยไม่มีอิมพีแดนซ์ที่ไม่ตรงกันและการแปลงข้อมูล

ตัวอย่างเช่น หากคุณใช้ Rails คุณจะต้องแปลงจาก JSON เป็นโมเดลไบนารี จากนั้นให้แสดงกลับเป็น JSON ผ่าน HTTP เมื่อ Backbone.js, Angular.js ฯลฯ ใช้งานข้อมูล หรือแม้แต่ jQuery AJAX แบบธรรมดา โทร. ด้วย Node.js คุณสามารถเปิดเผยวัตถุ JSON ของคุณด้วย REST API เพื่อให้ไคลเอ็นต์ใช้งานได้ นอกจากนี้ คุณไม่จำเป็นต้องกังวลเกี่ยวกับการแปลงระหว่าง JSON และสิ่งอื่นใดเมื่ออ่านหรือเขียนจากฐานข้อมูลของคุณ (หากคุณใช้ MongoDB) โดยสรุป คุณสามารถหลีกเลี่ยงความจำเป็นในการแปลงหลายรายการได้โดยใช้รูปแบบการจัดลำดับข้อมูลแบบเดียวกันในไคลเอนต์ เซิร์ฟเวอร์ และฐานข้อมูล

อินพุตที่อยู่ในคิว

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

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

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

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

การสตรีมข้อมูล

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

พร็อกซี่

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

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

แม้ว่าจะมีพร็อกซีเซิร์ฟเวอร์เฉพาะอยู่ แต่การใช้โหนดแทนอาจเป็นประโยชน์หากโครงสร้างพื้นฐานพร็อกซีของคุณไม่มีอยู่จริง หรือหากคุณต้องการโซลูชันสำหรับการพัฒนาในพื้นที่ จากสิ่งนี้ ฉันหมายความว่าคุณสามารถสร้างแอปฝั่งไคลเอ็นต์ด้วยเซิร์ฟเวอร์การพัฒนา Node.js สำหรับเนื้อหาและคำขอ API พร็อกซี/การขัดจังหวะ ในขณะที่ใช้งานจริง คุณจะต้องจัดการกับการโต้ตอบดังกล่าวกับบริการพร็อกซีเฉพาะ (nginx, HAProxy เป็นต้น) .)

นายหน้า - แดชบอร์ดของผู้ซื้อขายหุ้น

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

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

แดชบอร์ดการตรวจสอบแอปพลิเคชัน

กรณีใช้งานทั่วไปอีกกรณีหนึ่งซึ่ง Node-with-web-sockets เข้ากันได้อย่างสมบูรณ์: ติดตามผู้เยี่ยมชมเว็บไซต์และแสดงภาพการโต้ตอบของพวกเขาในแบบเรียลไทม์

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

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

แดชบอร์ดการตรวจสอบระบบ

ตอนนี้ มาดูด้านโครงสร้างพื้นฐานของสิ่งต่างๆ กัน ตัวอย่างเช่น ลองนึกภาพผู้ให้บริการ SaaS ที่ต้องการเสนอหน้าตรวจสอบบริการแก่ผู้ใช้ เช่น หน้าสถานะของ GitHub ด้วย Node.js event-loop เราสามารถสร้างแดชบอร์ดบนเว็บที่มีประสิทธิภาพ ซึ่งจะตรวจสอบสถานะของบริการในลักษณะอะซิงโครนัสและส่งข้อมูลไปยังไคลเอนต์โดยใช้ websockets

ทั้งสถานะภายใน (ภายในบริษัท) และบริการสาธารณะสามารถรายงานสดและแบบเรียลไทม์โดยใช้เทคโนโลยีนี้ ผลักดันแนวคิดนั้นให้ไกลขึ้นอีกนิดแล้วลองนึกภาพว่า Network Operations Center (NOC) แอปพลิเคชันการตรวจสอบในผู้ให้บริการโทรคมนาคม ผู้ให้บริการคลาวด์/เครือข่าย/โฮสต์ หรือสถาบันการเงินบางแห่ง ทั้งหมดทำงานบนเว็บสแต็กแบบเปิดซึ่งสนับสนุนโดย Node.js และ websockets แทน Java และ/หรือ Java Applets

ตำแหน่งที่สามารถใช้ Node.js ได้

แอปพลิเคชันเว็บฝั่งเซิร์ฟเวอร์

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

ข้อดี:

• หากแอปพลิเคชันของคุณไม่มีการคำนวณแบบเข้มข้นของ CPU คุณสามารถสร้างใน Javascript จากบนลงล่าง แม้กระทั่งระดับฐานข้อมูลหากคุณใช้ JSON storage Object DB เช่น MongoDB สิ่งนี้ทำให้การพัฒนา (รวมถึงการจ้างงาน) ง่ายขึ้นอย่างมาก
• โปรแกรมรวบรวมข้อมูลได้รับการตอบสนอง HTML ที่แสดงผลอย่างสมบูรณ์ ซึ่งเป็นมิตรกับ SEO มากกว่าการพูดแอปพลิเคชันหน้าเดียวหรือแอป websockets ที่ทำงานบน Node.js

จุดด้อย:

• การคำนวณแบบเข้มข้นของ CPU จะบล็อกการตอบสนองของ Node.js ดังนั้นแพลตฟอร์มแบบเธรดจึงเป็นแนวทางที่ดีกว่า หรือคุณอาจลองขยายการคำนวณ [*]
• การใช้ Node.js กับฐานข้อมูลเชิงสัมพันธ์นั้นค่อนข้างลำบาก (ดูรายละเอียดเพิ่มเติมด้านล่าง) ทำตัวเองให้เป็นประโยชน์และเลือกสภาพแวดล้อมอื่น ๆ เช่น Rails, Django หรือ ASP.Net MVC หากคุณกำลังพยายามดำเนินการเชิงสัมพันธ์

ที่ที่ไม่ควรใช้ Node.js

แอปพลิเคชันเว็บฝั่งเซิร์ฟเวอร์พร้อมฐานข้อมูลเชิงสัมพันธ์เบื้องหลัง

ตัวอย่างเช่น การเปรียบเทียบ Node.js กับ Express.js กับ Ruby on Rails เคยมีการตัดสินใจที่ชัดเจนมาก่อนในการเข้าถึงฐานข้อมูลเชิงสัมพันธ์ เช่น PostgreSQL, MySQL และ Microsoft SQL Server

เครื่องมือฐานข้อมูลเชิงสัมพันธ์สำหรับ Node.js ยังอยู่ในช่วงเริ่มต้น ในอีกทางหนึ่ง Rails จะให้การตั้งค่าการเข้าถึงข้อมูลโดยอัตโนมัติทันทีพร้อมกับเครื่องมือสนับสนุนการโยกย้ายสคีมา DB และ Gems อื่น ๆ (เล่นสำนวนเจตนา) Rails และเฟรมเวิร์กเพียร์มีการใช้งานเลเยอร์การเข้าถึงข้อมูล Active Record หรือ Data Mapper ที่ครบถ้วนและได้รับการพิสูจน์แล้ว[*]

แต่สิ่งที่มีการเปลี่ยนแปลง Sequelize, TypeORM และ Bookshelf ก้าวไปไกลในการเป็นโซลูชัน ORM ที่ครบถ้วน มันอาจจะคุ้มค่าที่จะลองใช้ Join Monster หากคุณต้องการสร้าง SQL จากการสืบค้น GraphQL

การประมวลผล/การประมวลผลฝั่งเซิร์ฟเวอร์หนัก

เมื่อพูดถึงการคำนวณอย่างหนัก Node.js ไม่ใช่แพลตฟอร์มที่ดีที่สุด ไม่ คุณไม่ต้องการสร้างเซิร์ฟเวอร์การคำนวณ Fibonacci ใน Node.js โดยทั่วไป การดำเนินการที่เข้มข้นของ CPU จะยกเลิกผลประโยชน์ของปริมาณงานทั้งหมดที่ Node เสนอด้วยโมเดล I/O ที่ขับเคลื่อนด้วยเหตุการณ์และไม่บล็อก เนื่องจากคำขอขาเข้าใดๆ จะถูกบล็อกในขณะที่เธรดกำลังยุ่งอยู่กับการจำกัดจำนวนของคุณ—สมมติว่าคุณกำลังพยายาม เพื่อเรียกใช้การคำนวณของคุณในอินสแตนซ์โหนดเดียวกันกับที่คุณตอบสนองต่อคำขอ

ตามที่ระบุไว้ก่อนหน้านี้ Node.js เป็นแบบเธรดเดียวและใช้ซีพียูคอร์เดียวเท่านั้น เมื่อพูดถึงการเพิ่มการทำงานพร้อมกันบนเซิร์ฟเวอร์แบบ multi-core มีงานบางอย่างที่ทำโดยทีม Node core ในรูปแบบของโมดูลคลัสเตอร์ [ref: http://nodejs.org/api/cluster.html] คุณยังสามารถเรียกใช้อินสแตนซ์ของเซิร์ฟเวอร์ Node.js หลายตัวได้อย่างง่ายดายหลังพร็อกซีย้อนกลับผ่าน nginx

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

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

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

บทสรุป

เราได้พูดถึง Node.js จากทฤษฎีสู่การปฏิบัติ เริ่มต้นด้วยเป้าหมายและความทะเยอทะยาน และจบลงด้วยจุดที่น่าสนใจและข้อผิดพลาด เมื่อผู้คนประสบปัญหากับ Node เกือบทุกครั้งจะทำให้ การปิดกั้นเป็นรากเหง้าของความชั่วร้ายทั้งหมด —99% ของการใช้โหนดในทางที่ผิดนั้นเป็นผลโดยตรง

ข้อควรจำ: Node.js ไม่เคยสร้างมาเพื่อแก้ปัญหาการปรับขนาดการคำนวณ สร้างขึ้นเพื่อแก้ปัญหาการปรับสเกล I/O ซึ่งทำได้ดีมาก

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