Làm cách nào để quyết định khi nào nên sử dụng Node.js?


2195

Tôi chưa quen với loại công cụ này, nhưng gần đây tôi đã nghe rất nhiều về việc Node.js tốt như thế nào . Xem xét mức độ tôi thích làm việc với jQuery và JavaScript nói chung, tôi không thể không tự hỏi làm thế nào để quyết định khi nào nên sử dụng Node.js. Ứng dụng web tôi có trong đầu là một cái gì đó giống như Bitly - lấy một số nội dung, lưu trữ nó.

Từ tất cả các bài tập về nhà tôi đã làm trong vài ngày qua, tôi đã có được thông tin sau đây. Node.js

  • là một công cụ dòng lệnh có thể chạy như một máy chủ web thông thường và cho phép một người chạy các chương trình JavaScript
  • sử dụng công cụ JavaScript V8 tuyệt vời
  • là rất tốt khi bạn cần làm nhiều việc cùng một lúc
  • là dựa trên sự kiện để tất cả những thứ tuyệt vời giống như Ajax có thể được thực hiện ở phía máy chủ
  • cho phép chúng tôi chia sẻ mã giữa trình duyệt và phụ trợ
  • chúng ta hãy nói chuyện với MySQL

Một số nguồn mà tôi đã đi qua là:

Xem xét rằng Node.js có thể chạy gần như hoàn toàn trên các phiên bản EC2 của Amazon , tôi đang cố gắng hiểu loại vấn đề nào yêu cầu Node.js trái ngược với bất kỳ vị vua hùng mạnh nào ngoài đó như PHP , PythonRuby . Tôi hiểu rằng nó thực sự phụ thuộc vào chuyên môn người ta có về ngôn ngữ, nhưng câu hỏi của tôi rơi nhiều hơn vào loại chung: Khi nào nên sử dụng một khung cụ thể và loại vấn đề nào đặc biệt phù hợp?


4
Câu hỏi này đang được thảo luận trên meta ( meta.stackoverflow.com/q/332386/497418 ).
zzzzBov

Câu trả lời:


1355

Bạn đã làm một công việc tuyệt vời để tóm tắt những gì tuyệt vời về Node.js. Cảm giác của tôi là Node.js đặc biệt phù hợp với các ứng dụng mà bạn muốn duy trì kết nối liên tục từ trình duyệt trở lại máy chủ. Sử dụng một kỹ thuật được gọi là "bỏ phiếu dài" , bạn có thể viết một ứng dụng gửi thông tin cập nhật cho người dùng trong thời gian thực. Việc bỏ phiếu dài trên nhiều người khổng lồ của web, như Ruby on Rails hoặc Django , sẽ tạo ra tải trọng lớn trên máy chủ, bởi vì mỗi máy khách đang hoạt động ăn hết một quy trình máy chủ. Tình huống này lên tới một cuộc tấn công tarpit . Khi bạn sử dụng một cái gì đó như Node.js, máy chủ không cần duy trì các luồng riêng biệt cho mỗi kết nối mở.

Điều này có nghĩa là bạn có thể tạo một ứng dụng trò chuyện dựa trên trình duyệt trong Node.js mà hầu như không có tài nguyên hệ thống để phục vụ nhiều khách hàng tuyệt vời. Bất cứ khi nào bạn muốn thực hiện loại bỏ phiếu dài này, Node.js là một lựa chọn tuyệt vời.

Đó là đáng nói đến là Ruby và Python cả hai đều có công cụ để làm việc này ( eventmachinexoắn , tương ứng), nhưng điều đó Node.js làm nó đặc biệt tốt, và từ mặt đất lên. JavaScript đặc biệt phù hợp với mô hình tương tranh dựa trên cuộc gọi lại và nó vượt trội ở đây. Ngoài ra, việc có thể tuần tự hóa và giải tuần tự hóa với JSON gốc cho cả máy khách và máy chủ là khá tiện lợi.

Tôi mong được đọc những câu trả lời khác ở đây, đây là một câu hỏi tuyệt vời.

Thật đáng để chỉ ra rằng Node.js cũng tuyệt vời cho các tình huống trong đó bạn sẽ sử dụng lại rất nhiều mã trên khoảng cách máy khách / máy chủ. Các khuôn khổ Meteor làm cho điều này rất dễ dàng, và rất nhiều folks đang đề xuất này có thể là tương lai của phát triển web. Tôi có thể nói từ kinh nghiệm rằng việc viết mã trong Sao băng rất thú vị và một phần lớn trong số này là dành ít thời gian hơn để suy nghĩ về cách bạn sẽ cơ cấu lại dữ liệu của mình, vì vậy mã chạy trong trình duyệt có thể dễ dàng thao túng nó và vượt qua nó trở lại.

Đây là một bài viết về Kim tự tháp và bỏ phiếu dài, hóa ra rất dễ thiết lập với một chút trợ giúp từ gevent: TicTacToe và Long Polling with Pyramid .


12
Có, tôi nghĩ rất quan trọng khi nghĩ rằng 'node.js đặc biệt phù hợp với các ứng dụng yêu cầu kết nối liên tục từ trình duyệt trở lại máy chủ. - chẳng hạn như các chương trình trò chuyện hoặc trò chơi tương tác 'Nếu một người chỉ đang xây dựng một ứng dụng không nhất thiết cần giao tiếp với người dùng / máy chủ, việc phát triển với các khung công tác khác sẽ rất tốt và sẽ mất ít thời gian hơn.
dùng482594

1
Cảm ơn vì điều này ... Q và A tuyệt vời ;-) Tôi cũng sẽ nghĩ về việc làm chủ một công nghệ tuyệt vời cho cả phát triển phía trước và phía sau so với một vài công nghệ khác nhau;)
Stokingout

12
Tại sao sử dụng bỏ phiếu dài? Điều gì đã xảy ra với tương lai và ổ cắm ?
hitautodesturation

1
Câu trả lời ngắn gọn của tôi là quá trình nền. Yêu cầu và phản hồi (bao gồm API còn lại) tất cả có thể đạt được với bất kỳ ngôn ngữ và máy chủ nào khác. Vì vậy, đối với những người đang suy nghĩ để chuyển đổi các dự án web của họ trong nút. Hãy suy nghĩ lại điều tương tự! Sử dụng nút làm quy trình nền như đọc email bằng imap, xử lý hình ảnh, tải tệp lên đám mây hoặc bất kỳ quy trình dài hoặc không bao giờ kết thúc mà chủ yếu là hướng sự kiện ...
Vikas

409

Tôi tin rằng Node.js phù hợp nhất cho các ứng dụng thời gian thực: trò chơi trực tuyến, công cụ cộng tác, phòng trò chuyện hoặc bất cứ điều gì mà một người dùng (hoặc robot? Hoặc cảm biến?) Làm gì với ứng dụng cần được người dùng khác nhìn thấy ngay lập tức, mà không làm mới trang.

