จะตัดสินใจอย่างไรเมื่อใช้ Node.js


2195

ฉันใหม่ชนิดของสิ่งนี้ แต่เมื่อเร็ว ๆ นี้ผมได้รับฟังมากเกี่ยวกับวิธีการที่ดีNode.jsเป็น เมื่อพิจารณาว่าฉันรักการทำงานกับ jQuery และ JavaScript โดยทั่วไปฉันก็อดไม่ได้ที่จะสงสัยว่าจะตัดสินใจใช้ Node.js อย่างไร แอปพลิเคชันทางเว็บที่ฉันมีอยู่ในใจคือสิ่งที่คล้ายกับBitly - นำเนื้อหาบางส่วนมาเก็บไว้

จากการบ้านทั้งหมดที่ฉันทำในสองสามวันที่ผ่านมาฉันได้รับข้อมูลต่อไปนี้ Node.js

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

บางแหล่งที่ฉันเจอคือ:

เมื่อพิจารณาแล้วว่า Node.js สามารถใช้งานได้เกือบหมดในอินสแตนซ์EC2 ของ Amazonฉันพยายามทำความเข้าใจว่าปัญหาประเภทใดที่ Node.js ต้องการเมื่อเทียบกับกษัตริย์ผู้ยิ่งใหญ่อื่น ๆ เช่นPHP , PythonและRuby . ฉันเข้าใจว่ามันขึ้นอยู่กับความเชี่ยวชาญที่มีในภาษา แต่คำถามของฉันอยู่ในหมวดหมู่ทั่วไปของ: เมื่อใดที่จะใช้กรอบงานเฉพาะและประเภทของปัญหาที่เหมาะสมสำหรับ?


4
คำถามนี้กำลังถูกกล่าวถึงใน meta ( meta.stackoverflow.com/q/332386/497418 )
zzzzBov

คำตอบ:


1355

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

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

เป็นมูลค่าการกล่าวขวัญว่าทั้ง Ruby และ Python มีเครื่องมือในการทำสิ่งนี้ ( eventmachineและtwistedตามลำดับ) แต่ Node.js นั้นทำได้ดีเป็นพิเศษและจากจุดเริ่มต้น JavaScript อยู่ในตำแหน่งที่ดีเป็นอย่างยิ่งสำหรับรูปแบบการทำงานพร้อมกันที่ใช้การติดต่อกลับและมันยอดเยี่ยมที่นี่ นอกจากนี้ความสามารถในการทำให้เป็นอนุกรมและ deserialize กับ JSON ดั้งเดิมทั้งไคลเอนต์และเซิร์ฟเวอร์สวยดี

ฉันหวังว่าจะอ่านคำตอบอื่น ๆ ที่นี่นี่เป็นคำถามที่ยอดเยี่ยม

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

ต่อไปนี้เป็นบทความเกี่ยวกับพีระมิดและระยะยาวการเลือกตั้งซึ่งจะออกมาเป็นเรื่องง่ายมากที่จะตั้งขึ้นด้วยความช่วยเหลือเล็ก ๆ น้อย ๆ จาก gevent: TicTacToe และลอง Polling กับพีระมิด


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

1
ขอบคุณสำหรับสิ่งนี้ ... Great Q and A ;-) ฉันยังคิดถึงมันในแง่ของการเรียนรู้เทคโนโลยีที่ยอดเยี่ยมสำหรับการพัฒนาทั้งด้านหน้าและด้านหลังมากกว่าเทคโนโลยีที่แตกต่างกันสองสามตัว)
Stokedout

12
ทำไมต้องใช้การสำรวจความคิดเห็นนาน? เกิดอะไรขึ้นกับอนาคตและซ็อกเก็ต ?
hitautodestruct

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

409

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

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

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

นอกจากนี้ไรอันดาห์ลกล่าวในการพูดคุยว่าฉันเคยเข้าร่วมว่าเกณฑ์มาตรฐานของ Node.js ใกล้เคียงกับ Nginx สำหรับคำขอ HTTP ปกติทั่วไป ดังนั้นถ้าเราสร้างด้วย Node.js เราสามารถให้บริการทรัพยากรปกติของเราได้อย่างมีประสิทธิภาพและเมื่อเราต้องการสิ่งที่ขับเคลื่อนด้วยเหตุการณ์ก็พร้อมที่จะจัดการมัน

นอกจากนี้ยังมี JavaScript ทั้งหมดตลอดเวลา Lingua Franca ในกองทั้งหมด


17
เพียงการสังเกตจากบางคนสลับไปมาระหว่าง. Net และ Node ภาษาที่แตกต่างกันสำหรับพื้นที่ต่าง ๆ ของระบบช่วยได้อย่างมากเมื่อการสลับบริบท เมื่อฉันดูจาวาสคริปต์ฉันทำงานในไคลเอนต์ C # หมายถึงแอปเซิร์ฟเวอร์ SQL = ฐานข้อมูล ทำงานใน Javascript มาตลอดฉันพบว่าตัวเองสับสนเลเยอร์หรือใช้เวลานานกว่าในการสลับบริบท นี่น่าจะเป็นสิ่งประดิษฐ์ของการทำงานกับ. NET stack ทุกวันและ Noding ในเวลากลางคืน แต่มันสร้างความแตกต่าง
Michael Blackburn

9
ที่น่าสนใจคือการฝึกฝนภาษาถิ่นข้ามวัฒนธรรมเมื่อเปลี่ยนระหว่างวัฒนธรรมกระแสหลักและวัฒนธรรมพื้นเมืองเรียกว่า "การสลับรหัส"
Michael Blackburn

1
เมื่อวันก่อนฉันกำลังคิดว่าฉันจะกำหนดสีต่าง ๆ ให้กับ.jsไฟล์ต่าง ๆ ของฉันได้อย่างไร สีเขียวสำหรับฝั่งไคลเอ็นต์, สีน้ำเงินสำหรับฝั่งเซิร์ฟเวอร์ ฉันได้รับ "หลงทาง" อยู่เสมอ
AJB

209

