node.js เหมาะสมกับการประมวลผลเบื้องหลังหรือไม่?

ฉันเรียนรู้อย่างช้า ๆnode.jsและมีโครงการเล็ก ๆ ที่ฉันต้องการเริ่ม โครงการจะมีกระบวนการพื้นหลังจำนวนมาก (การดาวน์โหลดข้อมูลจากไซต์ภายนอกการแยกไฟล์ CSV และอื่น ๆ )

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

แต่อย่างที่ฉันบอกดูเหมือนว่ามันน่าดึงดูดใจที่จะใช้ภาษาใดภาษาหนึ่งในทุกที่และ JS ดูเหมือนจะเหมาะสมกับบิล

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

ความเห็นชื่นชม

ขอบคุณ

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

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

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

//event CBs are more DOM-style than Node style and this isn't built-in Node file I/O
//keeping it simple and quick since I'll just get Node stuff wrong from memory
file.get('someFile.txt', function(e){
    e.fileObj.find('some snippet', function(e){
        someFinalCallBackHandler( e.snippetLocations );
    } );
} );

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

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

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

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

แต่เพื่อตอบคำถามหลักของคุณอย่างชัดเจน / ชัดถ้อยชัดคำ: มันดีกับกระบวนการเบื้องหลังหรือไม่

ใช่โหนดเป็นพื้นหลังของกระบวนการที่มีวิธีการขับรถแอพผ่านกิจกรรมและการโทรกลับ

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

Node.js เก่งที่ IO คุณไม่น่าจะค้นพบหนึ่งวันว่ากระบวนการของคุณติดขัดเนื่องจากเธรดส่วนใหญ่ของคุณบล็อกในการโทร SQL

อย่างไรก็ตาม node.js ไม่ดีจริง ๆในการทำงานของขอบเขตที่คำนวณได้ เมื่อฉันได้ยิน "จำนวนมากของ IO" ฉันคิดว่า "ใช่! ไปที่โหนด!" แต่เมื่อฉันได้ยิน "การแยก" ฉันลังเลเล็กน้อย ฉันไม่แน่ใจว่านี่เป็นเหตุผลใดก็ตามที่นอกเหนือจากคนที่ไม่ได้เป็นโหนดแบบมัลติเธรดอย่างเหมาะสม แต่จนถึงตอนนี้งานที่คำนวณขอบเขตของผลิตภัณฑ์ทั้งหมดของฉันเกิดขึ้นนอกโหนด

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

นอกจากนี้โปรดทราบว่าโหนดอาจลดความสามารถขององค์กรลงเล็กน้อย ตัวอย่างเช่นไลบรารีการบันทึกของมันไม่ได้เปรียบเทียบกับ Java ในปัจจุบันยังไม่มีกรอบการบันทึกที่ดีที่แม้แต่สนับสนุนและ MDC ซึ่งในทางปฏิบัติหมายความว่าคุณต้องทำอะไรvar logPrefix = userId + ": "มากมาย

ฉันยังไม่เคยเรียกใช้ repo ส่วนตัวของ npm คุณอาจต้องใช้หนึ่งในนั้นขึ้นอยู่กับว่ารหัสของคุณเป็นกรรมสิทธิ์หรือไม่

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

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

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

สำหรับ CSV คุณสามารถใช้node-csvซึ่งค่อนข้างดีในการสร้างฐานสำหรับการไพพ์เร็กคอร์ดไปยังสตรีมตัวประมวลผล

สำหรับ large-ish XML ที่คุณต้องการทำบันทึกครั้งละครั้งฉันจะดูnode-halfstreamxmlซึ่งอ่านผ่านสตรีม XML ของคุณโดยใช้ตัวประมวลผล SAX และเพิ่มเหตุการณ์สำหรับแต่ละโหนด ฉันจะสรุปให้เป็นการอ่าน / เขียนสตรีมเพื่อให้คุณสามารถยกระดับการแข่งขันที่คุณต้องการ ตัวแยกวิเคราะห์วัตถุ xml จำนวนมากในโหนดจะพยายามอ่าน / แยกวิเคราะห์ xml ทั้งหมดในครั้งเดียวและพูดได้ 100mb ของ xml ที่มีขนาดใหญ่มาก ... โดยที่ halfstreamxml จะอ่านเป็นกระแสข้อมูล

หมายเหตุ: มีโปรเซสเซอร์อื่น ๆ เช่นxml-streamซึ่งจะใช้ expat (C library) ภายใต้ซึ่งสามารถให้ประสิทธิภาพที่มากกว่า แต่พกพาได้น้อยลงโดยไม่ต้องสร้างสภาพแวดล้อม

โดยทั่วไปแล้วมันเป็นความสุขที่แท้จริงที่จะใช้ ...