Tôi cũng nên đề cập rằng Socket.IO kết hợp với Node.js sẽ giảm độ trễ thời gian thực của bạn thậm chí xa hơn những gì có thể với việc bỏ phiếu dài. Socket.IO sẽ quay trở lại bỏ phiếu dài như một trường hợp xấu nhất, và thay vào đó sử dụng ổ cắm web hoặc thậm chí Flash nếu chúng có sẵn.

Nhưng tôi cũng nên đề cập rằng bất kỳ tình huống nào mà mã có thể bị chặn do các luồng có thể được xử lý tốt hơn với Node.js. Hoặc bất kỳ tình huống nào mà bạn cần ứng dụng theo hướng sự kiện.

Ngoài ra, Ryan Dahl đã nói trong một cuộc nói chuyện rằng tôi đã từng tham dự rằng Node.js điểm chuẩn đối thủ chặt chẽ với đối thủ Nginx đối với các yêu cầu HTTP cũ thông thường. Vì vậy, nếu chúng tôi xây dựng bằng Node.js, chúng tôi có thể phục vụ các tài nguyên bình thường của mình khá hiệu quả và khi chúng tôi cần các công cụ hướng sự kiện, nó đã sẵn sàng để xử lý nó.

Thêm vào đó là tất cả JavaScript mọi lúc. Lingua Franca trên toàn bộ ngăn xếp.


17
Chỉ cần một quan sát từ ai đó chuyển đổi giữa .Net và Node, Các ngôn ngữ khác nhau cho các khu vực khác nhau của hệ thống sẽ giúp ích rất nhiều khi chuyển đổi ngữ cảnh. Khi tôi đang xem Javascript, tôi đang làm việc trong Máy khách, C # có nghĩa là Máy chủ ứng dụng, SQL = cơ sở dữ liệu. Hoạt động trong Javascript xuyên suốt, tôi thấy mình nhầm lẫn các lớp hoặc đơn giản là mất nhiều thời gian hơn để chuyển đổi ngữ cảnh. Đây có thể là một tạo tác làm việc trên ngăn xếp .NET cả ngày và Noding vào ban đêm, nhưng nó tạo ra sự khác biệt.
Michael Blackburn

9
Thật thú vị, thực tế của các cá nhân đa văn hóa chuyển đổi phương ngữ khi di chuyển giữa các nền văn hóa chính thống và bản địa được gọi là "chuyển đổi mã".
Michael Blackburn

1
Mới hôm nọ tôi đã suy nghĩ về cách tôi có thể chuyển các màu khác nhau cho các .jstệp khác nhau của mình bằng cách nào đó. Màu xanh lá cây cho phía khách hàng, màu xanh dương cho phía máy chủ. Tôi cứ bị "lạc".
AJB

209

Lý do nên sử dụng NodeJS:

  • Nó chạy Javascript, vì vậy bạn có thể sử dụng cùng một ngôn ngữ trên máy chủ và máy khách và thậm chí chia sẻ một số mã giữa chúng (ví dụ: để xác thực mẫu hoặc để hiển thị chế độ xem ở hai đầu.)

  • Các đơn ren hệ thống hướng sự kiện là nhanh ngay cả khi xử lý nhiều yêu cầu cùng một lúc, và cũng đơn giản, so với đa luồng truyền thống Java hoặc ROR khung.

  • Nhóm các gói ngày càng tăng có thể truy cập thông qua NPM , bao gồm các thư viện / mô-đun phía máy khách và máy chủ, cũng như các công cụ dòng lệnh để phát triển web. Hầu hết trong số này được lưu trữ thuận tiện trên github, nơi đôi khi bạn có thể báo cáo sự cố và tìm thấy sự cố trong vài giờ! Thật tuyệt khi có mọi thứ dưới một mái nhà, với báo cáo vấn đề được chuẩn hóa và dễ dàng chuyển đổi.

  • Nó đã trở thành môi trường tiêu chuẩn defacto để chạy các công cụ liên quan đến Javascript và các công cụ liên quan đến web khác , bao gồm trình chạy tác vụ, trình khai thác, trình làm đẹp, bộ xử lý, bộ xử lý trước, bộ xử lý và bộ xử lý phân tích.

  • Nó có vẻ khá phù hợp để tạo mẫu, phát triển nhanh và lặp lại sản phẩm nhanh chóng .

Lý do không sử dụng NodeJS:

  • Nó chạy Javascript, không có kiểm tra kiểu thời gian biên dịch. Đối với các hệ thống hoặc dự án lớn, an toàn phức tạp , bao gồm sự hợp tác giữa các tổ chức khác nhau, ngôn ngữ khuyến khích giao diện hợp đồng và cung cấp kiểm tra kiểu tĩnh có thể giúp bạn tiết kiệm thời gian gỡ lỗi (và vụ nổ ) trong thời gian dài. (Mặc dù JVM bị kẹt với null, vì vậy vui lòng sử dụng Haskell cho các lò phản ứng hạt nhân của bạn.)

  • Thêm vào đó, nhiều gói trong NPM hơi thô và vẫn đang được phát triển nhanh chóng. Một số thư viện cho các khung cũ hơn đã trải qua một thập kỷ thử nghiệm và sửa lỗi, và hiện tại rất ổn định . Npmjs.org không có cơ chế để xếp hạng các gói , điều này dẫn đến sự phổ biến của các gói làm ít nhiều cùng một thứ, trong đó một tỷ lệ lớn không còn được duy trì.

  • Gọi lại địa ngục lồng nhau. (Tất nhiên có 20 giải pháp khác nhau cho việc này ...)

  • Nhóm các gói ngày càng phát triển có thể làm cho một dự án NodeJS xuất hiện hoàn toàn khác với các gói tiếp theo. Có sự đa dạng lớn trong việc triển khai do số lượng lớn các tùy chọn có sẵn (ví dụ: Express / Sails.js / Meteor / Derby ). Điều này đôi khi có thể làm cho nhà phát triển mới khó nhảy vào dự án Node hơn. Trái ngược với việc nhà phát triển Rails tham gia một dự án hiện có: anh ta sẽ có thể làm quen với ứng dụng khá nhanh, vì tất cả các ứng dụng Rails đều được khuyến khích sử dụng cấu trúc tương tự .

  • Đối phó với các tập tin có thể là một chút đau đớn. Những điều không quan trọng trong các ngôn ngữ khác, như đọc một dòng từ tệp văn bản, đủ kỳ lạ để làm với Node.js có câu hỏi StackOverflow về điều đó với hơn 80 lượt upvote. Không có cách nào đơn giản để đọc một bản ghi tại một thời điểm từ tệp CSV . Vân vân.

Tôi yêu NodeJS, nó nhanh và hoang dã và vui vẻ, nhưng tôi lo ngại rằng nó không mấy quan tâm đến tính chính xác có thể chứng minh được. Chúng ta hãy hy vọng chúng ta cuối cùng có thể hợp nhất những điều tốt nhất của cả hai thế giới. Tôi háo hức muốn xem điều gì sẽ thay thế Node trong tương lai ... :)