เหตุผลในการใช้ NodeJS:

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

  • เดียวเกลียวระบบเหตุการณ์ที่ขับเคลื่อนเป็นไปอย่างรวดเร็วแม้ในขณะที่การจัดการจำนวนมากของการร้องขอในครั้งเดียวและยังง่ายเมื่อเทียบกับแบบดั้งเดิมแบบมัลติเธรดJavaหรือ ROR กรอบ

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

  • มันได้กลายเป็นสภาพแวดล้อมมาตรฐาน defacto ที่ใช้เครื่องมือที่เกี่ยวข้องกับจาวาสคริปต์และเครื่องมือที่เกี่ยวข้องกับเว็บอื่น ๆรวมถึงนักวิ่งงาน, minifiers, beautifiers, linters, preprocessors, bundlers และโปรเซสเซอร์วิเคราะห์

  • ดูเหมือนว่าค่อนข้างเหมาะสำหรับการสร้างต้นแบบเปรียวพัฒนาและย้ำผลิตภัณฑ์อย่างรวดเร็ว

เหตุผลที่ไม่ใช้ NodeJS:

  • มันรัน Javascript ซึ่งไม่มีการตรวจสอบประเภทเวลาคอมไพล์ สำหรับขนาดใหญ่ซับซ้อนความปลอดภัยที่สำคัญระบบหรือโครงการรวมถึงการทำงานร่วมกันระหว่างองค์กรที่แตกต่างกันภาษาซึ่งจะกระตุ้นให้เกิดการเชื่อมต่อสัญญาและให้ตรวจสอบประเภทคงที่อาจจะช่วยคุณแก้จุดบกพร่องบางเวลา (และระเบิด ) ในระยะยาว (แม้ว่า JVM ติดอยู่nullดังนั้นโปรดใช้ Haskell สำหรับเครื่องปฏิกรณ์นิวเคลียร์ของคุณ)

  • ยิ่งไปกว่านั้นแพ็คเกจต่าง ๆ ใน NPM นั้นค่อนข้างดิบและยังอยู่ในระหว่างการพัฒนาอย่างรวดเร็ว บางไลบรารีสำหรับเฟรมเวิร์กรุ่นเก่าต้องผ่านการทดสอบและการแก้ไขข้อผิดพลาดมานับทศวรรษและมีความเสถียรมากในตอนนี้ Npmjs.org ไม่มีกลไกในการจัดอันดับแพ็คเกจซึ่งนำไปสู่การแพร่กระจายของแพคเกจที่ทำสิ่งเดียวกันมากขึ้นหรือน้อยลงซึ่งไม่ได้รับการบำรุงรักษาเป็นเปอร์เซ็นต์จำนวนมากอีกต่อไป

  • นรกโทรกลับซ้อนกัน (แน่นอนว่ามีทางออกที่แตกต่างกันถึง 20 ข้อสำหรับเรื่องนี้ ... )

  • กลุ่มของแพคเกจที่เพิ่มขึ้นเรื่อย ๆ สามารถทำให้โครงการ NodeJS หนึ่งแตกต่างไปจากเดิมอย่างสิ้นเชิง มีความหลากหลายในการใช้งานเนื่องจากมีตัวเลือกจำนวนมาก (เช่น Express / Sails.js / Meteor / Derby ) บางครั้งสิ่งนี้สามารถทำให้ยากขึ้นสำหรับนักพัฒนาใหม่ในการเข้าสู่โครงการโหนด คมชัดด้วยRailsนักพัฒนาเข้าร่วมโครงการที่มีอยู่: เขาควรจะสามารถที่จะได้รับคุ้นเคยกับแอปสวยได้อย่างรวดเร็วเพราะทุกปพลิเคชันทางรถไฟมีการส่งเสริมให้ใช้โครงสร้างที่คล้ายกัน

  • การจัดการกับไฟล์อาจเป็นเรื่องเจ็บปวด สิ่งที่ไม่สำคัญในภาษาอื่น ๆ เช่นการอ่านบรรทัดจากไฟล์ข้อความเป็นสิ่งที่แปลกพอที่จะทำกับ Node.jsว่ามีคำถาม StackOverflow ในนั้นด้วย 80+ upvotes มีไม่มีวิธีง่ายๆในการอ่านบันทึกในเวลาจากไฟล์ CSV เป็นต้น

ฉันรัก NodeJS มันรวดเร็วและดุร้ายและสนุก แต่ฉันกังวลว่ามันมีความสนใจเพียงเล็กน้อยในการพิสูจน์ความถูกต้อง หวังว่าในที่สุดเราก็สามารถผสานสิ่งที่ดีที่สุดของทั้งสองโลก ฉันอยากรู้ว่าอะไรจะมาแทนที่โหนดในอนาคต ... :)


1
@ ไม่มีใช่ฉันคิดว่าพวกเขาสามารถแก้ไขปัญหานี้ได้ แต่คุณต้องจำกัด ตัวเองให้ใช้เฉพาะห้องสมุดที่เขียนด้วยภาษาที่ปลอดภัยเท่านั้นหรือยอมรับว่าฐานข้อมูลของคุณไม่ได้พิมพ์แบบคงที่ทั้งหมด แต่มีข้อโต้แย้งหนึ่งข้อ: เนื่องจากคุณควรเขียนแบบทดสอบที่ดีสำหรับรหัสของคุณโดยไม่คำนึงถึงภาษาดังนั้นระดับความมั่นใจของคุณควรจะเท่ากันแม้สำหรับรหัสที่พิมพ์แบบไดนามิก หากเรายอมรับข้อโต้แย้งนั้นแล้วข้อดีของการพิมพ์ที่แข็งแกร่งจะลดลงไปให้ความช่วยเหลือในการพัฒนา / การแก้จุดบกพร่องเวลา provability และการเพิ่มประสิทธิภาพ
joeytwiddle

1
@ kervin ฉันเห็นด้วยกับการวัดประสิทธิภาพที่ยอดเยี่ยม แต่ฉันก็ผิดหวังกับสิ่งที่ฉันพบทางออนไลน์ บางคนแย้งว่าประสิทธิภาพของ. NET นั้นเทียบได้กับโหนด แต่มันสำคัญมากกับสิ่งที่คุณกำลังทำอยู่ โหนดอาจทำได้ดีในการส่งข้อความเล็กน้อยที่มีการเชื่อมต่อพร้อมกันจำนวนมาก แต่ไม่ดีนักสำหรับการคำนวณทางคณิตศาสตร์อย่างหนัก การเปรียบเทียบประสิทธิภาพที่ดีจะต้องทดสอบสถานการณ์ที่หลากหลาย
joeytwiddle