1
@nane Có Tôi nghĩ rằng họ có thể giải quyết vấn đề đó, tuy nhiên sau đó bạn phải tự giới hạn mình chỉ sử dụng các thư viện được viết bằng ngôn ngữ an toàn hoặc chấp nhận rằng không phải tất cả các cơ sở mã của bạn đều được nhập tĩnh. Nhưng có một lý lẽ: vì bạn nên viết các bài kiểm tra tốt cho mã của mình bất kể ngôn ngữ nào, thì mức độ tin cậy của bạn phải bằng nhau ngay cả đối với mã được gõ động. Nếu chúng tôi chấp nhận lập luận đó, thì những lợi thế của việc gõ mạnh sẽ giảm xuống để hỗ trợ thời gian phát triển / gỡ lỗi, khả năng chứng minh và tối ưu hóa .
joeytwiddle

1
@kervin, tôi đồng ý một số điểm chuẩn sẽ rất tuyệt, nhưng tôi đã thất vọng với những gì tôi có thể tìm thấy trên mạng. Một số người đã lập luận rằng hiệu suất .NET có thể so sánh với Node, nhưng điều quan trọng là những gì bạn đang làm. Node có thể tuyệt vời trong việc cung cấp các thông điệp nhỏ với nhiều kết nối đồng thời, nhưng không tuyệt vời cho các phép tính toán học nặng. Một so sánh hiệu suất tốt sẽ cần phải kiểm tra một loạt các tình huống.
joeytwiddle

2
@joeytwiddle sẽ không những thứ như Typecript giúp Node.js khi xử lý các chương trình phức tạp lớn hơn và đánh máy tĩnh?
CodeMonkey

2
@joeytwiddle cho những gì đáng giá, bạn có thể sử dụng stillmaintained.com để xác định xem gói npm có còn được duy trì hay không (vì phần lớn là trên github). Ngoài ra, npm searchnpm showsẽ cho bạn thấy ngày phát hành gói cuối cùng.
Dan Pantry

3
Bằng cách so sánh đường ray với nút, bạn đang nhầm lẫn một nền tảng với khung. Rails là một khung cho Ruby giống như Sails và sao băng là các khung cho Javascript.
bonsaiOak


127

Tôi có một ví dụ trong thế giới thực nơi tôi đã sử dụng Node.js. Công ty nơi tôi làm việc có một khách hàng muốn có một trang web HTML tĩnh đơn giản. Trang web này là để bán một mặt hàng bằng PayPal và khách hàng cũng muốn có một quầy cho biết số lượng mặt hàng đã bán. Khách hàng dự kiến ​​sẽ có lượng khách truy cập lớn vào trang web này. Tôi quyết định tạo bộ đếm bằng Node.js và Express.js khung .

Ứng dụng Node.js rất đơn giản. Nhận số lượng mặt hàng đã bán từ cơ sở dữ liệu Redis , tăng bộ đếm khi mặt hàng được bán và phục vụ giá trị truy cập cho người dùng thông qua API .

Một số lý do tại sao tôi chọn sử dụng Node.js trong trường hợp này

  1. Nó rất nhẹ và nhanh. Đã có hơn 200000 lượt truy cập trên trang web này trong ba tuần và tài nguyên máy chủ tối thiểu đã có thể xử lý tất cả.
  2. Các quầy thực sự dễ dàng để được thực hiện để được thời gian thực.
  3. Node.js rất dễ cấu hình.
  4. Có rất nhiều mô-đun có sẵn miễn phí. Ví dụ: tôi đã tìm thấy mô-đun Node.js cho PayPal.

Trong trường hợp này, Node.js là một lựa chọn tuyệt vời.


7
Làm thế nào để bạn lưu trữ một cái gì đó như thế? Bạn có phải thiết lập nodejs trên máy chủ sản xuất không? Trong linux?
Miguel Stevens

1
Có một vài PaaS như nodejitsu và Heroku. Hoặc bạn thực sự có thể thiết lập nodejs trên hộp linux tức là từ amazon ec2. xem: lauradhamilton.com/ từ
harry young

13
200.000 lượt truy cập trong vòng 1.814.400 giây. Không liên quan gì cả. Ngay cả bash cũng có thể phục vụ nhiều yêu cầu đó, trên máy chủ chậm nhất. Máy chủ cào. VM chậm nhất.
Tiberiu-Ionuț Stan

105

Những lý do quan trọng nhất để bắt đầu dự án tiếp theo của bạn bằng Node ...

  • Tất cả các anh chàng tuyệt vời nhất đều ở trong đó ... vì vậy nó phải rất vui.
  • Bạn có thể đi chơi ở khu vực mát mẻ và có rất nhiều cuộc phiêu lưu của Node để khoe khoang.
  • Bạn là một penny pincher khi nói đến chi phí lưu trữ đám mây.
  • Đã ở đó với Rails
  • Bạn ghét triển khai IIS
  • Công việc CNTT cũ của bạn đang trở nên khá buồn tẻ và bạn ước mình được ở trong một Start Up mới sáng bóng.

Những gì mong đợi ...

  • Bạn sẽ cảm thấy an toàn và bảo mật với Express mà không cần tất cả các bloatware máy chủ mà bạn không bao giờ cần.
  • Chạy như tên lửa và vảy tốt.
  • Bạn mơ ước nó. Bạn đã cài đặt nó. Gói nút repo npmjs.org là hệ sinh thái lớn nhất của các thư viện nguồn mở trên thế giới.
  • Bộ não của bạn sẽ có thời gian bị biến dạng trong vùng đất của các cuộc gọi lại lồng nhau ...
  • ... Cho đến khi bạn học cách giữ lời hứa của mình .
  • Sắp xếp lạihộ chiếu là những người bạn API mới của bạn.
  • Gỡ lỗi mã async sẽ nhận được umm ... thú vị .
  • Thời gian cho tất cả Noders để làm chủ nguyên cảo .

Ai sử dụng nó?

  • PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
  • Đây là lý do tại sao họ chuyển sang Node .

18
Vâng, tôi có thể trả lời câu hỏi này theo cách truyền thống. Tôi nghĩ rằng tôi đủ điều kiện để làm như vậy nhưng hầu hết đã được nói và tôi nghĩ một số niềm vui nhẹ nhàng sẽ phá vỡ sự đơn điệu. Tôi thường xuyên đóng góp câu trả lời kỹ thuật cho các câu hỏi khác.
Tony O'Hagan

1
Có thể tránh các cuộc gọi lại lồng nhau bằng cách sử dụng các trình tạo ES6 cho mã async
tái cấu trúc

1
@CleanCrispCode: Vâng thực sự! ES6 đã áp dụng kiểu C # async/ awaitvì vậy bây giờ chúng ta có thể tung ra mã Node async sạch hơn nhiều cũng hỗ trợ truyền thống try/ catch. Trong năm 2016/17, các lập trình viên JS đang chuyển sang ES6.
Tony O'Hagan