2
@joeytwiddle จะไม่เหมือนกับ Typescript help Node.js เมื่อพูดถึงการจัดการโปรแกรมที่ซับซ้อนและการตรวจสอบ typecheck แบบคงที่?
CodeMonkey

2
@jotwiddle สำหรับสิ่งที่คุ้มค่าคุณสามารถใช้Stillmaintained.comเพื่อตรวจสอบว่าแพคเกจ npm ยังคงอยู่หรือไม่ (เป็นส่วนใหญ่อยู่บน GitHub) นอกจากนี้npm searchและnpm showจะแสดงวันที่ของแพคเกจรุ่นล่าสุด
Dan Pantry

3
โดยการเปรียบเทียบทางรถไฟกับโหนดคุณทำให้แพลตฟอร์มสับสนกับกรอบงาน Rails เป็นเฟรมเวิร์กสำหรับ Ruby เช่นเดียวกับ Sails และ meteor เป็นเฟรมเวิร์กสำหรับ Javascript
BonsaiOak

206

วิธีทำให้สั้น:

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

บทความที่ดีเกี่ยวกับห่วงเหตุการณ์ใน Node.js เป็นบล็อกเทคโนโลยี Mixu ของ: การทำความเข้าใจ Node.js ห่วงเหตุการณ์


127

ฉันมีตัวอย่างในโลกแห่งความจริงที่ฉันใช้ Node.js บริษัท ที่ฉันทำงานมีลูกค้ารายหนึ่งที่ต้องการมีเว็บไซต์ HTML แบบคงที่เรียบง่าย เว็บไซต์นี้มีไว้สำหรับขายสินค้าหนึ่งรายการโดยใช้PayPalและลูกค้าต้องการมีเคาน์เตอร์ซึ่งแสดงจำนวนสินค้าที่ขาย ลูกค้าคาดว่าจะมีผู้เยี่ยมชมเว็บไซต์นี้เป็นจำนวนมาก ฉันตัดสินใจสร้างตัวนับโดยใช้ Node.js และกรอบงานExpress.js

แอปพลิเคชั่น Node.js นั้นเรียบง่าย รับจำนวนสินค้าที่ขายจากRedisฐานข้อมูลเพิ่มเคาน์เตอร์เมื่อรายการขายและให้บริการค่าตัวนับให้กับผู้ใช้ผ่านทางAPI

เหตุผลบางอย่างที่ฉันเลือกใช้ Node.js ในกรณีนี้

  1. มันมีน้ำหนักเบาและรวดเร็วมาก มีการเข้าชมเว็บไซต์นี้มากกว่า 200,000 ครั้งในเวลาสามสัปดาห์และทรัพยากรเซิร์ฟเวอร์ขั้นต่ำสามารถจัดการได้ทั้งหมด
  2. เคาน์เตอร์เป็นเรื่องง่ายที่จะทำให้เป็นเวลาจริง
  3. Node.js ตั้งค่าได้ง่าย
  4. มีโมดูลมากมายให้ใช้ฟรี ตัวอย่างเช่นฉันพบโมดูล Node.js สำหรับ PayPal

ในกรณีนี้ Node.js เป็นตัวเลือกที่ยอดเยี่ยม


7
คุณโฮสต์บางอย่างเช่นนั้นได้อย่างไร คุณต้องตั้งค่า nodejs บนเซิร์ฟเวอร์ที่ใช้งานจริงหรือไม่? ใน linux
Miguel Stevens

1
มี PaaSs ไม่กี่อย่างเช่น nodejitsu และ Heroku หรือคุณสามารถตั้งค่า nodejs บนกล่อง linux เช่นจาก amazon ec2 ดู: lauradhamilton.com/…
แฮร์รี่หนุ่ม

13
200,000 การเยี่ยมชมภายใน 1,814,400 วินาที ไม่เกี่ยวข้องเลย แม้แต่ bash สามารถตอบสนองคำขอจำนวนมากบนเซิร์ฟเวอร์ที่ช้าที่สุด เซิร์ฟเวอร์เริ่มต้น VM ที่ช้าที่สุด
Tiberiu-Ionuț Stan

105

เหตุผลที่สำคัญที่สุดในการเริ่มต้นโครงการต่อไปของคุณโดยใช้ Node ...

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

คาดหวังอะไร ...

  • คุณจะรู้สึกปลอดภัยกับ Express โดยไม่ต้อง bloatware เซิร์ฟเวอร์ที่คุณไม่ต้องการ
  • วิ่งเหมือนจรวดและสเกลได้ดี
  • คุณฝันไว้ คุณติดตั้งมัน แพ็คเกจโหนด repo npmjs.orgเป็นระบบนิเวศน์ที่ใหญ่ที่สุดของห้องสมุดโอเพนซอร์สในโลก
  • สมองของคุณจะได้รับเวลาเหยเกในดินแดนของการโทรกลับซ้อนกัน ...
  • ... จนกว่าคุณจะได้เรียนรู้ที่จะทำให้คุณสัญญา
  • SequelizeและPassportคือเพื่อน API ใหม่ของคุณ
  • แก้จุดบกพร่องส่วนใหญ่ async จะได้รับรหัสอืมม ... น่าสนใจ
  • เวลาสำหรับ Noders ทั้งหมดจะโทtypescript

ใครใช้บ้าง

  • PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
  • นี่คือเหตุผลที่พวกเขาเปลี่ยนไปโหนด

18
ใช่ฉันสามารถตอบคำถามนี้ในแบบดั้งเดิม ฉันคิดว่าฉันมีคุณสมบัติที่จะทำเช่นนั้น แต่ส่วนใหญ่มีการพูดไปแล้วและฉันคิดว่าความสนุกที่เบา ๆ จะทำลายความน่าเบื่อ ฉันให้คำตอบด้านเทคนิคกับคำถามอื่นเป็นประจำ
Tony O'Hagan

1
การเรียกกลับที่ซ้อนกันสามารถหลีกเลี่ยงได้โดยใช้เครื่องกำเนิดไฟฟ้า ES6 สำหรับรหัส async
refactor

1
@CleanCrispCode: ใช่แน่นอน! ES6 ได้นำ C # สไตล์async/ awaitดังนั้นตอนนี้เราสามารถแผ่ออกทำความสะอาดมาก async รหัสโหนดที่ยังสนับสนุนแบบดั้งเดิม/try catchใน 2016/17 JS coders กำลังเปลี่ยนเป็น ES6
Tony O'Hagan

1
ครั้งนี้นับพันสิบ "คุณจะรู้สึกปลอดภัยและปลอดภัยด้วยด่วนโดยไม่ต้องทั้งหมดเซิร์ฟเวอร์ bloatware คุณไม่จำเป็น"
Simone Poggi

60

ไม่มีอะไรที่เหมือนกับ Silver Bullet ทุกอย่างมาพร้อมกับค่าใช้จ่ายที่เกี่ยวข้อง มันเหมือนกับว่าถ้าคุณกินอาหารที่มีน้ำมันคุณจะประนีประนอมสุขภาพของคุณและอาหารเพื่อสุขภาพไม่ได้มาพร้อมกับเครื่องเทศเช่นอาหารที่มีน้ำมัน เป็นตัวเลือกส่วนบุคคลไม่ว่าพวกเขาต้องการสุขภาพหรือเครื่องเทศในอาหารของพวกเขา ในทำนองเดียวกัน Node.js พิจารณาที่จะใช้ในสถานการณ์เฉพาะ หากแอพของคุณไม่สอดคล้องกับสถานการณ์นั้นคุณไม่ควรพิจารณาเรื่องนี้สำหรับการพัฒนาแอพของคุณ ฉันแค่ใส่ความคิดของฉันลงไป:

เมื่อใดจึงจะใช้ Node.JS

  1. หากรหัสฝั่งเซิร์ฟเวอร์ของคุณต้องการ cpu cycles น้อยมาก ในอีกโลกหนึ่งคุณกำลังทำการปิดกั้นการทำงานและไม่มีอัลกอริทึม / งานหนักซึ่งใช้รอบ CPU มาก
  2. หากคุณมาจากพื้นหลังของ Javascript และสะดวกสบายในการเขียนโค้ดเธรดเดียวเช่นเดียวกับ JS ฝั่งไคลเอ็นต์

เมื่อใดที่จะไม่ใช้ Node.JS

  1. คำขอของเซิร์ฟเวอร์ของคุณขึ้นอยู่กับอัลกอริทึมที่ใช้ CPU มาก / งาน

การพิจารณาปรับขนาดด้วย Node.JS

  1. Node.JS นั้นไม่ได้ใช้แกนหลักทั้งหมดของระบบพื้นฐานและเป็นเธรดเดี่ยวโดยค่าเริ่มต้นคุณต้องเขียนลอจิกด้วยตัวเองเพื่อใช้ประโยชน์จากตัวประมวลผลแบบมัลติคอร์และทำให้เป็นแบบมัลติเธรด

ทางเลือก Node.JS

มีตัวเลือกอื่นให้ใช้แทน Node.JS แต่Vert.xดูเหมือนว่าจะค่อนข้างดีและมีคุณสมบัติเพิ่มเติมมากมายเช่น polygot และข้อควรพิจารณาเกี่ยวกับความยืดหยุ่นในการปรับขนาดที่ดีกว่า


24
ฉันไม่แน่ใจเกี่ยวกับ "ถ้าคำขอฝั่งเซิร์ฟเวอร์ของคุณมีการบล็อก ops เช่น File IO หรือ Socket IO" อยู่ในรายการ "เมื่อไม่ใช้" หากความเข้าใจของฉันถูกต้องหนึ่งในจุดแข็งของ node.js ก็คือมันมีวิธีการที่มีประสิทธิภาพในการจัดการ IO โดยไม่ปิดกั้น ดังนั้น Node.js สามารถดูได้ในฐานะ "วิธีแก้" สำหรับการบล็อก IO
Ondrej Peterka

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

4
@ajay จากnodejs.orgพวกเขาพูดว่า "non-blocking I / O" โปรดตรวจสอบ "เมื่อไม่" 2 และ 3
Omar Al-Ithawi

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

4
คุณสามารถใช้ node.js สำหรับการคำนวณหนัก forkใช้ ดูstackoverflow.com/questions/9546225/... โหนดจัดการหลายคอร์ได้เป็นอย่างดีด้วยclusterโมดูล nodejs.org/api/cluster.html
Jess

41

อีกสิ่งที่ยอดเยี่ยมที่ฉันคิดว่าไม่มีใครพูดถึง Node.js คือชุมชนที่น่าทึ่งระบบการจัดการแพ็กเกจ (npm) และจำนวนของโมดูลที่มีอยู่ที่คุณสามารถรวมได้โดยรวมไว้ในไฟล์ package.json ของคุณ


6
และแพ็คเกจเหล่านี้ค่อนข้างใหม่ดังนั้นจึงมีประโยชน์ของการเข้าใจถึงปัญหาหลังเหตุการณ์และมีแนวโน้มที่จะเป็นไปตามมาตรฐานเว็บล่าสุด
joeytwiddle

3
ด้วยความเคารพจากทุกคนเป็นจำนวนมากของแพคเกจใน NPM จะแย่เพราะNPM ไม่ได้มีกลไกในการแพคเกจอัตรา ย้อนหลังจากCPANทุกคน?
Dan Dascalescu

น่าเสียดายที่ไม่มีไลบรารี websockets ใดที่สามารถตอบสนองข้อกำหนด rfc 6455 ได้ node.js fanboys เป็นคนหูหนวกเป็นใบ้และตาบอดเมื่อให้ข้อเท็จจริงนี้
r3wt

1
ฉันไม่รู้เกี่ยวกับเมื่อคุณแสดงความคิดเห็น แต่ ณ ตอนนี้ไลบรารี ws สนับสนุนข้อมูลจำเพาะนั้น
Jonathan Gray

37