1
Mười nghìn lần điều này "Bạn sẽ cảm thấy an toàn và an toàn với Express mà không cần tất cả các bloatware máy chủ mà bạn không bao giờ cần"
Simone Poggi

60

Không có gì giống như Silver Bullet. Tất cả mọi thứ đi kèm với một số chi phí liên quan đến nó. Nó giống như nếu bạn ăn thực phẩm có dầu, bạn sẽ làm tổn hại sức khỏe của bạn và thực phẩm lành mạnh không đi kèm với các loại gia vị như thực phẩm có dầu. Đó là lựa chọn cá nhân cho dù họ muốn sức khỏe hoặc gia vị như trong thực phẩm của họ. Cùng một cách Node.js xem xét được sử dụng trong kịch bản cụ thể. Nếu ứng dụng của bạn không phù hợp với kịch bản đó, bạn không nên xem xét nó để phát triển ứng dụng. Tôi chỉ đang đặt suy nghĩ của mình giống nhau:

Khi nào nên sử dụng Node.JS

  1. Nếu mã phía máy chủ của bạn yêu cầu rất ít chu kỳ cpu. Ở thế giới khác, bạn đang thực hiện thao tác không chặn và không có thuật toán / Công việc nặng, tiêu tốn nhiều chu kỳ CPU.
  2. Nếu bạn từ Javascript trở lại và thoải mái khi viết mã Single Threaded giống như JS phía máy khách.

Khi KHÔNG sử dụng Node.JS

  1. Yêu cầu máy chủ của bạn phụ thuộc vào thuật toán tiêu thụ CPU nặng / Công việc.

Cân nhắc khả năng mở rộng với Node.JS

  1. Bản thân Node.JS không sử dụng tất cả lõi của hệ thống cơ bản và nó được phân luồng theo mặc định, bạn phải tự viết logic để sử dụng bộ xử lý đa lõi và làm cho nó đa luồng.

Node.JS thay thế

Có một tùy chọn khác để sử dụng thay cho Node.JS tuy nhiên Vert.x có vẻ khá hứa hẹn và có nhiều tính năng bổ sung như polygot và cân nhắc khả năng mở rộng tốt hơn.


24
Tôi không chắc chắn về "Nếu yêu cầu phía máy chủ của bạn bao gồm chặn các op như File IO hoặc Socket IO" được liệt kê trong "Khi KHÔNG sử dụng". Nếu sự hiểu biết của tôi là đúng, một trong những điểm mạnh của node.js là, nó có các phương tiện không đồng bộ mạnh mẽ để xử lý IO mà không chặn. Vì vậy, Node.js có thể được xem là "phương thuốc" để chặn IO.
Ondrej Peterka

3
@OndraPeterka: Bạn đúng rằng Node.js đang chữa bệnh để chặn IO máy chủ, tuy nhiên nếu trình xử lý yêu cầu của bạn trên máy chủ thì chính nó đang thực hiện một cuộc gọi chặn đến một số hoạt động dịch vụ web / Tệp khác, Node.js sẽ không giúp đỡ ở đây. Nó không chặn IO chỉ cho các yêu cầu đến máy chủ chứ không phải cho yêu cầu gửi đi từ trình xử lý yêu cầu ứng dụng của bạn.
Ajay Tiwari

4
@ajay từ nodejs.org họ nói "I / O không chặn", vui lòng kiểm tra "Khi KHÔNG" 2 và 3.
Omar Al-Ithawi

5
với phiên bản hiện tại, nút thực sự hỗ trợ hỗ trợ đa lõi bằng cách sử dụng cluster. Điều này thực sự tăng hiệu suất ứng dụng Node ít nhất hai lần. Tuy nhiên, tôi nghĩ hiệu suất nên nhiều hơn hai lần khi chúng ổn định cụm lib.
Nam Nguyễn

4
Bạn có thể sử dụng node.js để tính toán nặng. Sử dụng fork. Xem stackoverflow.com/questions/9546225/ Lần . Node xử lý nhiều lõi rất tốt với clustermô-đun. nodejs.org/api/cluster.html
Jess

41

Một điều tuyệt vời khác mà tôi nghĩ rằng không ai đã đề cập về Node.js là cộng đồng tuyệt vời, hệ thống quản lý gói (npm) và số lượng mô-đun tồn tại mà bạn có thể đưa vào bằng cách đơn giản đưa chúng vào tệp pack.json của bạn.


6
Và các gói này đều tương đối mới, vì vậy chúng có lợi ích của nhận thức muộn và có xu hướng tuân thủ các tiêu chuẩn web gần đây.
joeytwiddle

3
Với tất cả sự tôn trọng, rất nhiều gói trên npm rất tệ, bởi vì npm không có cơ chế để xếp hạng các gói . Hindsight từ CPAN có ai không?
Dan Dascalescu

quá tệ, không có thư viện websockets nào có thể đáp ứng thông số kỹ thuật rfc 6455. Các fanboys của node.js bị điếc, câm và mù khi thực tế này được đưa ra.
r3wt

1
Tôi không biết khi nào bạn đưa ra nhận xét nhưng đến bây giờ thư viện ws hỗ trợ thông số đó
Jonathan Gray

37

Phần của tôi: nodejs rất tuyệt để tạo các hệ thống thời gian thực như phân tích, ứng dụng trò chuyện, apis, máy chủ quảng cáo, v.v.

Biên tập

Đã vài năm kể từ khi tôi bắt đầu sử dụng nodejs và tôi đã sử dụng nó để tạo ra nhiều thứ khác nhau bao gồm máy chủ tệp tĩnh, phân tích đơn giản, ứng dụng trò chuyện và nhiều hơn nữa. Đây là khi tôi sử dụng nodejs

Khi nào sử dụng

Khi làm hệ thống nhấn mạnh vào sự tương tranh và tốc độ.

  • Ổ cắm chỉ các máy chủ như ứng dụng trò chuyện, ứng dụng irc, v.v.
  • Các mạng xã hội tập trung vào các tài nguyên thời gian thực như định vị địa lý, luồng video, luồng âm thanh, v.v.
  • Xử lý các khối dữ liệu nhỏ thực sự nhanh như một ứng dụng web phân tích.
  • Như phơi bày một REST chỉ api.

Khi không sử dụng

Đây là một máy chủ web rất linh hoạt để bạn có thể sử dụng nó bất cứ nơi nào bạn muốn nhưng có lẽ không phải là những nơi này.

  • Blog đơn giản và các trang web tĩnh.
  • Cũng như một máy chủ tệp tĩnh.

Hãy nhớ rằng tôi chỉ là nitpicking. Đối với các máy chủ tệp tĩnh, apache tốt hơn chủ yếu vì nó có sẵn rộng rãi. Cộng đồng nodejs đã phát triển lớn hơn và trưởng thành hơn qua nhiều năm và có thể nói rằng nodejs có thể được sử dụng ở mọi nơi nếu bạn có lựa chọn lưu trữ riêng.