ส่วนของฉัน: nodejs เหมาะอย่างยิ่งสำหรับการสร้างระบบเรียลไทม์เช่นการวิเคราะห์แชทแอพ apis เซิร์ฟเวอร์โฆษณาและอื่น ๆ ฉันสร้างแอพแชทครั้งแรกโดยใช้ nodejs และ socket.io น้อยกว่า 2 ชั่วโมงและในช่วงสัปดาห์สอบ!

แก้ไข

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

ควรใช้เมื่อไร

เมื่อทำการสร้างระบบที่เน้นการทำงานพร้อมกันและความเร็ว

  • เชื่อมต่อเฉพาะเซิร์ฟเวอร์เช่นแอพแชทแอพ irc ฯลฯ
  • เครือข่ายทางสังคมที่ให้ความสำคัญกับทรัพยากรเรียลไทม์เช่นตำแหน่งทางภูมิศาสตร์สตรีมวิดีโอสตรีมเสียงและอื่น ๆ
  • การจัดการข้อมูลขนาดเล็กอย่างรวดเร็วเหมือนเว็บแอปวิเคราะห์
  • เป็นการเปิดเผย REST api เท่านั้น

เมื่อไม่ใช้

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

  • บล็อกง่ายและเว็บไซต์คงที่
  • เช่นเดียวกับไฟล์เซิร์ฟเวอร์คงที่

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


บล็อกง่าย ๆ ยังคงได้ประโยชน์จาก Node.js สำหรับการให้บริการไฟล์สแตติกคุณยังคงสามารถใช้ Node.js และหากโหลดเพิ่มขึ้นเพียงเพิ่ม Nginx reverse proxy ไว้ข้างหน้าตามแนวทางปฏิบัติที่ดีที่สุดในปัจจุบัน เซิร์ฟเวอร์ Apache httpd เป็นไดโนเสาร์ที่กำลังจะตาย - ดูการสำรวจ Netcraftนี้
Endrju

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

30

มันสามารถใช้ที่ไหน

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

ในหน้ามือถือ บริษัท ที่มีชื่อเสียงนั้นใช้ Node.js สำหรับโซลูชั่นมือถือของพวกเขา ลองดูทำไม

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

eBayเปิดตัว ql.io ภาษาสืบค้นเว็บสำหรับ HTTP APIs ซึ่งใช้ Node.js เป็น runtime stack พวกเขาสามารถปรับแต่งเวิร์กสเตชันอูบุนตูคุณภาพระดับปกติเพื่อจัดการการเชื่อมต่อที่ใช้งานได้มากกว่า 120,000 ต่อกระบวนการ node.js แต่ละการเชื่อมต่อใช้หน่วยความจำประมาณ 2kB!

Walmartออกแบบแอพมือถือขึ้นใหม่เพื่อใช้ Node.js และผลักดันการประมวลผล JavaScript ไปยังเซิร์ฟเวอร์

อ่านเพิ่มเติมได้ที่: http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/


20

โหนดที่ดีที่สุดสำหรับการจัดการคำร้องขอพร้อมกัน -

ดังนั้นเรามาเริ่มด้วยเรื่องราว จาก 2 ปีที่แล้วฉันทำงานกับ JavaScript และพัฒนาส่วนหน้าของเว็บและฉันก็สนุกกับมัน พวกแบ็คเอนด์ให้เราเป็น API ของภาษาจาวา, หลาม (เราไม่สนใจ) และเราก็แค่เขียนการโทร AJAX, รับข้อมูลของเราและเดาอะไร! เราเสร็จแล้ว แต่ในความเป็นจริงมันไม่ใช่เรื่องง่ายถ้าข้อมูลที่เราได้รับไม่ถูกต้องหรือมีข้อผิดพลาดของเซิร์ฟเวอร์บางอย่างเราก็ติดขัดและเราต้องติดต่อพวกแบ็คเอนด์ของเราผ่านทางอีเมลหรือแชท (บางครั้งบน whatsApp :)) ไม่เท่ห์ ถ้าเราเขียน API ของเราใน JavaScript และเรียก API เหล่านั้นจากส่วนหน้าของเรา ใช่มันค่อนข้างเท่เพราะถ้าเราประสบปัญหาใด ๆ ใน API เราสามารถดูได้ เดาสิ! คุณสามารถทำได้ตอนนี้ได้อย่างไร - โหนดอยู่ที่นั่นเพื่อคุณ

ตกลงตกลงว่าคุณสามารถเขียน API ของคุณใน JavaScript แต่ถ้าฉันตกลงกับปัญหาข้างต้น คุณมีเหตุผลอื่นที่จะใช้ node สำหรับ rest API หรือไม่?

ดังนั้นนี่คือความมหัศจรรย์ที่เริ่มต้น ใช่ฉันมีเหตุผลอื่นที่จะใช้โหนดสำหรับ API ของเรา

กลับไปที่ระบบ API พักผ่อนแบบเดิมของเราซึ่งขึ้นอยู่กับการบล็อกการทำงานหรือการทำเกลียว สมมติว่ามีคำขอที่เกิดขึ้นพร้อมกันสองรายการเกิดขึ้น (r1 และ r2) แต่ละคำขอต้องการการดำเนินการฐานข้อมูล ดังนั้นในระบบดั้งเดิมจะเกิดอะไรขึ้น:

1. วิธีที่รอ:เซิร์ฟเวอร์ของเราเริ่มให้บริการr1ตามคำขอและรอการตอบกลับแบบสอบถาม หลังจากเสร็จสิ้นr1เซิร์ฟเวอร์จะเริ่มให้บริการr2และดำเนินการในลักษณะเดียวกัน ดังนั้นการรอคอยไม่ใช่ความคิดที่ดีเพราะเราไม่มีเวลามาก

2. เธรดวิธี:เซิร์ฟเวอร์ของเราจะสร้างสองเธรดสำหรับทั้งคำขอr1และr2ตอบสนองวัตถุประสงค์ของพวกเขาหลังจากทำการสืบค้นฐานข้อมูลดังนั้นมันจึงเจ๋งเร็ว แต่มันก็ใช้หน่วยความจำมากเพราะคุณสามารถเห็นว่าเราเริ่มสองเธรด จากนั้นคุณต้องจัดการกับปัญหาการหยุดชะงัก ดังนั้นมันจึงดีกว่าวิธีที่รอ แต่ยังมีปัญหาอยู่