Các blog đơn giản vẫn có thể hưởng lợi từ Node.js. Để phục vụ các tệp tĩnh, bạn vẫn có thể sử dụng Node.js và nếu tải tăng, chỉ cần thêm proxy ngược Nginx ở phía trước, theo các thực tiễn tốt nhất hiện tại. Máy chủ Apache httpd là một con khủng long sắp chết - xem khảo sát của Netcraft này .
Endrju

Tôi sẽ nói khác - hãy xem ghost.org , trông thật tuyệt vời và được xây dựng dựa trên NodeJs - cộng tác, chỉnh sửa bài viết theo thời gian thực. Ngoài ra, việc tạo một trang đơn giản trong NodeJs, giả sử sử dụng sailsjs.org , rất dễ dàng, nhanh chóng và bạn không cần phải bận tâm đến việc học bất kỳ ngôn ngữ lập trình phía máy chủ nào
Bery

30

Nó có thể được sử dụng ở đâu

  • Các ứng dụng được định hướng theo sự kiện cao và bị ràng buộc I / O rất nhiều
  • Các ứng dụng xử lý một số lượng lớn kết nối đến các hệ thống khác
  • Các ứng dụng thời gian thực (Node.js được thiết kế từ đầu để có thời gian thực và dễ sử dụng.)
  • Các ứng dụng sắp xếp các luồng thông tin đến và từ các nguồn khác
  • Lưu lượng truy cập cao, ứng dụng có thể mở rộng
  • Các ứng dụng di động phải nói chuyện với API nền tảng & cơ sở dữ liệu mà không phải thực hiện nhiều phân tích dữ liệu
  • Xây dựng các ứng dụng nối mạng
  • Các ứng dụng cần nói chuyện với back end rất thường xuyên

Trên mặt trận di động, các công ty hàng đầu đã dựa vào Node.js cho các giải pháp di động của họ. Kiểm tra tại sao?

LinkedIn là một người dùng nổi bật. Toàn bộ ngăn xếp di động của họ được xây dựng trên Node.js. Họ đã đi từ việc chạy 15 máy chủ với 15 trường hợp trên mỗi máy vật lý, đến chỉ 4 trường hợp - có thể xử lý lưu lượng gấp đôi!

eBay đã ra mắt ql.io, một ngôn ngữ truy vấn web cho API HTTP, sử dụng Node.js làm ngăn xếp thời gian chạy. Họ đã có thể điều chỉnh máy trạm Ubuntu chất lượng dành cho nhà phát triển để xử lý hơn 120.000 kết nối hoạt động trên mỗi quy trình của node.js, với mỗi kết nối tiêu tốn khoảng 2kB bộ nhớ!

Walmart đã thiết kế lại ứng dụng di động của mình để sử dụng Node.js và đẩy quá trình xử lý JavaScript của nó đến máy chủ.

Đọc thêm tại: http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/


20

Nút tốt nhất để xử lý yêu cầu đồng thời -

Vì vậy, hãy bắt đầu với một câu chuyện. Từ 2 năm trước tôi đã làm việc về JavaScript và phát triển giao diện người dùng và tôi rất thích nó. Những người ở cuối cung cấp cho chúng tôi một số API được viết bằng Java, python (chúng tôi không quan tâm) và chúng tôi chỉ đơn giản viết một cuộc gọi AJAX, nhận dữ liệu của chúng tôi và đoán xem! chúng ta xong rồi. Nhưng thực tế thì không dễ chút nào không mát Điều gì xảy ra nếu chúng ta viết API của chúng tôi bằng JavaScript và gọi các API đó từ giao diện của chúng tôi? Vâng, điều đó thật tuyệt vời bởi vì nếu chúng ta gặp phải bất kỳ vấn đề nào trong API, chúng ta có thể xem xét nó. Đoán xem! Bạn có thể làm điều này bây giờ, làm thế nào? - Nút là có cho bạn.

Ok đồng ý rằng bạn có thể viết API bằng JavaScript nhưng nếu tôi ổn với vấn đề trên. Bạn có bất kỳ lý do nào khác để sử dụng nút cho API còn lại không?

Vì vậy, đây là phép thuật bắt đầu. Có, tôi có lý do khác để sử dụng nút cho API của chúng tôi.

Chúng ta hãy quay trở lại hệ thống API nghỉ ngơi truyền thống của chúng tôi dựa trên hoạt động chặn hoặc luồng. Giả sử hai yêu cầu đồng thời xảy ra (r1 và r2), mỗi yêu cầu đều yêu cầu hoạt động cơ sở dữ liệu. Vì vậy, trong hệ thống truyền thống, điều gì sẽ xảy ra:

1. Cách chờ: Máy chủ của chúng tôi bắt đầu phục vụ r1yêu cầu và chờ phản hồi truy vấn. Sau khi hoàn thành r1, máy chủ bắt đầu phục vụ r2và thực hiện theo cách tương tự. Vì vậy, chờ đợi không phải là một ý tưởng tốt bởi vì chúng ta không có nhiều thời gian.

2. Cách phân luồng: Máy chủ của chúng tôi sẽ tạo hai luồng cho cả hai yêu cầu r1r2 phục vụ mục đích của chúng sau khi truy vấn cơ sở dữ liệu rất nhanh. Nhưng nó tiêu tốn bộ nhớ vì bạn có thể thấy chúng tôi bắt đầu hai luồng cũng tăng khi cả hai yêu cầu truy vấn cùng một dữ liệu sau đó bạn phải đối phó với các loại vấn đề bế tắc. Vì vậy, nó tốt hơn so với cách chờ đợi nhưng vẫn còn vấn đề.

Bây giờ đây là, làm thế nào nút sẽ làm điều đó:

3. Nodeway: Khi cùng một yêu cầu đồng thời xuất hiện trong nút thì nó sẽ đăng ký một sự kiện với cuộc gọi lại của nó và di chuyển về phía trước, nó sẽ không chờ phản hồi truy vấn cho một r1yêu cầu cụ thể. Vì vậy, khi yêu cầu đến vòng lặp sự kiện của nút (vâng, có một vòng lặp sự kiện trong nút phục vụ mục đích này.) đăng ký một sự kiện với chức năng gọi lại và di chuyển về phía trước để phục vụ r2yêu cầu và tương tự đăng ký sự kiện của nó với cuộc gọi lại. Bất cứ khi nào bất kỳ truy vấn nào kết thúc, nó sẽ kích hoạt sự kiện tương ứng của nó và thực hiện cuộc gọi lại để hoàn thành mà không bị gián đoạn.

Vì vậy, không phải chờ đợi, không phân luồng, không tiêu thụ bộ nhớ - vâng, đây là nút để phục vụ API nghỉ ngơi.


1
Xin chào Anshul. Bạn có thể xây dựng hoặc đề xuất một số tài nguyên về cách bế tắc có thể xảy ra theo cách phân luồng.
jsbisht 14/03/2015

16

Một lý do nữa của tôi để chọn Node.js cho một dự án mới là:

Có thể thực hiện phát triển dựa trên đám mây thuần túy