ตอนนี้ที่นี่เป็นอย่างไรโหนดจะทำ:

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

ดังนั้นไม่ต้องรอไม่ต้องเธรดไม่มีการใช้หน่วยความจำ - ใช่นี่เป็นวิธีที่ให้บริการ API ส่วนที่เหลือ


1
สวัสดี Anshul คุณสามารถทำอย่างละเอียดหรือแนะนำทรัพยากรบางอย่างเกี่ยวกับวิธีการหยุดชะงักอาจเกิดขึ้นในทางเกลียว
jsbisht

16

อีกหนึ่งเหตุผลของฉันที่จะเลือก Node.js สำหรับโครงการใหม่คือ:

สามารถพัฒนาระบบคลาวด์ที่บริสุทธิ์ได้

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

แน่นอนว่าอาจมี IDE ที่ใช้ระบบคลาวด์สำหรับภาษาหรือแพลตฟอร์มอื่น ๆ (Cloud 9 IDE กำลังเพิ่มการสนับสนุนสำหรับภาษาอื่นเช่นกัน) แต่การใช้ Cloud 9 เพื่อพัฒนา Node.js เป็นประสบการณ์ที่ยอดเยี่ยมสำหรับฉัน


1
จริง ๆ แล้ว Cloud9 IDE และอื่น ๆ (โค้ดที่ฉันใช้) สนับสนุนภาษาเว็บเกือบทุกประเภท
Wanny Miarelli

7
คุณเป็นคนจริงจังหรือเปล่า? นี่เป็นเกณฑ์สำหรับการเลือกสแต็กหรือไม่ :) มีความสุขที่ได้ผลกับคุณ!
matanster

15

อีกสิ่งหนึ่งที่โหนดมอบให้คือความสามารถในการสร้างหลาย v8 instanes ของโหนดโดยใช้กระบวนการลูกของโหนด ( childProcess.fork ()แต่ละอันต้องใช้หน่วยความจำ10mbตามเอกสาร) ในทันทีดังนั้นจึงไม่ส่งผลกระทบต่อกระบวนการหลักที่ใช้เซิร์ฟเวอร์ ดังนั้นการถ่ายภาพงานแบ็คกราวน์ที่ต้องการโหลดเซิร์ฟเวอร์จำนวนมากกลายเป็นการเล่นของเด็กและเราสามารถฆ่าพวกเขาได้อย่างง่ายดายตามต้องการ

ฉันใช้โหนดจำนวนมากและในแอพส่วนใหญ่ที่เราสร้างต้องใช้การเชื่อมต่อเซิร์ฟเวอร์ในเวลาเดียวกันจึงเป็นการรับส่งข้อมูลเครือข่ายจำนวนมาก เฟรมเวิร์กเช่นExpress.jsและKoajsใหม่(ซึ่งลบการเรียกกลับนรก) ทำให้การทำงานบนโหนดง่ายยิ่งขึ้น


15

แร่ใยหิน longjohns ...

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

ฉันได้เห็นมุมมองที่สดใสของประสบการณ์ของฉันกับ Node.js แต่ฉันเป็นคนซื่อสัตย์เกี่ยวกับคะแนนที่ดีและคะแนนที่ไม่ดีที่ฉันพบ

ให้ฉันรวมคำพูดไม่กี่คำที่เกี่ยวข้องที่นี่:

คำเตือน: Node.js และระบบนิเวศของมันร้อน - ร้อนพอที่จะเผาคุณไม่ดี!

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

มี gotchas ที่ไม่เพียง แต่รบกวนผู้คนที่มาจาก Python / Django ซึ่งจะโหลดแหล่งที่มาทันทีหากคุณเปลี่ยนแปลงอะไร ด้วย Node.js พฤติกรรมเริ่มต้นคือถ้าคุณทำการเปลี่ยนแปลงหนึ่งเวอร์ชันเก่าจะยังคงใช้งานได้จนกว่าจะหมดเวลาหรือจนกว่าคุณจะหยุดและรีสตาร์ทเซิร์ฟเวอร์ด้วยตนเอง พฤติกรรมที่ไม่เหมาะสมนี้ไม่เพียงรบกวน Pythonistas เท่านั้น นอกจากนี้ยังทำให้ผู้ใช้ Node.js ดั้งเดิมที่ทำให้เกิดปัญหาต่าง ๆ คำถาม StackOverflow“ การโหลดไฟล์ซ้ำอัตโนมัติใน Node.js” ในขณะที่เขียนนี้มีผู้อัปโหลดมากกว่า 200 คนและ 19 คำตอบ การแก้ไขจะชี้นำผู้ใช้ไปยังสคริปต์พี่เลี้ยง, node-supervisor พร้อมโฮมเพจที่http://tinyurl.com/reactjs-node-supervisor. ปัญหานี้กำบังผู้ใช้ใหม่ที่มีโอกาสที่ดีที่จะรู้สึกโง่เพราะพวกเขาคิดว่าพวกเขาได้แก้ไขปัญหาแล้ว แต่พฤติกรรมรถบั๊กเก่าไม่เปลี่ยนแปลงอย่างสมบูรณ์ และง่ายต่อการลืมเด้งเซิร์ฟเวอร์ ฉันทำมาหลายครั้งแล้ว และข้อความที่ฉันต้องการจะบอกคือ“ ไม่คุณไม่ใช่คนโง่เพราะพฤติกรรมของ Node.js กัดหลังของคุณ เป็นเพียงการที่นักออกแบบของ Node.js ไม่เห็นเหตุผลที่จะแสดงพฤติกรรมที่เหมาะสมที่นี่ พยายามรับมือกับมันบางทีใช้ความช่วยเหลือเล็กน้อยจากโหนดผู้ดูแลหรือวิธีแก้ไขปัญหาอื่น ๆ แต่โปรดอย่าเดินออกไปรู้สึกว่าคุณโง่ คุณไม่ใช่คนที่มีปัญหา ปัญหาอยู่ในพฤติกรรมเริ่มต้นของ Node.js”

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