Tôi đã sử dụng Cloud9 IDE được một thời gian và bây giờ tôi không thể tưởng tượng được nếu không có nó, nó bao gồm tất cả các vòng đời phát triển. Tất cả những gì bạn cần là một trình duyệt và bạn có thể mã hóa mọi lúc mọi nơi trên mọi thiết bị. Bạn không cần kiểm tra mã trong một Máy tính (như ở nhà), sau đó kiểm tra trong một máy tính khác (như tại nơi làm việc).

Tất nhiên, có thể có IDE dựa trên đám mây cho các ngôn ngữ hoặc nền tảng khác (Cloud 9 IDE cũng đang hỗ trợ thêm các ngôn ngữ khác), nhưng sử dụng Cloud 9 để phát triển Node.js thực sự là một trải nghiệm tuyệt vời đối với tôi.


1
Trên thực tế, Cloud9 IDE và các ứng dụng khác (mã hóa cái tôi sử dụng) hỗ trợ hầu hết tất cả các loại ngôn ngữ web.
Wanny Miarelli

7
Bạn có nghiêm túc không? đây là tiêu chí để chọn một ngăn xếp? :) rất vui vì nó hiệu quả với bạn!
matanster 18/03/2015

15

Một điều nữa nút cung cấp là khả năng tạo nhiều v8 instanes của nút bằng cách sử dụng tiến trình con của nút ( childProcess.fork () mỗi yêu cầu bộ nhớ 10mb theo tài liệu), do đó không ảnh hưởng đến quá trình chính chạy máy chủ. Vì vậy, giảm tải một công việc nền đòi hỏi tải máy chủ lớn sẽ trở thành một trò chơi trẻ con và chúng ta có thể dễ dàng giết chúng khi cần thiết.

Tôi đã sử dụng nút rất nhiều và trong hầu hết các ứng dụng chúng tôi xây dựng, yêu cầu kết nối máy chủ cùng một lúc, do đó lưu lượng mạng lớn. Các khung như Express.jsKoajs mới (đã loại bỏ địa ngục gọi lại) đã giúp việc làm việc trên nút trở nên dễ dàng hơn.


15

Tặng longjohns ...

Hôm qua tiêu đề của tôi với Ấn phẩm Packt, Lập trình phản ứng với JavaScript . Nó không thực sự là một tiêu đề Node.js-centric; các chương đầu được dự định để bao quát lý thuyết, và các chương nặng về mã này bao gồm thực hành. Bởi vì tôi không thực sự nghĩ rằng nó sẽ là thích hợp để thất bại trong việc cung cấp cho độc giả một máy chủ web, Node.js dường như cho đến nay lựa chọn rõ ràng. Vụ án đã được đóng lại trước khi nó được mở.

Tôi có thể đã đưa ra một cái nhìn rất màu hồng về trải nghiệm của tôi với Node.js. Thay vào đó tôi thành thật về điểm tốt và điểm xấu tôi gặp phải.

Hãy để tôi bao gồm một vài trích dẫn có liên quan ở đây:

Cảnh báo: Node.js và hệ sinh thái của nó rất nóng - đủ để đốt cháy bạn!

Khi tôi còn là trợ lý toán của giáo viên, một trong những gợi ý không rõ ràng mà tôi được nói là đừng nói với học sinh rằng có gì đó dễ dàng. Lý do có phần rõ ràng khi nhìn lại: nếu bạn nói với mọi người điều gì đó dễ dàng, một người không thấy giải pháp có thể sẽ cảm thấy ngu ngốc (thậm chí nhiều hơn), bởi vì họ không chỉ không biết cách giải quyết vấn đề, mà là vấn đề họ quá ngu ngốc để hiểu là một điều dễ dàng!

Có những vấn đề không làm phiền mọi người đến từ Python / Django, ngay lập tức tải lại nguồn nếu bạn thay đổi bất cứ điều gì. Với Node.js, hành vi mặc định là nếu bạn thực hiện một thay đổi, phiên bản cũ sẽ tiếp tục hoạt động cho đến hết thời gian hoặc cho đến khi bạn dừng và khởi động lại máy chủ theo cách thủ công. Hành vi không phù hợp này không chỉ gây khó chịu cho Pythonistas; nó cũng gây khó chịu cho người dùng Node.js bản địa, những người cung cấp nhiều cách giải quyết khác nhau. Câu hỏi StackOverflow Tự động tải lại các tệp trong Node.js, tại thời điểm viết bài này, có hơn 200 câu hỏi và 19 câu trả lời; một chỉnh sửa hướng người dùng đến một kịch bản bảo mẫu, người giám sát nút, với trang chủ tại http://tinyurl.com/reactjs-node-supervisor. Vấn đề này khiến người dùng mới có cơ hội tuyệt vời để cảm thấy ngu ngốc vì họ nghĩ rằng họ đã khắc phục vấn đề, nhưng hành vi lỗi cũ là hoàn toàn không thay đổi. Và thật dễ dàng để quên trả lại máy chủ; Tôi đã làm như vậy nhiều lần. Và thông điệp tôi muốn đưa ra là, No No, bạn không ngu ngốc vì hành vi này của Node.js cắn vào lưng bạn; chỉ là các nhà thiết kế của Node.js thấy không có lý do gì để cung cấp hành vi phù hợp ở đây. Hãy cố gắng đối phó với nó, có thể nhờ một chút trợ giúp từ người giám sát nút hoặc giải pháp khác, nhưng xin đừng bỏ đi cảm giác rằng bạn thật ngu ngốc. Bạn không phải là người có vấn đề; vấn đề nằm ở hành vi mặc định của Node.js.

Phần này, sau một số cuộc tranh luận, được để lại, chính xác là vì tôi không muốn tạo ấn tượng về điều đó Thật dễ dàng. Tôi đã cắt tay liên tục trong khi mọi thứ hoạt động và tôi không muốn giải quyết khó khăn và khiến bạn tin rằng việc Node.js và hệ sinh thái của nó hoạt động tốt là một vấn đề đơn giản và nếu điều đó không đơn giản với bạn , bạn không biết bạn đang làm gì. Nếu bạn không gặp phải những khó khăn đáng ghét khi sử dụng Node.js, điều đó thật tuyệt vời. Nếu bạn làm thế, tôi sẽ hy vọng rằng bạn không bỏ đi cảm giác, thì tôi thật ngu ngốc, chắc chắn có điều gì đó không ổn với tôi. Bạn sẽ không ngu ngốc nếu bạn gặp phải những bất ngờ khó chịu khi giao dịch với Node.js. Không phải bạn! Đó là Node.js và hệ sinh thái của nó!

Phụ lục, điều mà tôi không thực sự muốn sau khi tăng cao trong các chương cuối và kết luận, nói về những gì tôi có thể tìm thấy trong hệ sinh thái, và cung cấp một cách giải quyết cho chủ nghĩa văn chương đạo đức:

Một cơ sở dữ liệu khác có vẻ phù hợp hoàn hảo và có thể được hoàn lại là triển khai phía máy chủ của kho lưu trữ khóa-giá trị HTML5. Cách tiếp cận này có lợi thế chính của một API mà hầu hết các nhà phát triển front-end giỏi đều hiểu rõ. Đối với vấn đề đó, đó cũng là một API mà hầu hết các nhà phát triển front-end không giỏi đều hiểu rõ. Nhưng với gói lưu trữ nút cục bộ, trong khi truy cập cú pháp từ điển không được cung cấp (bạn muốn sử dụng localStorage.setItem (khóa, giá trị) hoặc localStorage.getItem (khóa), không phải localStorage [key]), ngữ nghĩa localStorage đầy đủ được triển khai , bao gồm cả dung lượng hạn ngạch 5 MB mặc định TẠI SAO? Các nhà phát triển JavaScript phía máy chủ có cần được bảo vệ khỏi chính họ không?

Đối với khả năng cơ sở dữ liệu phía máy khách, hạn ngạch 5 MB cho mỗi trang web thực sự là một lượng phòng thở rộng rãi và hữu ích để cho phép các nhà phát triển làm việc với nó. Bạn có thể đặt hạn mức thấp hơn nhiều và vẫn cung cấp cho các nhà phát triển một cải tiến không thể đo lường được bằng cách khập khiễng cùng với quản lý cookie. Giới hạn 5 MB không cho vay rất nhanh để xử lý phía máy khách Big Data, nhưng có một khoản trợ cấp thực sự khá hào phóng mà các nhà phát triển tài nguyên có thể sử dụng để làm rất nhiều việc. Tuy nhiên, mặt khác, 5 MB không phải là một phần đặc biệt lớn của hầu hết các đĩa được mua bất kỳ lúc nào gần đây, có nghĩa là nếu bạn và một trang web không đồng ý về việc sử dụng dung lượng đĩa hợp lý là gì, hoặc một số trang web chỉ đơn giản là không ổn định, thì nó không thực sự tốn kém bạn nhiều và bạn không gặp nguy hiểm với ổ cứng bị ngập, trừ khi ổ cứng của bạn đã quá đầy.

Tuy nhiên, có thể nhẹ nhàng chỉ ra rằng khi bạn là một mã viết cho máy chủ của mình, bạn không cần bất kỳ sự bảo vệ bổ sung nào để làm cho cơ sở dữ liệu của bạn có kích thước lớn hơn 5 MB có thể chấp nhận được. Hầu hết các nhà phát triển sẽ không cần và cũng không muốn các công cụ hoạt động như một người giữ trẻ và bảo vệ họ khỏi việc lưu trữ hơn 5 MB dữ liệu phía máy chủ. Và hạn ngạch 5 MB là một hành động cân bằng vàng ở phía máy khách thì hơi ngớ ngẩn trên máy chủ Node.js. (Và, đối với cơ sở dữ liệu cho nhiều người dùng như được nêu trong Phụ lục này, có thể chỉ ra rằng, hơi đau, đó không phải là 5 MB cho mỗi tài khoản người dùng trừ khi bạn tạo một cơ sở dữ liệu riêng trên đĩa cho mỗi tài khoản người dùng; đó là 5 MB được chia sẻ giữa tất cả các tài khoản người dùng với nhau. Điều đó có thể nhận được gây đau đớnnếu bạn bị virus!) Tài liệu nói rằng hạn ngạch có thể tùy chỉnh, nhưng một email một tuần trước cho nhà phát triển hỏi cách thay đổi hạn ngạch không được trả lời, cũng như câu hỏi StackOverflow hỏi tương tự. Câu trả lời duy nhất tôi có thể tìm thấy là trong nguồn Github CoffeeScript, nơi nó được liệt kê dưới dạng đối số nguyên thứ hai tùy chọn cho hàm tạo. Như vậy là đủ dễ dàng và bạn có thể chỉ định hạn ngạch bằng với kích thước đĩa hoặc phân vùng. Nhưng bên cạnh việc chuyển một tính năng không có ý nghĩa, tác giả của công cụ đã hoàn toàn không tuân theo quy ước diễn giải rất chuẩn là 0 không giới hạn đối với một biến hoặc hàm trong đó một số nguyên là chỉ định giới hạn tối đa cho một số sử dụng tài nguyên. Điều tốt nhất để làm với sự không phù hợp này có lẽ là xác định rằng hạn ngạch là Vô cực:

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

Trao đổi hai bình luận theo thứ tự:

Mọi người không cần phải tự mình sử dụng JavaScript một cách toàn diện và một phần của JavaScript được tạo ra bằng ngôn ngữ đáng kính là một câu nói thực tế của Douglas Crockford, Ngôn ngữ JavaScript có một số phần thực sự tốt và một số phần thực sự xấu. Dưới đây là những phần tốt. Chỉ cần quên rằng có bất cứ điều gì khác là có. Có lẽ hệ sinh thái Node.js nóng bỏng sẽ phát triển chính Douglas Douglas Crockford, người sẽ nói, hệ sinh thái Node.js là một miền Tây hoang dã mã hóa, nhưng có một số đá quý thực sự được tìm thấy. Đây là một lộ trình. Dưới đây là những lĩnh vực cần tránh với hầu hết mọi chi phí. Dưới đây là các khu vực có một số khoản thanh toán phong phú nhất được tìm thấy trong bất kỳ ngôn ngữ hoặc môi trường nào.

Có lẽ ai đó khác có thể coi những từ đó là một thách thức, và đi theo sự dẫn dắt của Crockford và viết lên những phần hay và một phần hay hơn cho các Node.js và hệ sinh thái của nó. Tôi sẽ mua một bản sao!

Và với mức độ nhiệt tình và thời gian làm việc tuyệt đối cho tất cả các dự án, nó có thể được bảo hành trong một hoặc hai hoặc ba năm để giảm bớt bất kỳ nhận xét nào về một hệ sinh thái chưa trưởng thành được thực hiện tại thời điểm viết bài này. Nó thực sự có thể có ý nghĩa trong năm năm để nói, hệ sinh thái Node.js 2015 có một số mỏ. Hệ sinh thái Node.js 2020 có nhiều thiên đường.


9

Nếu ứng dụng của bạn chủ yếu xử lý apis web hoặc các kênh io khác, cung cấp hoặc lấy giao diện người dùng, thì node.js có thể là một lựa chọn hợp lý cho bạn, đặc biệt nếu bạn muốn loại bỏ khả năng mở rộng nhất hoặc, nếu ngôn ngữ chính của bạn trong cuộc sống là javascript (hoặc bộ chuyển đổi javascript của các loại). Nếu bạn xây dựng microservice, node.js cũng không sao. Node.js cũng phù hợp cho bất kỳ dự án nào nhỏ hoặc đơn giản.

Điểm bán hàng chính của nó là cho phép những người đi trước chịu trách nhiệm về những thứ phụ trợ hơn là sự phân chia thông thường. Một điểm bán hàng chính đáng khác là nếu lực lượng lao động của bạn được định hướng javascript để bắt đầu.