ภาคผนวกที่ฉันไม่ต้องการจริง ๆ หลังจาก crescendo ที่เพิ่มขึ้นในบทสุดท้ายและบทสรุปพูดถึงสิ่งที่ฉันสามารถพบได้ในระบบนิเวศ

ฐานข้อมูลอื่นที่ดูเหมือนว่าลงตัวพอดีและอาจแลกได้คือการใช้งานฝั่งเซิร์ฟเวอร์ของที่เก็บคีย์ - ค่า HTML5 วิธีการนี้มีข้อได้เปรียบที่สำคัญของ API ซึ่งนักพัฒนาส่วนใหญ่ที่ดีเข้าใจดีพอ สำหรับเรื่องนั้นก็เป็น API ที่นักพัฒนาส่วนหน้าไม่ดีส่วนใหญ่เข้าใจดีพอ แต่ด้วยแพ็คเกจ node-localstorage ในขณะที่ไม่มีการเข้าถึงพจนานุกรม - ไวยากรณ์ (คุณต้องการใช้ localStorage.setItem (key, value) หรือ localStorage.getItem (key) ไม่ใช่ localStorage [key]) จะใช้ semantics แบบเต็ม localStorage รวมถึงโควต้า 5MB เริ่มต้น - ทำไมล่ะ ผู้พัฒนา JavaScript ฝั่งเซิร์ฟเวอร์จำเป็นต้องได้รับการปกป้องจากตนเองหรือไม่?

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

อย่างไรก็ตามมันอาจชี้ให้เห็นอย่างนุ่มนวลว่าเมื่อคุณเป็นหนึ่งในรหัสการเขียนสำหรับเซิร์ฟเวอร์ของคุณคุณไม่ต้องการการป้องกันเพิ่มเติมใด ๆ จากการสร้างฐานข้อมูลของคุณมากกว่าขนาด 5MB ที่สามารถทนได้ นักพัฒนาส่วนใหญ่ไม่ต้องการหรือไม่ต้องการเครื่องมือที่ทำหน้าที่เป็นพี่เลี้ยงและปกป้องพวกเขาจากการจัดเก็บข้อมูลฝั่งเซิร์ฟเวอร์มากกว่า 5MB และโควต้า 5MB ที่เป็นการปรับสมดุลสีทองบนฝั่งไคลเอ็นต์ค่อนข้างจะค่อนข้างโง่บนเซิร์ฟเวอร์ Node.js (และสำหรับฐานข้อมูลสำหรับผู้ใช้หลายคนเช่นที่กล่าวถึงในภาคผนวกนี้อาจมีการชี้ให้เห็นอย่างเจ็บปวดเล็กน้อยว่านั่นไม่ใช่ 5MB ต่อบัญชีผู้ใช้เว้นแต่คุณจะสร้างฐานข้อมูลแยกต่างหากบนดิสก์สำหรับแต่ละบัญชีผู้ใช้ บัญชีผู้ใช้ทั้งหมดเข้าด้วยกันซึ่งอาจเจ็บปวดถ้าคุณไปไวรัส!) เอกสารระบุว่าโควต้าสามารถปรับแต่งได้ แต่อีเมลเมื่อสัปดาห์ที่ผ่านมาถึงนักพัฒนาที่ถามวิธีการเปลี่ยนโควต้าที่ยังไม่ได้ตอบเช่นเดียวกับคำถาม StackOverflow ถามเดียวกัน คำตอบเดียวที่ฉันสามารถหาได้คืออยู่ในแหล่ง Github CoffeeScript โดยที่มันถูกระบุว่าเป็นอาร์กิวเมนต์เลขจำนวนเต็มตัวที่สองที่เป็นทางเลือกของตัวสร้าง ง่ายพอและคุณสามารถระบุโควต้าเท่ากับขนาดดิสก์หรือพาร์ติชัน แต่นอกเหนือจากการพอร์ตคุณสมบัติที่ไม่สมเหตุสมผลผู้เขียนเครื่องมือก็ล้มเหลวอย่างสมบูรณ์ในการปฏิบัติตามแบบแผนมาตรฐานของการตีความ 0 ว่าหมายถึง“ ไม่ จำกัด ” สำหรับตัวแปรหรือฟังก์ชั่นที่จำนวนเต็มคือการระบุขีด จำกัด สูงสุดสำหรับการใช้ทรัพยากรบางอย่าง สิ่งที่ดีที่สุดที่จะทำอย่างไรกับความผิดพลาดนี้อาจเป็นการระบุว่าโควต้านั้นไม่มีที่สิ้นสุด:

if (typeof localStorage === 'undefined' || localStorage === null)
  {      
  var LocalStorage = require('node-localstorage').LocalStorage;
  localStorage = new LocalStorage(__dirname + '/localStorage',
    Infinity);
  }

การสลับสองความคิดเห็นตามลำดับ:

ผู้คนยิงตัวเองอย่างไม่จำเป็นโดยใช้ JavaScript โดยรวมและส่วนหนึ่งของ JavaScript ที่ทำให้ภาษาที่น่านับถือคือ Douglas Crockford กล่าวโดยสรุปว่า“ JavaScript เป็นภาษาที่มีบางส่วนที่ดีจริงๆและบางส่วนที่ไม่ดี นี่คือส่วนที่ดี แค่ลืมว่าไม่มีอะไรอีกแล้ว” บางทีระบบนิเวศของ Node.js ที่ร้อนแรงอาจจะเติบโตขึ้นเอง “ Douglas Crockford” ซึ่งจะกล่าวว่า“ ระบบนิเวศของ Node.js นั้นเป็นรหัส Wild West แต่มีอัญมณีจริงบางอย่างที่จะพบ นี่คือแผนงาน นี่คือพื้นที่ที่จะหลีกเลี่ยงค่าใช้จ่ายใด ๆ นี่คือพื้นที่ที่มีคนรวยที่สุดคนหนึ่งที่สามารถพบได้ในภาษาหรือสภาพแวดล้อมใด ๆ ”