Tuy nhiên, vượt quá một điểm nhất định, bạn không thể mở rộng quy mô mã của mình mà không bị hack khủng khiếp để buộc tính mô đun, khả năng đọc và kiểm soát luồng. Một số người thích những bản hack đó, đặc biệt là đến từ nền javascript hướng sự kiện, họ có vẻ quen thuộc hoặc dễ tha thứ.

Đặc biệt, khi ứng dụng của bạn cần thực hiện các luồng đồng bộ, bạn bắt đầu chảy máu trên các giải pháp nửa nướng, làm chậm đáng kể về quy trình phát triển của bạn. Nếu bạn có các phần chuyên sâu tính toán trong ứng dụng của mình, hãy cẩn thận chọn (chỉ) node.js. Có thể http://koajs.com/ hoặc các tiểu thuyết khác làm giảm bớt các khía cạnh gai góc ban đầu, so với khi ban đầu tôi sử dụng node.js hoặc viết bài này.


3
Có nhiều cách tiếp cận hiện có để nhân rộng các ứng dụng Node.js và bạn dường như không cung cấp bất kỳ tài liệu tham khảo nào liên quan đến "các giải pháp nửa nướng", "hack khủng khiếp" và "API khủng khiếp". Tâm mở rộng về những điều đó?
Sven Slootweg

Tôi để nó như một bài tập cho người đọc, nhưng nó đủ để xem xét các giải pháp được gọi là kiểm soát dòng chảy.
matanster

2
Đó không thực sự là một câu trả lời. Bạn cho rằng các giải pháp hiện tại là "những vụ hack khủng khiếp", nhưng không thể chỉ ra bất kỳ giải pháp nào trong số đó. Bạn đã từng nghĩ rằng bạn có thể đơn giản là không hiểu hoặc không biết các phương thức chính xác để nhân rộng các ứng dụng Node.js?
Sven Slootweg

Tôi cập nhật câu trả lời của tôi một chút. Có thể bạn vẫn còn phàn nàn, nhưng nếu bạn nghĩ đó là sai, bạn nên bình luận với các chi tiết ... thay vì chỉ ra sự thiếu sót trong câu trả lời. Điều đó sẽ hiệu quả hơn cho cộng đồng imo.
matanster 18/03/2015

-2

Tôi có thể chia sẻ một vài điểm trong đó & tại sao nên sử dụng nút js.

  1. Đối với các ứng dụng thời gian thực như trò chuyện, chỉnh sửa cộng tác tốt hơn, chúng tôi sử dụng nodejs vì đây là cơ sở sự kiện nơi thực hiện sự kiện và dữ liệu cho khách hàng từ máy chủ.
  2. Đơn giản và dễ hiểu vì nó là cơ sở javascript, nơi hầu hết mọi người có ý tưởng.
  3. Hầu hết các ứng dụng web hiện tại đều hướng tới js & xương sống góc cạnh, với nút rất dễ tương tác với mã phía máy khách vì cả hai sẽ sử dụng dữ liệu json.
  4. Rất nhiều plugin có sẵn.

Hạn chế: -

  1. Node sẽ hỗ trợ hầu hết các cơ sở dữ liệu nhưng tốt nhất là mongodb không hỗ trợ các phép nối phức tạp và các cơ sở dữ liệu khác.
  2. Lỗi biên dịch ... nhà phát triển nên xử lý từng trường hợp ngoại lệ khác nếu ứng dụng phù hợp với lỗi sẽ ngừng hoạt động khi chúng ta cần phải khởi động lại bằng tay hoặc sử dụng bất kỳ công cụ tự động hóa nào.

Kết luận: - Nodejs tốt nhất để sử dụng cho các ứng dụng đơn giản và thời gian thực..nếu bạn có logic kinh doanh rất lớn và chức năng phức tạp tốt hơn không nên sử dụng nodejs. Nếu bạn muốn xây dựng một ứng dụng cùng với trò chuyện và bất kỳ chức năng hợp tác nào .. nút có thể được sử dụng trong các phần cụ thể và vẫn phải đi với công nghệ tiện lợi của bạn.


-3
  1. Nút là tuyệt vời cho các nguyên mẫu nhanh chóng nhưng tôi sẽ không bao giờ sử dụng nó cho bất cứ điều gì phức tạp. Tôi đã dành 20 năm để phát triển mối quan hệ với một trình biên dịch và tôi chắc chắn bỏ lỡ nó.

  2. Nút đặc biệt đau đớn khi duy trì mã mà bạn chưa truy cập trong một thời gian. Loại thông tin và phát hiện lỗi thời gian biên dịch là những điều TỐT. Tại sao lại ném tất cả những thứ đó ra? Để làm gì? Và dang, khi một cái gì đó đi về phía nam, dấu vết ngăn xếp khá thường xuyên hoàn toàn vô dụng.


2
Mặc dù bạn không được kiểm tra thời gian biên dịch, JSDoc cho phép bạn thêm bất kỳ loại thông tin nào bạn muốn để mọi thứ trở nên có ý nghĩa hơn khi bạn quay lại. Các hàm phân rã (nhỏ) đúng cách cũng thường khá dễ bị mò mẫm do môi trường được xác định rõ (đóng). Dấu vết ngăn xếp xấu thường có thể được giải quyết bằng một số bao thanh toán lại để đảm bảo bạn không phân tách logic của mình với một cuộc gọi lại không đồng bộ ở giữa. Giữ các cuộc gọi lại không đồng bộ của bạn trong cùng một bao đóng giúp bạn dễ dàng suy luận và duy trì.
Rich Remer

2
Tôi đã dành 30 năm với các ngôn ngữ được biên dịch, nhưng sau khi sử dụng nó chỉ khoảng một năm, giờ đây JavaScript là ngôn ngữ tôi chọn. Nó rất hiệu quả - Tôi có thể làm được nhiều hơn với mã ít hơn nhiều so với Java C # C ++ hoặc C. Nhưng đó là một suy nghĩ khác. Biến không gõ thực sự là một lợi thế trong nhiều trường hợp. JSLINT là điều cần thiết. Khi bạn cần thực hiện đồng thời các cuộc gọi lại không đồng bộ sẽ an toàn hơn, dễ dàng hơn và cuối cùng hiệu quả hơn bất kỳ ngôn ngữ nào mà bạn phải sử dụng chuỗi. Và dù sao bạn cũng phải biết JavaScript vì đó là ngôn ngữ của trình duyệt.
James

Tôi đồng cảm với những lo ngại nêu ra, và tôi lưu ý rằng một số nỗ lực đã được thực hiện để giải quyết chúng, mặc dù chúng chắc chắn không được áp dụng phổ biến. Có một dự án tuyệt vời tên là Tern có thể cung cấp dẫn xuất kiểu từ phân tích tĩnh mã Javascript và thư viện. Nó có plugin cho các biên tập viên khác nhau. Ngoài ra còn có Bản in, JSDoc và BetterJS . Và sau đó là Go , một trong nhiều ngôn ngữ biên dịch thành Javascript !
joeytwiddle
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.