บางทีคนอื่นอาจใช้คำเหล่านั้นเป็นสิ่งที่ท้าทายและทำตามคำนำของ Crockford และเขียน“ ส่วนที่ดี” และ / หรือ“ ส่วนที่ดีกว่า” สำหรับ Node.js และระบบนิเวศ ฉันจะซื้อสำเนา!

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


9

หากแอปพลิเคชันของคุณส่วนใหญ่ปรับเปลี่ยนเว็บ apis หรือช่อง io อื่น ๆ ให้หรือใช้ส่วนต่อประสานกับผู้ใช้ node.js อาจเป็นทางเลือกที่ดีสำหรับคุณโดยเฉพาะอย่างยิ่งถ้าคุณต้องการบีบขยายความยืดหยุ่นมากที่สุด คือ javascript (หรือ javascript transpilers แปลก ๆ ) หากคุณสร้าง microservices node.js ก็ใช้ได้เช่นกัน Node.js ยังเหมาะสำหรับโครงการใด ๆ ที่มีขนาดเล็กหรือเรียบง่าย

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

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

โดยเฉพาะอย่างยิ่งเมื่อแอปพลิเคชันของคุณต้องการดำเนินการกระแสข้อมูลแบบซิงโครนัสคุณจะเริ่มมีเลือดไหลผ่านโซลูชั่นที่มีเบคน้อยซึ่งทำให้คุณช้าลงอย่างมากในแง่ของกระบวนการพัฒนาของคุณ หากคุณมีการคำนวณส่วนที่เข้มข้นในแอปพลิเคชันของคุณให้ใช้ดอกยางด้วยความระมัดระวัง (เท่านั้น) node.js อาจจะhttp://koajs.com/หรือ novelties อื่น ๆ ช่วยลดความยุ่งยากในแง่มุมเดิม ๆ เมื่อเทียบกับตอนที่ฉันใช้ node.js หรือเขียนสิ่งนี้


3
มีวิธีการที่มีอยู่มากมายสำหรับการปรับขนาดแอปพลิเคชัน Node.js และคุณไม่ปรากฏว่ามีการอ้างอิงใด ๆ เกี่ยวกับการอ้างสิทธิ์แบบ ใจกำลังขยายตัวเหล่านั้นเหรอ?
Sven Slootweg

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

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

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

-2

ฉันสามารถแบ่งปันบางจุดที่ & ทำไมถึงใช้โหนด js

  1. สำหรับแอพพลิเคชั่นเรียลไทม์เช่นการแชทการแก้ไขการทำงานร่วมกันที่ดีขึ้นเราจะไปกับ nodejs เพราะมันเป็นฐานเหตุการณ์ที่เกิดเหตุการณ์และข้อมูลไปยังไคลเอนต์จากเซิร์ฟเวอร์
  2. ง่ายและเข้าใจง่ายเนื่องจากเป็นฐานจาวาสคริปต์ที่คนส่วนใหญ่มีความคิด
  3. เว็บแอปพลิเคชั่นส่วนใหญ่ในปัจจุบันจะมุ่งไปสู่ ​​angular js & backbone โดยที่โหนดนั้นง่ายต่อการโต้ตอบกับโค้ดฝั่งไคลเอ็นต์เนื่องจากทั้งสองจะใช้ข้อมูล json
  4. มีปลั๊กอินจำนวนมาก

ข้อเสีย: -

  1. โหนดจะรองรับฐานข้อมูลส่วนใหญ่ แต่ที่ดีที่สุดคือ mongodb ซึ่งจะไม่รองรับการรวมที่ซับซ้อนและอื่น ๆ
  2. ข้อผิดพลาดในการคอมไพล์ ... นักพัฒนาควรจัดการข้อยกเว้นแต่ละข้ออื่น ๆ อย่างชาญฉลาดหากแอปพลิเคชันแอคคอร์ดข้อผิดพลาดใด ๆ หยุดทำงานอีกครั้งที่เราต้องไปและเริ่มต้นด้วยตนเองหรือใช้เครื่องมืออัตโนมัติใด ๆ

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


-3
  1. Node นั้นยอดเยี่ยมสำหรับการสร้างต้นแบบอย่างรวดเร็ว แต่ฉันไม่เคยใช้มันเพื่อความซับซ้อนอีกต่อไป ฉันใช้เวลา 20 ปีในการพัฒนาความสัมพันธ์กับคอมไพเลอร์และพลาดแน่นอน

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


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

2
ฉันใช้เวลา 30 ปีกับภาษาที่คอมไพล์แล้ว แต่หลังจากใช้ไปได้ประมาณหนึ่งปีจาวาสคริปต์ก็กลายเป็นภาษาที่ฉันเลือก มันทำงานได้ดีมาก - ฉันสามารถทำอะไรได้มากมายด้วยโค้ดน้อยกว่า Java C # C ++ หรือ C แต่มันเป็นความคิดที่แตกต่าง ตัวแปรที่ไม่ได้พิมพ์นั้นจริง ๆ แล้วเป็นประโยชน์ในหลายกรณี JSLINT เป็นสิ่งจำเป็น เมื่อคุณต้องทำสิ่งต่าง ๆ ในเวลาเดียวกันการโทรกลับแบบอะซิงโครนัสจะปลอดภัยกว่าง่ายกว่าและมีประสิทธิผลมากกว่าภาษาใด ๆ ที่คุณต้องใช้เธรด และคุณต้องรู้จักจาวาสคริปต์อยู่แล้วเพราะภาษาของเบราว์เซอร์
James

ฉันเห็นอกเห็นใจกับข้อกังวลที่เกิดขึ้นและฉันทราบว่าความพยายามบางอย่างได้รับการจัดการกับพวกเขาแม้ว่าพวกเขาจะไม่ได้ใช้อย่างกว้างขวาง มีโครงการที่น่าอัศจรรย์ที่เรียกว่าเทินซึ่งสามารถให้ประเภทที่มาจากการวิเคราะห์แบบคงที่ของรหัสจาวาสคริปต์และห้องสมุด มันมีปลั๊กอินสำหรับบรรณาธิการต่าง ๆ นอกจากนี้ยังมี typescript, JSDoc และBetterJS และจากนั้นก็มีGoซึ่งเป็นหนึ่งในภาษาที่คอมไพล์ต่อ Javascript !
joeytwiddle
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.