Sử dụng bộ nhớ javascript

Nút. js tỏa sáng trong các ứng dụng web thời gian thực sử dụng công nghệ đẩy qua WebSocket. Các kết nối hai chiều, thời gian thực của nút—nơi mỗi máy khách và máy chủ có thể bắt đầu giao tiếp—cho phép trao đổi dữ liệu tự do hơn

Nội dung chính Show

nút là gì. js?
Why Use Node. js?
Nút như thế nào. js Work?
npm. Trình quản lý gói nút
Nơi sử dụng nút. js
Trò chuyện
API trên đầu DB đối tượng
Đầu vào xếp hàng
Truyền dữ liệu
Ủy quyền
Môi giới/Bảng điều khiển của nhà giao dịch chứng khoán
Bảng điều khiển giám sát ứng dụng
Bảng điều khiển giám sát hệ thống
Nơi sử dụng nút. js, nhưng thận trọng
Ứng dụng web phía máy chủ
Nơi không sử dụng nút. js
Ứng dụng web phía máy chủ với ứng dụng cơ sở dữ liệu quan hệ
Xử lý và/hoặc tính toán phía máy chủ nặng
Tại sao chọn nút. js?
Hiểu những điều cơ bản
nút là gì. js?
nút là gì. js dùng để làm gì?
một khuôn khổ web là gì?
là nút. js là một khuôn khổ?
là nút. js một ngôn ngữ lập trình?
Tại sao là nút. js phổ biến?
Sự khác biệt giữa nút là gì. js và Góc/AngularJS?
Tại sao là nút. js xấu?
Bình luận

Qua

Tomislav Capan

Tomislav là Kiến trúc sư giải pháp, nhà phát triển và tư vấn kỹ thuật được AWS chứng nhận với hơn 10 năm kinh nghiệm. Tomislav có bằng thạc sĩ về máy tính

CHIA SẺ

Đọc bản tiếng Tây Ban Nha

của bài viết này do Isabella Rolz dịch

Ghi chú của biên tập viên. Phiên bản tiếng Anh của bài viết này đã được cập nhật vào ngày 10/03/2022 bởi nhóm biên tập của chúng tôi. Nó đã được sửa đổi để bao gồm các nguồn gần đây và phù hợp với các tiêu chuẩn biên tập hiện tại của chúng tôi

Sự phổ biến của JavaScript đã kéo theo rất nhiều thay đổi. Những điều chúng ta làm trên web ngày nay thật khó tưởng tượng chỉ vài năm trước

Trước khi chúng tôi tìm hiểu về Node. js (“Node”), hãy xem xét việc áp dụng JavaScript trên toàn bộ ngăn xếp để thống nhất ngôn ngữ và định dạng dữ liệu (JSON), sẽ tạo điều kiện thuận lợi cho việc sử dụng lại tài nguyên của nhà phát triển một cách tối ưu. Vì đây là một lợi ích của JavaScript hơn là Node. js cụ thể, chúng tôi sẽ không giải thích thêm

Với tất cả những ưu điểm của mình, Node. js đóng một vai trò quan trọng trong kho công nghệ của nhiều công ty nổi tiếng, những người phụ thuộc vào lợi ích độc đáo của nó. nút này. js giải quyết cách nhận ra những lợi thế này và lý do tại sao bạn có thể—hoặc có thể không—sử dụng Node. js

nút là gì. js?

Nút. js bao gồm công cụ JavaScript V8 của Google, lớp trừu tượng nền tảng libUV và thư viện cốt lõi được viết bằng JavaScript. Ngoài ra, Nút. js dựa trên ngăn xếp web mở (HTML, CSS và JS) và hoạt động trên cổng tiêu chuẩn 80

Node. js provides developers a comprehensive tool for working in the non-blocking, event-driven I/O paradigm. Ryan Dahl, the creator of Node. js was “inspired by applications like Gmail” and—in creating Node. js—aimed to create real-time websites with push capability

After over 20 years of stateless-web based on the stateless request-response paradigm, we finally have web applications with real-time, two-way connections

Why Use Node. js?

Node. js shines in real-time web applications employing push technology over WebSocket. After over 20 years of stateless-web based on the stateless request-response paradigm, we finally have web applications with real-time, two-way connections, where both the client and server can initiate communication, allowing them to exchange data more freely. This is in stark contrast to the typical web response paradigm, where the client always initiates communication

One might argue that we’ve had this technology for years in the form of Flash and Java Applets. In reality, however, those were just sandboxed environments that used the web as a transport protocol to be delivered to the client. Plus, Flash and Java Applets were run in isolation and often operated over nonstandard ports, which may have required extra permissions

Nút như thế nào. js Work?

Node really shines in building fast, scalable network applications. Điều này là do khả năng xử lý một số lượng lớn các kết nối đồng thời với thông lượng cao

Nút. js sử dụng I/O không chặn, theo sự kiện để duy trì trọng lượng nhẹ và hiệu quả khi đối mặt với các ứng dụng thời gian thực sử dụng nhiều dữ liệu chạy trên các thiết bị phân tán

Nút. js là một nền tảng đáp ứng một nhu cầu cụ thể và hiểu điều này là vô cùng cần thiết. Ví dụ, bạn sẽ không sử dụng Node. js để thực hiện các hoạt động sử dụng nhiều CPU. Gần như tất cả các lợi thế của Node sẽ bị hủy bỏ nếu nó được sử dụng để tính toán nặng

Nút. js là một nền tảng đáp ứng nhu cầu cụ thể. Nó không phải là viên đạn bạc hay nền tảng sẽ thống trị thế giới phát triển web

tiếng riu ríu

Làm thế nào nút. js hoạt động bí mật thật thú vị. So với các kỹ thuật phục vụ web truyền thống trong đó mỗi kết nối (yêu cầu) tạo ra một luồng mới (chiếm RAM hệ thống và cuối cùng sử dụng tối đa dung lượng RAM có sẵn), Node. js hoạt động trên một luồng đơn, sử dụng lệnh gọi I/O không chặn. Điều này cho phép Node hỗ trợ hàng chục nghìn kết nối đồng thời được tổ chức trong vòng lặp sự kiện

Theo bài viết năm 2011 của Michael Abernethy “Node là gì. js?”, lấy một chuỗi có bộ nhớ 2 MB đi kèm, chạy trên hệ thống có RAM 8 GB và cung cấp tối đa theo lý thuyết là 4.000 kết nối đồng thời. Thêm vào đó là chi phí chuyển đổi ngữ cảnh giữa các luồng và bạn sẽ có một kịch bản phổ biến trong các kỹ thuật phục vụ web truyền thống. Nút. js tránh được tất cả điều này, đạt được mức khả năng mở rộng cao

Tất nhiên, có câu hỏi về việc chia sẻ một luồng duy nhất trong số tất cả các yêu cầu của khách hàng, một cạm bẫy tiềm ẩn khi viết Node. ứng dụng js

Đầu tiên, tính toán nặng nề có thể làm tắc nghẽn luồng đơn của Node và gây ra sự cố cho tất cả các máy khách, vì các yêu cầu đến bị chặn cho đến khi quá trình tính toán nói trên hoàn tất

Thứ hai, các nhà phát triển cần cảnh giác và ngăn chặn các ngoại lệ xuất hiện ở nút lõi (trên cùng). js, vì điều này sẽ khiến Node. js để chấm dứt, làm hỏng chương trình một cách hiệu quả

Để ngăn dòng ngoại lệ, chúng tôi chuyển lỗi trở lại trình gọi dưới dạng tham số gọi lại (thay vì "ném", như chúng tôi làm trong một số môi trường khác). Nếu một ngoại lệ chưa được xử lý xuất hiện, chúng ta có thể sử dụng mô-đun Forever hoặc các công cụ bên ngoài như upstart và monit và just upstart để theo dõi Nút. js và thực hiện khôi phục cần thiết cho một phiên bản bị lỗi. Lưu ý rằng những công cụ này không giải quyết việc khôi phục trạng thái hiện tại của phiên người dùng

npm. Trình quản lý gói nút

Hỗ trợ tích hợp để quản lý gói bằng npm được bao gồm trong mọi Nút. cài đặt js. Ý tưởng đằng sau các mô-đun npm tương tự như ý tưởng của Ruby Gems. Nó là một tập hợp các thành phần có sẵn công khai, có thể tái sử dụng, dễ dàng cài đặt thông qua kho lưu trữ trực tuyến, với quản lý phiên bản và phụ thuộc

npm Inc. chia sẻ danh sách các mô-đun được đóng gói cũng có thể truy cập thông qua công cụ npm CLI của nó. Hệ sinh thái mô-đun mở cho tất cả mọi người xuất bản mô-đun của riêng họ, mô-đun này sẽ được thêm vào kho lưu trữ npm

Một số mô-đun npm hữu ích bao gồm

thể hiện, thể hiện. js hoặc đơn giản là Express

Khung phát triển web lấy cảm hứng từ Sinatra cho Node. js và tiêu chuẩn thực tế cho phần lớn Node. ứng dụng js

hapi

Khung tập trung vào cấu hình mô-đun và dễ sử dụng để xây dựng các ứng dụng web và dịch vụ

liên kết

Khung máy chủ HTTP có thể mở rộng cho Node. js, cung cấp một tập hợp các plugin hiệu suất cao được gọi là phần mềm trung gian;

ổ cắm. io và sockjs

Một thành phần phía máy chủ của hai thành phần WebSocket phổ biến

pug (trước đây là Jade)

Công cụ tạo khuôn mẫu lấy cảm hứng từ HAML, mặc định trong Express. js

mongodb và mongojs

Trình bao bọc MongoDB để cung cấp API cho cơ sở dữ liệu đối tượng MongoDB trong Node. js

làm lại

Thư viện máy khách Redis

lodash, gạch dưới, lười biếng. js

Vành đai tiện ích JavaScript. Underscore bắt đầu trò chơi nhưng bị lật đổ bởi một trong hai đối tác của nó, chủ yếu là do lười biếng. js' hiệu suất tốt hơn và triển khai mô-đun

mãi mãi

Một tiện ích để đảm bảo rằng tập lệnh nút đã cho chạy liên tục; . js xử lý trong quá trình sản xuất khi đối mặt với bất kỳ lỗi không mong muốn nào

chim xanh

Triển khai Promise/A+ đầy đủ tính năng với hiệu suất đặc biệt tốt

chốc lát. js

Thư viện ngày JavaScript để phân tích cú pháp, xác thực, thao tác và định dạng ngày

Nơi sử dụng nút. js

Trò chuyện

Trò chuyện là một ứng dụng nhiều người dùng, thời gian thực điển hình—từ IRC (trước đây)—đến các triển khai hiện đại trong Node. js với WebSocket

Ứng dụng trò chuyện nhẹ, lưu lượng truy cập cao và sử dụng nhiều dữ liệu (nhưng khả năng xử lý/tính toán thấp). Nó chạy trên các thiết bị phân tán và là ví dụ điển hình cho Node. js

Đơn giản, nhưng bao gồm hầu hết các mô hình mà bạn sẽ sử dụng trong một Nút điển hình. js, trò chuyện là một trường hợp sử dụng tuyệt vời cho việc học

Hãy mô tả cách trò chuyện hoạt động. Giả sử chúng tôi có một phòng trò chuyện duy nhất nơi người dùng có thể trao đổi tin nhắn theo kiểu một-nhiều (thực tế là tất cả). Cũng giả sử có ba người dùng được kết nối với bảng tin của chúng tôi

Về phía máy chủ, một Express đơn giản. triển khai ứng dụng js

Trình xử lý yêu cầu GET / phục vụ trang web chứa bảng tin và nút 'Gửi' để khởi tạo đầu vào tin nhắn mới và
Máy chủ WebSocket lắng nghe các tin nhắn mới do máy khách WebSocket phát ra

Về phía khách hàng, chúng tôi có một trang HTML với một số trình xử lý được thiết lập

Trình xử lý cho sự kiện nhấp vào nút 'Gửi', nhận thông báo đầu vào và gửi nó xuống WebSocket
Trình xử lý lắng nghe các tin nhắn đến mới trên máy khách WebSocket (i. e. , thông báo do người dùng tạo mà máy chủ muốn máy khách hiển thị)

Khi một khách hàng đăng một tin nhắn, đây là những gì sẽ xảy ra

Trình duyệt bắt nút 'Gửi' khi nhấp qua trình xử lý JavaScript. Nó chọn giá trị từ trường đầu vào (i. e. , văn bản tin nhắn) và phát ra một tin nhắn WebSocket bằng ứng dụng khách WebSocket được kết nối với máy chủ của chúng tôi (được khởi tạo khi khởi tạo trang web)
Thành phần phía máy chủ của kết nối WebSocket nhận tin nhắn và chuyển tiếp nó tới tất cả các máy khách được kết nối khác, sử dụng phương thức quảng bá
Tất cả máy khách nhận được tin nhắn mới dưới dạng tin nhắn đẩy, thông qua thành phần phía máy khách WebSocket chạy trong trang web. Sau đó, khách hàng chọn nội dung tin nhắn và cập nhật trang web tại chỗ, bằng cách thêm tin nhắn mới vào bảng

Client and Server WebSockets in a Node.js Application

Đây là một ví dụ đơn giản về trò chuyện thời gian thực với NodeJS, Socket. io và ExpressJS

Để có giải pháp hiệu quả hơn, bạn có thể sử dụng bộ đệm đơn giản dựa trên cửa hàng Redis. Hoặc trong một giải pháp nâng cao hơn nữa, hãy sử dụng hàng đợi tin nhắn để xử lý việc định tuyến tin nhắn đến máy khách và cơ chế phân phối mạnh mẽ hơn. Hàng đợi có thể bao gồm mất kết nối tạm thời hoặc lưu trữ tin nhắn cho khách hàng đã đăng ký khi họ ngoại tuyến

Bất kể giải pháp bạn chọn là gì, Node. js hoạt động theo các nguyên tắc cơ bản giống nhau. phản ứng với các sự kiện, xử lý nhiều kết nối đồng thời và duy trì tính trôi chảy trong trải nghiệm người dùng

API trên đầu DB đối tượng

Nút. js là sự phù hợp tự nhiên để hiển thị dữ liệu từ các DB đối tượng (e. g. , MongoDB). Dữ liệu được lưu trữ JSON cho phép Node. js hoạt động mà không có trở kháng không phù hợp và chuyển đổi dữ liệu

Chẳng hạn, nếu bạn đang sử dụng Rails, bạn sẽ chuyển đổi từ JSON sang mô hình nhị phân, sau đó hiển thị chúng trở lại dưới dạng JSON qua HTTP khi dữ liệu được sử dụng bởi Backbone. js, góc cạnh. js, v.v. —hoặc thậm chí các cuộc gọi jQuery AJAX đơn giản. với nút. js, bạn có thể hiển thị các đối tượng JSON bằng API REST để máy khách sử dụng

Nếu bạn đang sử dụng MongoDB, bạn không cần lo lắng về việc chuyển đổi giữa JSON và bất kỳ thứ gì khác khi đọc hoặc ghi từ cơ sở dữ liệu. Do đó, bạn có thể tránh nhu cầu chuyển đổi nhiều lần bằng cách sử dụng định dạng tuần tự hóa dữ liệu thống nhất trên máy khách, máy chủ và cơ sở dữ liệu

Đầu vào xếp hàng

Nút cho phép bạn linh hoạt đẩy việc xóa sổ cơ sở dữ liệu sang một bên. Nhưng thậm chí còn có nhiều lý do hơn để sử dụng Node. js

Nếu bạn đang nhận một lượng lớn dữ liệu đồng thời, cơ sở dữ liệu của bạn có thể trở thành nút cổ chai. Nút. js có thể dễ dàng xử lý các kết nối đồng thời. Bởi vì—trong trường hợp này—việc truy cập cơ sở dữ liệu là một thao tác ngăn chặn, nên chúng tôi gặp rắc rối. Giải pháp là thừa nhận hành vi của khách hàng trước khi dữ liệu thực sự được ghi vào cơ sở dữ liệu

Cách tiếp cận này cho phép hệ thống duy trì khả năng phản hồi khi tải nặng. Tính năng này đặc biệt hữu ích khi khách hàng không yêu cầu xác nhận chắc chắn về việc ghi dữ liệu thành công, khi ghi nhật ký hoặc ghi dữ liệu theo dõi người dùng, được xử lý theo lô, để sử dụng sau này hoặc cho các hoạt động không cần thiết

Dữ liệu được xếp hàng đợi thông qua một số loại bộ nhớ đệm hoặc cơ sở hạ tầng xếp hàng tin nhắn như RabbitMQ hoặc ZeroMQ. Sau đó, nó được tiêu hóa bởi một quy trình ghi hàng loạt cơ sở dữ liệu riêng biệt hoặc dịch vụ phụ trợ xử lý tính toán chuyên sâu, được viết trên một nền tảng hoạt động tốt hơn cho tác vụ như vậy

Database Batch-write in Node.js With Message Queuing.

Nói ngắn gọn. Với Node, bạn có thể đẩy việc ghi cơ sở dữ liệu sang một bên để xử lý sau

Truyền dữ liệu

Tại sao không sử dụng Nút. js trong truyền dữ liệu? . Chúng ta có thể sử dụng quan sát này để xây dựng một số Node thú vị. tính năng js

Ví dụ: chúng tôi có thể xử lý tệp trong khi chúng vẫn đang được tải lên. Khi dữ liệu đến qua một luồng, chúng tôi có thể xử lý dữ liệu song song trong quá trình tải lên đó. Điều này đúng với mã hóa âm thanh hoặc video thời gian thực và ủy quyền giữa các nguồn dữ liệu khác nhau

Ủy quyền

Nút. js dễ dàng được sử dụng làm proxy phía máy chủ, nơi nó có thể xử lý một lượng lớn kết nối đồng thời theo cách không chặn. Nó hữu ích cho việc ủy quyền các dịch vụ khác nhau với thời gian phản hồi khác nhau hoặc thu thập dữ liệu từ nhiều điểm nguồn

Ví dụ: hãy xem xét ứng dụng phía máy chủ giao tiếp với tài nguyên của bên thứ ba, lấy dữ liệu từ các nguồn khác nhau hoặc lưu trữ nội dung (như hình ảnh và video) vào dịch vụ đám mây của bên thứ ba

Sử dụng Nút thay cho máy chủ proxy chuyên dụng có thể hữu ích nếu cơ sở hạ tầng ủy quyền của bạn không tồn tại hoặc nếu bạn cần một giải pháp để phát triển cục bộ. Bằng cách này, ý tôi là bạn có thể xây dựng ứng dụng phía máy khách bằng Node. máy chủ phát triển js cho nội dung và yêu cầu ủy quyền/sơ khai API. Trong sản xuất, bạn sẽ xử lý các tương tác như vậy với dịch vụ proxy chuyên dụng (như nginx hoặc HAProxy)

Môi giới/Bảng điều khiển của nhà giao dịch chứng khoán

Ở cấp độ ứng dụng, phần mềm giao dịch của nhà môi giới là một ví dụ khác trong đó phần mềm máy tính chiếm ưu thế, nhưng có thể dễ dàng thay thế bằng giải pháp web thời gian thực. Phần mềm giao dịch của nhà môi giới theo dõi giá cổ phiếu, thực hiện tính toán và phân tích kỹ thuật, đồng thời hiển thị đồ thị và biểu đồ

Tại sao không sử dụng Nút. js để viết một giải pháp dựa trên web thời gian thực cho các nhà môi giới? . Chúng tôi có thể sớm gặp các nhà môi giới của mình trên bãi biển ở Florida hoặc Ibiza hoặc Bali

Bảng điều khiển giám sát ứng dụng

Hãy tưởng tượng bạn có thể phát triển doanh nghiệp của mình như thế nào nếu bạn có thể thấy khách truy cập của mình đang làm gì trong thời gian thực. Với ổ cắm hai chiều, thời gian thực của Node, bạn có thể đạt được khả năng này

Nút với WebSocket hoàn toàn phù hợp để theo dõi khách truy cập trang web và trực quan hóa các tương tác của họ trong thời gian thực

Lý do nên sử dụng Nút. js cho bảng điều khiển giám sát bao gồm thu thập số liệu thống kê theo thời gian thực từ người dùng hoặc giới thiệu các tương tác được nhắm mục tiêu với khách truy cập của bạn bằng cách mở kênh liên lạc tại một điểm cụ thể trong kênh của bạn. CANDDi sản xuất ý tưởng này

Bảng điều khiển giám sát hệ thống

Bây giờ, hãy đến thăm khía cạnh cơ sở hạ tầng của mọi thứ. Ví dụ, hãy tưởng tượng một nhà cung cấp SaaS muốn cung cấp cho người dùng một trang giám sát dịch vụ, như trang trạng thái của GitHub. với nút. js, chúng ta có thể tạo một bảng điều khiển dựa trên web mạnh mẽ để kiểm tra trạng thái của dịch vụ theo cách không đồng bộ, đẩy dữ liệu đến máy khách bằng WebSocket

Cả trạng thái nội bộ (nội bộ công ty) và dịch vụ công cộng đều có thể được báo cáo trực tiếp và theo thời gian thực bằng cách sử dụng công nghệ này. Đẩy xa hơn một chút và thử tưởng tượng một trung tâm điều hành mạng (NOC) giám sát các ứng dụng của nhà điều hành viễn thông, nhà cung cấp dịch vụ đám mây/mạng/lưu trữ hoặc một số tổ chức tài chính. Các ứng dụng sẽ chạy trên ngăn xếp web mở được hỗ trợ bởi Node. js và WebSocket

Đừng cố xây dựng các hệ thống thời gian thực cứng trong Node (tôi. e. , hệ thống yêu cầu thời gian phản hồi nhất quán). Erlang có lẽ là lựa chọn tốt hơn cho loại ứng dụng đó

Nơi sử dụng nút. js, nhưng thận trọng

Ứng dụng web phía máy chủ

với nút. js với Express. js, bạn có thể tạo các ứng dụng web cổ điển ở phía máy chủ. Trong khi có thể, mô hình phản hồi yêu cầu này trong đó Nút. js sẽ mang HTML được kết xuất không phải là trường hợp sử dụng lý tưởng. Có những lập luận được đưa ra để ủng hộ và chống lại cách tiếp cận này. Dưới đây là một số sự thật để xem xét

ưu

Bạn có thể dễ dàng phát triển một ứng dụng không yêu cầu tính toán nhiều CPU, bằng cách sử dụng Javascript để xây dựng ứng dụng đó từ trên xuống dưới, thậm chí xuống cấp cơ sở dữ liệu—nếu bạn sử dụng Cơ sở dữ liệu đối tượng lưu trữ JSON (e. g. , MongoDB)
Trình thu thập thông tin nhận được phản hồi HTML được hiển thị đầy đủ, thân thiện với SEO hơn nhiều so với Ứng dụng một trang hoặc ứng dụng WebSocket chạy trên Nút. js

Nhược điểm

Mọi tính toán sử dụng nhiều CPU sẽ chặn Node. js, vì vậy một nền tảng luồng là một cách tiếp cận tốt hơn. Ngoài ra, bạn có thể thử nhân rộng tính toán
Sử dụng nút. js với cơ sở dữ liệu quan hệ có thể gây khó khăn. Nếu bạn đang cố gắng thực hiện các thao tác quan hệ, hãy cân nhắc sử dụng một môi trường như Rails, Django hoặc ASP. mạng MVC

Một giải pháp thay thế cho các tính toán sử dụng nhiều CPU là tạo ra một môi trường được hỗ trợ bởi MQ có khả năng mở rộng cao với quá trình xử lý phía sau để giữ Node làm “thư ký” phía trước để xử lý các yêu cầu của khách hàng một cách không đồng bộ

Nơi không sử dụng nút. js

There are situations where Node may not be the best tool for the job

Ứng dụng web phía máy chủ với ứng dụng cơ sở dữ liệu quan hệ

Ruby on Rails was once the clear choice as a tool to access relational databases like PostgreSQL, MySQL, and Microsoft SQL Server. This was because relational DB tools for Node. js vẫn đang ở giai đoạn đầu, ngược lại, Rails đã tự động cung cấp thiết lập truy cập dữ liệu ngay lập tức, cùng với các công cụ hỗ trợ di chuyển lược đồ DB và các Viên ngọc khác (ý định chơi chữ). Rails và các khung ngang hàng của nó đã triển khai lớp truy cập dữ liệu Active Record hoặc Data Mapper hoàn thiện và đã được chứng minh

Có thể và không có gì lạ khi chỉ sử dụng Node ở giao diện người dùng, trong khi vẫn giữ cho Rails của bạn ở mặt sau với khả năng truy cập dễ dàng vào DB quan hệ

But things have changed. Sequelize, TypeORM, and Bookshelf have come a long way toward becoming mature ORM solutions. Cũng có thể đáng để xem Tham gia Quái vật nếu bạn đang muốn tạo SQL từ các truy vấn GraphQL

Xử lý và/hoặc tính toán phía máy chủ nặng

Nút. js không phải là nền tảng tốt nhất để xử lý tính toán nặng. Không, bạn chắc chắn không muốn xây dựng máy chủ tính toán Fibonacci trong Node. js

Nói chung, bất kỳ hoạt động sử dụng nhiều CPU nào cũng loại bỏ tất cả các lợi ích về thông lượng mà Node mang lại với mô hình I/O không chặn, hướng sự kiện của nó. This is because incoming requests are blocked while the thread is occupied with your number-crunching—assuming you’re trying to run computations in the same Node instance used to respond to requests

Kể từ nút. js là một luồng và chỉ sử dụng một lõi CPU duy nhất, nó sẽ đòi hỏi nỗ lực đáng kể để phát triển một mô-đun cụm nhằm cung cấp đồng thời trên một máy chủ đa lõi. Alternatively, you can run several Node. js khá dễ dàng đằng sau một proxy ngược thông qua nginx

Với phân cụm, bạn vẫn nên giảm tải tất cả tính toán nặng nề cho các quy trình nền. Đảm bảo rằng bạn sử dụng môi trường thích hợp cho các quy trình nền và chúng giao tiếp qua máy chủ hàng đợi tin nhắn như RabbitMQ

Mặc dù bạn có thể chạy các quy trình nền trên máy chủ chính, phương pháp này có thể không mở rộng tốt khi tải tăng. Bạn có thể phân phối các dịch vụ xử lý nền cho các máy chủ worker riêng biệt mà không cần phải định cấu hình tải của các máy chủ web phía trước

với nút. js—trái ngược với hầu hết các nền tảng khác—bạn tận hưởng thông lượng yêu cầu/giây cao mà chúng tôi đã đề cập, vì mỗi yêu cầu là một nhiệm vụ nhỏ mà Node xử lý nhanh chóng và hiệu quả

Tại sao chọn nút. js?

Chúng tôi đã thảo luận về Nút. js từ lý thuyết đến thực hành, bắt đầu với mục đích của nó và kết thúc với những điểm hấp dẫn và cạm bẫy của nó

Các vấn đề với Node hầu như luôn bắt nguồn từ thực tế là các hoạt động ngăn chặn là gốc rễ của mọi tội ác—và 99% việc lạm dụng Node là hậu quả trực tiếp

Trong Node, các hoạt động ngăn chặn là gốc rễ của mọi tội ác—99% việc lạm dụng Node là hậu quả trực tiếp

tiếng riu ríu

Nếu trường hợp sử dụng của bạn không chứa các hoạt động sử dụng nhiều CPU, cũng như không truy cập các tài nguyên bị chặn, thì bạn có thể khai thác các lợi ích của Node. js và tận hưởng các ứng dụng mạng nhanh và có thể mở rộng. Chào mừng bạn đến với web thời gian thực

Hiểu những điều cơ bản

nút là gì. js?

Nút. js là môi trường chạy JavaScript mã nguồn mở phía máy chủ. Nút sử dụng công cụ V8 của Google---libUV---để cung cấp khả năng tương thích đa nền tảng và thư viện cốt lõi. Đáng chú ý, nút. js không hiển thị đối tượng cửa sổ chung vì nó không chạy trong trình duyệt

nút là gì. js dùng để làm gì?

Bởi vì nút. js là một luồng, chúng tôi sử dụng nó chủ yếu cho các máy chủ hướng sự kiện, không chặn. Chúng ta cũng có thể sử dụng Nút. js cho các trang web truyền thống và dịch vụ API back-end, vì nó được thiết kế với kiến trúc dựa trên đẩy, thời gian thực

một khuôn khổ web là gì?

Các khung web như Angular và React là các thư viện giúp tổ chức và tạo mã mặt trước chạy trong trình duyệt web. Các khung web tái sử dụng mã cho các hoạt động chung, do đó giảm thời gian phát triển. Một số khung web là ngăn xếp đầy đủ

là nút. js là một khuôn khổ?

Không, nút. js là một môi trường. Các khung công tác back-end chạy trong Node. js. Các khung phổ biến, tương thích bao gồm Express. js (còn được gọi là Express) cho máy chủ HTTP và Socket. IO cho máy chủ WebSocket

là nút. js một ngôn ngữ lập trình?

Nút. js không phải là ngôn ngữ lập trình. Các ". js" ở cuối tên của nó cho biết JavaScript là ngôn ngữ lập trình được liên kết với nó. Bất cứ thứ gì có thể dịch sang JavaScript---như TypeScript, Haxe hoặc CoffeeScript---cũng có thể được sử dụng với Node. js

Tại sao là nút. js phổ biến?

Bên cạnh hiệu quả cao, Node. js phổ biến vì hệ sinh thái dựa trên JavaScript khổng lồ, năng động, mã nguồn mở của nó

Sự khác biệt giữa nút là gì. js và Góc/AngularJS?

nút. js thực thi mã JavaScript trên máy chủ, trong khi đó Angular là một khung JavaScript được thực thi trên máy khách (i. e. , trong trình duyệt web)

Tại sao là nút. js xấu?

Nút. js không tệ. Công nghệ của nó được sử dụng rộng rãi cho nhiều loại máy chủ. Tuy nhiên, vì là đơn luồng nên Node. js không lý tưởng cho các máy chủ web gấp đôi máy chủ tính toán---việc tính toán nặng như vậy sẽ cản trở khả năng phản hồi của máy chủ

Thẻ

JavaScript/Nút. js

Người làm việc tự do? Tìm công việc tiếp theo của bạn.

Công việc lập trình viên JavaScript

Xem thông tin đầy đủ

Tomislav Capan

Kiến trúc sư giải pháp đám mây và nhà phát triển chính

Giới thiệu về tác giả

Tomislav là kỹ sư phần mềm, nhà tư vấn kỹ thuật và kiến trúc sư giải pháp, người bắt đầu làm đối tác kỹ thuật cho một doanh nghiệp truyền thông trực tuyến, phát triển nó từ con số 0 lên hơn 100.000 độc giả hàng tháng. Sau nhiều năm làm việc trong lĩnh vực công nghệ phần mềm, giờ đây, anh ấy đảm nhận vai trò lãnh đạo kỹ thuật thông qua tư vấn và kiến trúc các giải pháp đám mây năng động, đáng tin cậy và có thể mở rộng để hỗ trợ tăng trưởng kinh doanh và tối ưu hóa các kiến trúc phức tạp bị trục trặc. Là người lãnh đạo cơ sở hạ tầng, anh ấy làm cho đám mây trở thành một nơi thân thiện

Thuê Tomislav

Bình luận

Chuột Anonymous

Đối với các DB quan hệ trên Nút, tôi thích http. // giá sáchjs. tổ chức/

Chuột Anonymous

Đối với các DB quan hệ trên Nút, tôi thích http. // giá sáchjs. tổ chức/

Adin Scannell

bài viết tuyệt vời. Tôi chắc chắn đồng ý rằng nút. js có một số trường hợp sử dụng thực sự hoàn toàn phù hợp. Tuy nhiên, tôi muốn bình luận về một điều mà tôi hơi khó chịu -- Tôi ước bạn không đối chiếu nó với một hệ thống "truyền thống" không tồn tại của người rơm trong "cách thức hoạt động". 1) Không có máy chủ nào tạo ra một luồng cho mỗi yêu cầu (họ sử dụng nhóm luồng hoặc nhóm xử lý). 2) Bạn nói "chi phí chuyển đổi ngữ cảnh" như thể nó chỉ áp dụng cho các chuỗi hệ điều hành. Các khung không gian người dùng cần được lưu và tải theo cùng một cách. Ngoài ra, hệ điều hành thực hiện điều đó với một vài hướng dẫn, tận dụng hỗ trợ chuyên biệt từ phần cứng - điều mà không gian người dùng không thể làm được. 3) Tương tự, luồng không gian người dùng (I. e. khung hoặc bao đóng nếu bạn không muốn nói về các luồng) lấy tài nguyên bộ nhớ giống như cách các luồng nhân thực hiện. Không phải mỗi luồng hệ thống đều được phân bổ giới hạn ngăn xếp đầy đủ, vì vậy đó là một phân tích không công bằng. Các hệ thống thông thường thường có hơn 4000 mà không đến gần nơi bạn đã chốt nó. 4) Vấn đề LỚN với đồng thời một luồng là thiếu tính song song. Chắc chắn, bạn có thể xử lý hàng nghìn yêu cầu mỗi giây, nhưng chỉ một CPU trên máy chủ 40 lõi của bạn sẽ thực hiện BẤT KỲ công việc nào. Dù sao đi nữa, tất cả những điều trên liên quan đến một đoạn khá nhỏ trong bài đăng xuất sắc của bạn. Nút không thực sự có lỗi về điều này, chỉ là có rất nhiều FUD xung quanh các luồng và quy trình mà mọi người thường sử dụng để biện minh cho các thiết kế điên rồ (và tránh các luồng khi chúng hoàn toàn là cách tiếp cận phù hợp cho phần lớn các tình huống)

Adin Scannell

Eric Elliott

Tất cả lời khuyên của bạn về các ứng dụng nặng tính toán không thể sai hơn. Chắc chắn rằng việc cố gắng tính toán nội tuyến nặng nề với chu kỳ phản hồi yêu cầu là một ý tưởng tồi, nhưng điều tương tự cũng có thể xảy ra với các môi trường luồng. Nếu bạn có các hoạt động bị ràng buộc bởi CPU, bạn nên xử lý chúng bằng worker process. JavaScript và đặc biệt là Node thực sự rất phù hợp để xử lý tính toán phân tán - đặc biệt là với sự hỗ trợ tốt cho lập trình kiểu chức năng. Nếu bạn viết thuật toán của mình bằng cách sử dụng các hàm thuần túy và phân phối khối lượng công việc cho nhân viên, bạn có thể dễ dàng phân phối khối lượng công việc của mình trên các cụm được nối mạng. Sự hỗ trợ tuyệt vời của Node cho kết nối mạng làm cho nó trở thành một môi trường lý tưởng cho cả các tác vụ điện toán và điều phối, đồng thời nó có tốc độ nhanh hơn Ruby ở cả hai khía cạnh

Eric Elliott

jim thomas

Rất hữu ích. Cảm ơn rất nhiều

jim thomas

Rất hữu ích. Cảm ơn rất nhiều

roland

Bạn chắc chắn không muốn chặn bất kỳ Node nào. js đang xử lý các yêu cầu của máy chủ, nhưng điều đó không có nghĩa là bạn không nên thực hiện các tính toán nặng nề đằng sau một Nút. máy chủ js. Miễn là quá trình thực hiện các tính toán nặng nề được sinh ra không đồng bộ từ quá trình máy chủ của bạn. Still you could end up blocking your Node. js process if you overdue it, but that is also true with the traditional threaded server

roland

Danny Machal

Điều này sẽ khiến tôi trở thành một kẻ mới lớn nhưng bạn có thể cho tôi một ví dụ về "hoạt động chặn" không?

Danny Machal

Điều này sẽ khiến tôi trở thành một kẻ mới lớn nhưng bạn có thể cho tôi một ví dụ về "hoạt động chặn" không?

irneb

Bất kỳ hệ thống hybrid như vậy? . Sử dụng nút. js to process a request by simply placing it onto a to-process queue, return a message to the client stating something like "calculating. ". Sau đó nút. js được tự do tiếp tục với yêu cầu tiếp theo. Sau đó, hàng đợi xử lý có thể được chạy qua bằng cách sử dụng một luồng khác biệt (hoặc thậm chí nhiều luồng). Khi những điều này hoàn thành, họ sẽ gửi kết quả của mình tới Node. js's queue which will then relay it back to the original client? Of course this means some ID key needs to accompany each item in this queue to ensure the correct data is returned to the correct client. Bất cứ điều gì như thế này có thể?

irneb

zivkovic_milan

Great article, thanks . )

zivkovic_milan

Great article, thanks . )

Gerd Jungbluth

Tomislav, cảm ơn vì bài viết rất hay và súc tích này. We 've been using MongoDB and Node. js (kết hợp với AngularJS cho phần hướng tới người dùng) hơn 2 năm nay và không thể tưởng tượng được sẽ có bao giờ quay lại Flash (sau 10 năm kinh nghiệm) hoặc JEE / RDMS. Vì vậy, nó chỉ còn một ngôn ngữ lập trình (JS), một định dạng dữ liệu (JSON) và một mô hình lập trình (Async), wow

Gerd Jungbluth

chad

Đó là lời giải thích tốt nhất hiện có về Node. js. Cuối cùng tôi đã hiểu rằng nó rất hữu ích (trong một số tình huống nhất định) và không chỉ là sự cường điệu. Cảm ơn rất nhiều điều này rất nhiều thông tin

chad

ellisgl

Nút hoạt động tốt với cơ sở dữ liệu quan hệ, chỉ cần không sử dụng ORM. SQL isn't that hard to learn. =)

ellisgl

Nút hoạt động tốt với cơ sở dữ liệu quan hệ, chỉ cần không sử dụng ORM. SQL isn't that hard to learn. =)

Tomislav Capan

True that, but I thought we as an industry got over the idea of writing all the SQL manually. Các công cụ rất tốt cho các hoạt động thông thường, các công cụ giúp bạn viết một số chi tiết cụ thể theo cách thủ công, nếu không sẽ giảm khả năng xảy ra lỗi và các vấn đề bảo mật (điều đó xảy ra với nhiều nhà phát triển cơ sở hơn cho dù chúng ta có muốn hay không)

Tomislav Capan

Hi Adin, let me comment back 1) same scenario happens, there's a limitid amount of threads serving limited amount of clients. 2/3) Phần trình bày tham chiếu cho thấy một số phép đo và con số, bạn có thể khá đúng về phần bên trong nhưng tổng quan sơ bộ chung vẫn là một so sánh chung về cách mọi thứ hoạt động giữa hai thế giới đó. 4) các tùy chọn song song hóa cũng được thảo luận trong bài viết - dưới dạng các quy trình công nhân nền hoặc một số quy trình nút phía sau proxy ngược hoặc với API phân cụm nút (vẫn đang trong Thử nghiệm, nhưng cuối cùng sẽ có). Cảm ơn những bình luận tuyệt vời và phản hồi chất lượng về bài viết với thông tin bổ sung đó, tôi đánh giá cao nó

Tomislav Capan

Yes, you can have multiple worker processes, even communicating through Message Queue (MQ). Những công nhân đó có thể là các quy trình Nút riêng biệt (vì nút là một luồng, trừ khi bạn thử nghiệm API phân cụm - Tôi chưa thử vì API còn rất sớm và có thể chưa hoàn thiện), nhưng có thể là bất kỳ ngôn ngữ nào khác. Tôi đã làm việc trên một hệ thống chạy C# trên Mono để xử lý nền trong kiến trúc CQRS phân tán

Tomislav Capan

Any calculation that keeps the CPU busy until the calculation is finished. Imagine some operation that requires 2 seconds to perform the calculation. Đạt được điều đó với 100 khách hàng - bạn nhận được độ trễ 200 giây. Note the article I have referenced, which explains the blocking of the event loop. http. //zef. me/4561/node-js-and-the-case-of-the-blocked-event-loop

Tomislav Capan

Vâng, điều đó thuộc ý tưởng có 'các quy trình công nhân phụ trợ' trong một hệ thống phân tán. Khi hệ thống được phân phối, những công nhân đó có thể sử dụng bất kỳ ngôn ngữ/nền tảng nào, kể cả Node

Tomislav Capan

Cảm ơn phản hồi của bạn. Tôi hoàn toàn đồng ý về điều đó, đối với các quy trình worker, bạn có thể sử dụng JS khi nó phù hợp và điều đó có nghĩa là Node. js as that's what runs JS on the server, but you can also use other languages that do the particular work at hand fast

Tomislav Capan

ellisgl

For ORMs in general, I just see them as a tool that can get something done quick for a newbie, but end up really gumming up the works later on. Thứ gần nhất tôi sử dụng cho ORM là trình bao bọc PDO (mà tôi đã mượn và viết lại từ một đồng nghiệp cũ), giúp viết các câu lệnh PDO. https. //github. com/ellisgl/GeekLab-XPDO

ellisgl

Adin Scannell

Lời xin lỗi cho bức tường của văn bản. thảo luận tuyệt vời. 1) Đồng ý. Nhưng luồng và quy trình là những công cụ mạnh mẽ. Đó là lý do tại sao sự kết hợp giữa luồng/quy trình và hệ thống sự kiện thường hoạt động tốt nhất trong thế giới thực. Giống như nginx rất được yêu thích. ) 2/3) Xin lỗi, có thể tôi chưa rõ. Khi tôi nói FUD liên quan đến luồng và quy trình, tôi *có nghĩa là bản trình bày được tham chiếu*. Nó chỉ là một loạt các tiêu chuẩn vi mô được điều chỉnh cụ thể được thiết kế để chứng minh một điểm nào đó. (Which is fair, given that it's a lightning fair and can be a bit polemic. Trên thực tế, đó là một cuộc nói chuyện tuyệt vời. Nhưng những điểm chuẩn vi mô tổng hợp này không phải là cơ sở để so sánh công bằng và thông qua. ) To say the difference between nginx and apache benchmarks is purely because of context switching is an extreme oversimplification. Nginx được thiết kế đặc biệt để phục vụ các yêu cầu HTTP thực sự, thực sự nhanh chóng trong các trường hợp thông thường (IMO thường bằng cách kết hợp chặt chẽ với các hệ thống sự kiện HĐH mới nhất, v.v. ). You could specifically measure the overhead of context switching, and I would wager it's trivial. 4) Nhưng sau đó, bạn không hài lòng với "chi phí xử lý" khủng khiếp mà bản trình bày được tham chiếu nói đến -- không thể có cả hai cách. ) (Nói rõ hơn, vị trí của tôi sử dụng các chủ đề/quy trình hoặc bất cứ thứ gì không nằm trong bản thân nó và là một vấn đề. There are way more important design factors there, the OS overhead of those entities is pretty trivial. Hence I hate it when people adopt a silly design based on the idea thread-are-bad or processes-are-bad or some other such nonesense)

Adin Scannell

Tomislav Capan

Everything always needs to be put in the right context. I have presented possible situations, to analyze each one deeply I'd need a book . -) Tuy nhiên, tôi thực sự đánh giá cao những nhận xét và hiểu biết của bạn, chúng là những bổ sung có giá trị cho bài viết. Cảm ơn vì những điều đó

Tomislav Capan

Aaron Wang

Khi sử dụng nút. js là máy chủ api và db back-end là nút cổ chai, nếu máy khách là các ứng dụng khác, không phải giao diện người dùng, chúng ta có thể để các yêu cầu máy khách này treo ở đó chờ hoạt động db hoàn tất không (nút hình sin. js có thể xử lý các kết nối đồng thời lớn một cách dễ dàng)? . js đúng hàng đợi

Aaron Wang

Ethan

ORM không tồn tại để làm cho các ngôn ngữ truy vấn trở nên "dễ dàng hơn", nó là một công cụ được sử dụng để đóng gói các mối quan tâm về cơ sở dữ liệu, cách ly chúng khỏi ứng dụng. Có một số lợi ích, nhưng cuối cùng, nó giúp các ứng dụng dễ dàng kiểm tra và duy trì trong nhiều năm tới. Xin lỗi tiếp tuyến, không có gì để làm với nút

Ethan

Eric Elliott

Có, bạn có thể, nhưng Ruby sẽ là một lựa chọn tồi nếu mục tiêu của bạn là hiệu suất. =)

Eric Elliott

Có, bạn có thể, nhưng Ruby sẽ là một lựa chọn tồi nếu mục tiêu của bạn là hiệu suất. =)

Vedran

cảm ơn bạn cho một bài viết tuyệt vời. Bằng cách sử dụng nút. tiến trình con js http. //nodejs. org/api/child_ process. html - bạn có thể khắc phục sự cố Fibonacci chặn tính toán cao không?

Vedran

nene odonkor

bất kỳ ví dụ thực tế cuộc sống?

nene odonkor

bất kỳ ví dụ thực tế cuộc sống?

nene odonkor

Ví dụ Facebook bạn đã sử dụng là gì. Khi người dùng bấm vào nút thích sẽ có xác nhận ngay lập tức nhưng dữ liệu được ghi sau. Đó không phải là một ví dụ về nút được sử dụng với db quan hệ sao?

nene odonkor

Moch Lutfi

Có lẽ go-lang là sự lựa chọn thay thế. . )

Moch Lutfi

Có lẽ go-lang là sự lựa chọn thay thế. . )

Anthony Hildoer

Bài viết này rất hay, ngoại trừ phần nó nói không sử dụng NodeJS để tính toán vì nó không có chủ đề. Từ khi nào chúng ta cần chủ đề? . Ưu điểm duy nhất để chạy các luồng trên các tiến trình con là bộ nhớ dùng chung. Lần trước tôi đã kiểm tra, bất kỳ hệ thống nào đủ lớn để toàn bộ cuộc tranh luận này có liên quan dù sao cũng sẽ trải rộng trên nhiều máy chủ, bằng cách vô hiệu hóa bất kỳ lợi ích nào của các luồng. Vì vậy, hãy quên đi rằng NodeJS không thể thực hiện công việc chuyên sâu về CPU. Và, nếu bạn không thể, hãy liên hệ với BlueRival. com và chúng tôi có thể sửa tất cả những thứ bạn đã tạo sai với NodeJS

Anthony Hildoer

RiggerTheGeek

Một ứng dụng mà ít người sử dụng, nhưng có thể thực sự tuyệt vời, đó là sử dụng NodeJS để xây dựng ứng dụng dành cho máy tính để bàn. Có rất nhiều gói ở đó - cá nhân tôi thích Node-Webkit https. //github. com/rogerwang/nút-webkit

RiggerTheGeek

hfuti

Xin chào, bài viết hay. Tuy nhiên tôi muốn chỉ ra một điều, NodeJS không chạy trong một luồng đơn lẻ. Lập trình viên không phải sinh ra các luồng mới, chúng được xử lý bởi chính nút trên cơ sở sự kiện. NodeJS được tạo sự kiện, mỗi lệnh gọi hàm cho mỗi sự kiện sẽ chạy trong một luồng riêng biệt. Cách tiếp cận đó khuyến khích viết các chức năng nhẹ hơn. Nếu chức năng của bạn thực hiện nhiều tính toán, hãy phân tích nó thành các chức năng nhỏ hơn và tất cả chúng sẽ chạy trong các luồng riêng biệt. Hãy nghĩ về ví dụ nơi bạn xử lý tệp trong khi phát trực tuyến. Điều đó là có thể nhờ chủ đề

hfuti

Matthew Keas

Điều này được viết rất tốt. Cảm ơn vì điều này

Matthew Keas

Điều này được viết rất tốt. Cảm ơn vì điều này

Matti Schneider

> Kỹ thuật được sử dụng để tránh ngoại lệ nổi lên trên bề mặt là chuyển lỗi trở lại người gọi dưới dạng tham số gọi lại Xin lỗi, nhưng điều đó có vẻ sai. Theo hiểu biết của tôi, [“Gọi lại kiểu nút”](http. // nút hướng dẫn. com/phong cách. html#callbacks) (tôi. e. mô hình chuyển lỗi dưới dạng tham số đầu tiên cho lệnh gọi lại) là tác dụng phụ của hàng đợi sự kiện (trả lại quyền kiểm soát càng sớm càng tốt để cho phép “đồng thời”) thay vì thiết kế để tránh làm gián đoạn luồng. Thực tế là các ngoại lệ không bong bóng thực sự thường là một nguồn gây ra lỗi, đặc biệt là đối với những người mới

Matti Schneider

kyoukhana

Bài báo tuyệt vời. Tự hỏi ai đã tạo ra những sơ đồ đẹp. )

kyoukhana

Bài báo tuyệt vời. Tự hỏi ai đã tạo ra những sơ đồ đẹp. )

Bài báo tuyệt vời, cảm ơn. ) BTW, bạn sử dụng công cụ nào để vẽ hình ảnh?

Matthew Keas

+1 cho điều đó

Matthew Keas

+1 cho điều đó

Matthew Keas

Đối với những người tò mò, có vẻ như những hình ảnh được tạo ra bằng Adobe Photoshop CC. Tôi đã kiểm tra điều này bằng cách xem dữ liệu EXIF của một trong những hình ảnh. http. //dữ liệu exif. com/ Kích thước tệp – 61 kB Loại tệp – PNG Loại MIME – hình ảnh/png Chiều rộng hình ảnh – 624 Chiều cao hình ảnh – Độ phân giải 600 X – Độ phân giải 72 Y – 72 Không gian màu – Chế độ màu sRGB – 3 Nén – Hướng lệch/phồng – Ngang ( . 5-c014 79. 151481, 2013/03/13-12. 09. 15 Công cụ tạo – Adobe Photoshop CC (Macintosh)

Matthew Keas

Juan G. Nuño

Ngoài ra, thực tế là javascript không thể kiểm tra tính tuân thủ của loại gây khó khăn trong việc tổ chức số lượng lớn các lập trình viên cập nhật cùng một lúc cùng một cơ sở mã

Juan G. Nuño

mmmm. không đồng ý, nếu bạn sử dụng đúng một ORM tốt (hãy xem các ORM trưởng thành), bạn cũng nhận được bộ đệm được phân phối của Cơ sở dữ liệu quan hệ cho phép bạn có hiệu suất cao hơn với cùng số tiền và khả năng mở rộng hơn của hệ thống của bạn. ORM không chỉ để giảm bớt cuộc sống cho người mới. Thật vô nghĩa khi sử dụng một hệ thống không chặn như nút. js, nếu cuối cùng bạn bị chặn tại Cơ sở dữ liệu của mình. Nhưng sử dụng ORM theo cách đó, không dành cho người mới

Juan G. Nuño

thiên tài

Rất vui khi bạn đề cập, hầu hết mọi người không đề cập đến điều này

thiên tài

Rất vui khi bạn đề cập, hầu hết mọi người không đề cập đến điều này

Trình theo dõi1

Đối với vấn đề đó, vì bạn có thể thực hiện async shell cho ứng dụng bảng điều khiển, bạn có thể dễ dàng ghi nhân viên của mình vào, chẳng hạn như golang, sau đó sử dụng nhóm chung để giới hạn nhân viên cpu của bạn. từ đó, bạn có thể bao ra cho một công nhân hiệu quả hơn. Bạn cũng có thể làm điều đó cho JS chuyên sâu về CPU, tôi đã làm điều này cho mô-đun scrypt-js của mình (có các mô-đun nhị phân hoạt động hiệu quả hơn, nhưng tôi muốn một mô-đun không có phụ thuộc được biên dịch). Không khó để xếp hàng công việc cho các hệ thống khác và không có lý do gì không thể sử dụng nút để điều phối công việc nói trên

Trình theo dõi1

Có thể *có thể* sử dụng một hệ thống trung gian như TypeScript, bạn cũng có thể sử dụng một kẻ nói dối (jshint) và thậm chí yêu cầu một mức độ kiểm tra để phát hành. Nhận phạm vi kiểm tra 100% nói chung là *rất* dễ dàng trong môi trường tập lệnh. Sẽ đề xuất xem xét Mocha, Chai và Proxyquire. Nếu bạn không viết bài kiểm tra đơn vị, kiểu an toàn thực sự không mang lại cho bạn nhiều

Trình theo dõi1

Steve Naidamast

Tôi đang bắt đầu tìm Node. js khá thú vị. Tuy nhiên, mô hình mà nó dường như đang quảng bá hầu như không mới đối với CNTT. Trong thế giới truyền thông máy tính lớn, chúng tôi gọi những khả năng như vậy là "đăng nhập lại", trong đó một quy trình đơn lẻ có thể xử lý mức độ cao của các cuộc gọi đến nó. Microsoft đã triển khai các khả năng tương tự với cơ sở hạ tầng đối tượng Singleton của mình và tôi tưởng tượng thế giới Java đã thực hiện các triển khai tương tự. Thật kỳ lạ, khuyến nghị của Microsoft để tăng cường khả năng mở rộng qua các dây dẫn đến các dịch vụ phụ trợ là thúc đẩy cấu trúc đối tượng "Cuộc gọi đơn" hoặc một phiên bản đối tượng cho mỗi yêu cầu cuộc gọi. Do đó, lập luận được đưa ra cho Node. js thực sự trái với khuyến nghị của Microsoft; . Trong mọi trường hợp, với tư cách là một doanh nghiệp ASP. NET developer, I am not sure if I would find any use for a Node. js implementation, though our web designer may. On another note, I would like to add my own opinion on the use of ORMs. ORM là công cụ tuyệt vời khi phải đối mặt với cấu trúc cơ sở dữ liệu hiện có so với yêu cầu của ứng dụng mới vì ORM có thể xử lý rất nhiều mã hóa lặp đi lặp lại thông thường thường thấy với bất kỳ ứng dụng cơ sở dữ liệu nào. However, because ORMs are high-level layers, they are usually not the most efficient options to use against databases whereas direct access through native providers are. In many respects, better to do the repetitive coding for efficiency over applying a heavy-weight interim layer such as an ORM

Steve Naidamast

opensas

Very interesting observation. I'd like someone to elaborate a bit more on that. I would like a more concrete example, like some piece of concrete code calling an async heavy-computational function, and someone explaining what happens if that is run in a multicore equipment. Does the thread that was sercing http requests gets blocked? Or another thread is used for that?

opensas

Derrick Simpson

Node is terrible as a web server. Even the creator suggests that this is not what Node is intended for, and that it should be leveraged for it's strengths. JavaScript "Mọi thứ", giống như các quy trình công nhân, thật lố bịch

Derrick Simpson

Eric Elliott

This is ridiculous. Nút được xây dựng với web là hạng nhất và nó vượt trội như một máy chủ web. It is rapidly replacing Ruby and PHP in many enterprise organizations because it has demonstrably boosted both application performance (reduced page-load times, etc. ) and developer productivity

Eric Elliott

jonpress

You can in fact create multi-threaded servers using Node. js to offer more stable performance but it does take a lot of extra work (see the built-in cluster module and the child_process module). I have created a framework which runs on multiple CPU cores and solves much of the issues discussed in this post. Check it out. http. //nombo. io/

jonpress

Connor Leech

does something like mongoose. js solve the node relational database issue? http. //mongoosejs. com/

Connor Leech

does something like mongoose. js solve the node relational database issue? http. //mongoosejs. com/

Rob Tweed

Yes - see the queue/pre-forked worker pool approach adopted by EWD. js. http. //gradvs1. mgateway. com/download/EWDjs. pdf Summarised here. http. //gradvs1. đường cổng. com/download/EWDjsMechanics. pdf

Rob Tweed

keith

yeah, I was wondering about it too. great visual + awesome post

keith

yeah, I was wondering about it too. great visual + awesome post

Carlos Ballena

Very helpful article

Carlos Ballena

Very helpful article

Jesus Nuñez

npm install felixge/node-mysql. That might be the most useful repository I've seen in ages

Jesus Nuñez

npm install felixge/node-mysql. That might be the most useful repository I've seen in ages

Matthias Lienau

Nice article, indeed. But, @hfuti. disqus, you're wrong in saying "NodeJS is not running in a single thread . each function call per event will run in a separate thread. " As far as I understood, the main NodeJS event loop consuming your JS code in fact runs in a single thread. Tất cả các tác vụ có khả năng chặn và/hoặc chạy dài như I/O của đĩa được ủy quyền và thực thi bởi libuv như một phần của công cụ thời gian chạy nút tạo ra một số lượng *giới hạn* các luồng có sẵn dưới dạng nhóm luồng. Nói điều này, rõ ràng là luồng vòng lặp sự kiện chính không bị ảnh hưởng hoặc bị chặn bởi việc thực thi mã khác (lại không đồng bộ). Vì vậy, ví dụ: tệp I/O với chính mô-đun fs được triển khai theo cách không chặn - cuối cùng thì hệ điều hành/nhân cho phép hoạt động không chặn cũng tốt. Tất nhiên, các quy trình hoặc luồng nước ngoài luôn có thể được tạo ra bởi các mô-đun tùy chỉnh hoặc dịch vụ của bên thứ 3 (quy trình công nhân). And yes, there are runtime env projects handling more than one node process and their threads on the same machine or cpu cluster. Nhưng nó là một câu chuyện khác. Hãy sửa tôi nếu tôi sai

Matthias Lienau

josep2

Cái này thật tuyệt

josep2

Cái này thật tuyệt

Jacopo Chiapparino

Nice article, thank you

Jacopo Chiapparino

Nice article, thank you

NoobMovies. com

Tôi nghĩ Django vẫn đá đít Node

NoobMovies. com

Tôi nghĩ Django vẫn đá đít Node

Alex Writing

Này Tomislav, http. // mật mã. com/7-minimal-node-js-web-frameworks/ Tôi rất vui nếu bạn có thể thêm bài viết trên vào danh sách. )

Alex Writing

Này Tomislav, http. // mật mã. com/7-minimal-node-js-web-frameworks/ Tôi rất vui nếu bạn có thể thêm bài viết trên vào danh sách. )

dung nham Victor

Ôi, điều này thật tuyệt vời. Tôi luôn muốn học nút. js

dung nham Victor

Ôi, điều này thật tuyệt vời. Tôi luôn muốn học nút. js

Cảm ơn bạn đã cung cấp ví dụ, minh họa và trường hợp sử dụng. Giải thích chi tiết và các bước trong một số trường hợp với các tài nguyên có liên quan làm cho nó trở nên tuyệt vời. Trường hợp sử dụng nodejs *nên* rất hữu ích

tàu tuần dương

Tất cả mã Node đều bị ràng buộc bởi luồng. Nó có thể không chạy trên cùng một luồng mọi lúc (điều này không liên quan gì đến bản thân Node mà thay vào đó phải thực hiện với bộ lập lịch xử lý của hệ điều hành), nhưng nó bị ràng buộc bởi luồng. Để tận dụng nhiều luồng, bạn cần sử dụng thứ gì đó như Cụm. http. //nodejs. tổ chức/api/cụm. html

tàu tuần dương

Đã đồng ý. Tôi sử dụng Postgres cho tất cả các loại hoạt động GIS trong một ứng dụng mà tôi đã làm việc trong khoảng một năm và ứng dụng này hoạt động rất tốt cũng như mang lại lợi ích từ I/O không chặn giống như bất kỳ quyền truy cập cơ sở dữ liệu nào khác. Chỉ là bạn phải thả trực tiếp xuống SQL. Có một vài ORM, nhưng không có gì thực sự trưởng thành

tàu tuần dương

tiên tri

Tuyệt vời, cảm ơn rất nhiều vì điều này

tiên tri

Tuyệt vời, cảm ơn rất nhiều vì điều này

Zmirc

nhận xét nhỏ. đừng nhầm lẫn Object DB với Mongo (Document DB). Có 2 thứ hoàn toàn khác nhau

Zmirc

nhận xét nhỏ. đừng nhầm lẫn Object DB với Mongo (Document DB). Có 2 thứ hoàn toàn khác nhau

gianlucca

i agree, good post

gianlucca

i agree, good post

gianlucca

yes, i agree

gianlucca

yes, i agree

gianlucca

sure

gianlucca

sure

Toulon

Very well written article. You put a lot of thought into it. Quick node/express question I am I am adding rapid data entry, not batch, data entry to my system I have a form (mfntapes) that works great. I have a test form (joe) the prompts for the number of times I want to call the mfntapes form The gist contains the code, fails to work, the after prompting for cnt attempts to call for mfntapes cnt times. Error is "ReferenceError. form is not defined" in line 87 of the gist The question is how to call form mfntapes x number of times where x is a vairable? See lines 45-55 of https. //gist. github. com/toulon/9571625

Toulon

Jesus Bejarano

ORM for real projects are useless hone

Jesus Bejarano

ORM for real projects are useless hone

Thomas

Nice article . -) > SERVER-SIDE WEB APPLICATION W/ A RELATIONAL DB BEHIND I wonder why Node is not good for that? You have promise based *SQL libraries (like Knex) which enables non-blocking queries. Node has no opposition with relational databases. it has no interest with blocking I/O drivers only. Relational or not relational

Thomas

Seb

I wish NodeJS was not (almost) systematicallty presented as THE de facto alternative to the traditional threaded webserver. Async IO is not exclusive to NodeJS. Most major languages out there - including Java and PHP - have async IO frameworks similar to NodeJS. This wiki page lists most of them. http. //en. wikipedia. org/wiki/Reactor_pattern I'm not saying NodeJS doesn't have its merit, but I'm sick and tired of seeing people flocking to it as if it's the *only* async IO stack available, and the *only* alternative to the good ol' PHP or Rails stack. To be honest, we may be stuck with Javascript on the browser, and will be for a very long time (except if Javascript becomes just another target platform/language thanks to asm. js), but I can't come up with any good reason to use it on the server side in favor to other available languages. Most of the alternatives are just way better as a language, have better standard libraries, tools and resources. Just a personal opinion. Long story short, Node JS is cool, but there certainly is a similar framework written in your favorite language. Please just take 5 minutes to research it before switching to NodeJS

Seb

Jarle Leopold Moe

How would you upload files? What about Directory integration? (Active Directory, Open Directory) What about communication with external services? All request depending on a response from any of these types of services would block the calls. Node. js is _single-threaded_ it's only applicable for certain types of tasks

Jarle Leopold Moe

Eric Elliott

These are great examples of why Node is so much better than the competition at web services. None of those are blocking operations in Node. They're asynchronous. While other servers waste resources spinning off separate threads, Node fires off an event-driven asynchronous operation and keeps taking more requests in the meantime. The practical upshot is that porting web services from PHP or Ruby can deliver between 2x and 10x improvements in simultaneous connections and typically 30% - 60% improvements in average response times. Lots of big companies are doing web Node projects just for these reasons, including Adobe, Paypal, eBay, Walmart, Yahoo. , Groupon, Uber, etc

Eric Elliott

jenit shah

very nice article and very clear thought regarding node. js where to use and where not

jenit shah

very nice article and very clear thought regarding node. js where to use and where not

CowsRule

Every major application development platform has already had support for HTML5 for the past several years, including websockets for bi-directional communication. Add to this the strong types, multi-threading and the tons of other stuff that languages such as Java have to offer and I seriously question why anyone would waste their time using this

CowsRule

robertcooke

Just want to mention that node is not the only server side option for javascript especially since oracle put the nashorn javascript engine on the jdk. Now you can also use all the jvm goodness from javascript we are using vert. x as the async server and nashorn to use javascript. You can see some code samples in this module https. //github. com/core9/module-nashorn the project site is core9. io

robertcooke

Anonymous

This is an amazing overview . Thank you

Anonymous

This is an amazing overview . Thank you

Vishnu Tekale

Very well written. Thanks for sharing

Vishnu Tekale

Very well written. Thanks for sharing

Gleb Bahmutov

Why Node is different - using bar as analogy http. //bahmutov. cái ghim. co/why-node-is-different. html

Gleb Bahmutov

Why Node is different - using bar as analogy http. //bahmutov. cái ghim. co/why-node-is-different. html

FluckerSputter

Just to let you know you have "support support" in How it works under-the-hood is pretty interesting. Compared to traditional web-serving techniques where each connection (request) spawns a new thread, taking up system RAM and eventually maxing-out at the amount of RAM available, Node. js operates on a single-thread, using non-blocking I/O calls, allowing it to support support tens of thousands of concurrent connections (held in the event loop)

FluckerSputter

piloh23

Node. js will never replace Rails as the number one web framework

piloh23

Node. js will never replace Rails as the number one web framework

Alifa Nurani Putri

Hello, Is node a best choice for video streaming and uploading? Is any different performance w/ PHP for that?

Alifa Nurani Putri

Hello, Is node a best choice for video streaming and uploading? Is any different performance w/ PHP for that?

SleightDifference

How come PHP isn't mentioned for interacting with relational databases? It's as if PHP isn't used anymore? Why is it being neglected?

SleightDifference

How come PHP isn't mentioned for interacting with relational databases? It's as if PHP isn't used anymore? Why is it being neglected?

Clain Dsilva

Thanks for taking time to explain Node. js. I really had hard time understanding it from their website as well as Wikipedia. Well written post. Keep it up

Clain Dsilva

Thanks for taking time to explain Node. js. I really had hard time understanding it from their website as well as Wikipedia. Well written post. Keep it up

Cezar Luiz

What about this https. //github. com/felixge/node-mysql? Nice article. Thanks

Cezar Luiz

What about this https. //github. com/felixge/node-mysql? Nice article. Thanks

Marcelo Lima

Thank you for this article. Cleared a lot of questions I had about Node internals

Marcelo Lima

Thank you for this article. Cleared a lot of questions I had about Node internals

Navid

Awesome Article

Navid

Awesome Article

Abdelhakim

https. //www. udemy. com/nodejs-tutorial-from-scratch-by-examples/?couponCode=NewOffer 1. Lifetime access to 24 lectures 2. Over 120 mins of high quality content. 2. Join to a community of over 2687 students learning together. 4. Course information and regular updates 5. Learn node. js and mongoDB from scratch by examples. 6. Course information and regular updates. 7. Discussion forum, which we encourage you to make use of -- both to pose questions about the material to the course instructor and to exchange ideas with your classmates. 8. High quality course support

Abdelhakim

rahul garg

As per my understanding with article, if you send any request to node server it will actually process on some background thread (libuv. dll). Now I want to post some file through node server, why it block the node server while it will actually process on background thread and when done , only response will be returned by node thread ? Kindly suggest if I am missing some thing

rahul garg

siddesh

Super Article

siddesh

Super Article

Fanck

Isn't it possible to get the date of posting of your article? or all your posts for that matter. It is really disturbing to read technical posts without dates. thanks

Fanck

Isn't it possible to get the date of posting of your article? or all your posts for that matter. It is really disturbing to read technical posts without dates. thanks

Namo

You mention Node. js is good for a chat application because it's not CPU intensive. I can't think of too many use cases that don't require much CPU. For example, could Twitter be built with Node? It seems there's a lot of computation required just to generate your feed. Node. js uses certainly can't be so narrow

Namo

Ian Kaplan

Great article. Thanks. There's an old joke. you're not a paranoid if they're really out to get you. That's the attitude that should be taken when it comes to Web application security. One thing that bothers me about Node. js is that I have no insight into how secure it is. When an environment like Grails, where I have Java/Groovy running on Tomcat I have some confidence in Tomcat security, if for no other reason than the fact that Tomcat has been around a long time and has evolved. This isn't true with Node. js. I was also looking at the Node. js libraries. At least for the file access, it appears to be nothing more than a thin layer over the POSIX file system calls. I like the Java or even the C++ file abstractions more. The main argument that I see for Node. js (made in this post) is that it has really lightweight threads and that you can have JavaScrip everywhere. This last issue is an attraction for those who only know JavaScript. As far as the light weight threads, this is not so much a language issue as a platform support issue. It should be possible to support this kind of thread model in another language

Ian Kaplan

Huge Web

Toptal designer did the design for them

Huge Web

Toptal designer did the design for them

Scott

Great article. Thank you for all the information

Scott

Great article. Thank you for all the information

daimmo

I agree. I guessed it was around "a year ago" because of most of Disqus comments. This is taken from their meta tags anyway. 2013-08-13

daimmo

I agree. I guessed it was around "a year ago" because of most of Disqus comments. This is taken from their meta tags anyway. 2013-08-13

Adnan King

nice

Adnan King

nice

Ethan Garofolo

Node. js isn't a web framework. It's a packed V8 runtime with some core libraries attached. Node is more like mri in the Ruby world than Rails

Ethan Garofolo

Node. js isn't a web framework. It's a packed V8 runtime with some core libraries attached. Node is more like mri in the Ruby world than Rails

Guest

Node. js is more like Rack, but not the same. MRI is just a language implementation

Guest

Node. js is more like Rack, but not the same. MRI is just a language implementation

Lambda Pool

the problem is that mongodb, its too risky using a database who can't be migrated never

Lambda Pool

the problem is that mongodb, its too risky using a database who can't be migrated never

Lambda Pool

well its true, ORM is a bad practice after all

Lambda Pool

well its true, ORM is a bad practice after all

Lambda Pool

yes but it does in a very non efficiently way

Lambda Pool

yes but it does in a very non efficiently way

Lambda Pool

the database engine itself will be ever more sophisticated than any ORM library home made by someone else

Lambda Pool

the database engine itself will be ever more sophisticated than any ORM library home made by someone else

John Bailo

It's ameezing how asynchronous the web still is. Indeed, like a telephone answering machine, its utility lies there

John Bailo

It's ameezing how asynchronous the web still is. Indeed, like a telephone answering machine, its utility lies there

Jayaraj Poroor

I agree - I'm not a fan of ORMs either. ORM is a classic example of leaky abstraction

Jayaraj Poroor

I agree - I'm not a fan of ORMs either. ORM is a classic example of leaky abstraction

Jayaraj Poroor

Regarding using Node. js with relational databases. Shelloid (http. //shelloid. org) is an open source application server for Node. js that we developed to simplify lot of programmer tasks. e. g. , You can declare named SQL queries as annotations and a function by that name automatically gets added to the DB object for you to use

Jayaraj Poroor

I think you do not understand the reason for or characteristics of ORM's very well. ORM's not only isolate data concerns, they provide testability and greater flexibility than traditional SQL clients. ORM's also provide in memory access in place of inefficient joins, so they can actually be far more efficient than SQL in real world scenarios. Plus, given the choice of performing complex set operations in a limited procedural set language like SQL or complex in memory operations using a far richer, more expressive and maintainable language, the richer language wins if you ever expect to maintain or extend the application

You don't know what you are talking about. If you are writing a non-trivial applications and not using an ORM than I'm sure there will be many developers both today and in the future that will be cursing your name as they wade through ridiculous rafts of SQL. Testability? I guess that's just for trivial applications. When I see ridiculous comments like this coming from node. js fanboi's it makes me suspect that they'd be singing a different tune if node. js had decent RDBMS capabilities

Lambda Pool

you just overate ORM such as most OO fanboys does

Lambda Pool

you just overate ORM such as most OO fanboys does

Lambda Pool

your comment is ridiculous too, ORM is not a everyone's accepted pattern

Lambda Pool

your comment is ridiculous too, ORM is not a everyone's accepted pattern

The irony is that lambda's (aka, anonymous methods) are the basis of both javascript and the preferred technique for C#'s multiple implementation of the same callback pattern, albeit with full type safety. In fact node's major characteristics (2-way, lightweight, asynchronous has effectively been implemented in C# as "SignalR", and there are several language features which are both asynchronous and natively multithreaded, (unlike node. js). Now I could understand if your experience with ORM's was limited to Hibernate (absolutely awful, one of the worst implementations of a major concept I've ever had the displeasure to work with) or even EF, which at least is fairly powerful and expressive due to LINQ, if data nanny overkill. But a micro-ORM like Dapper gives you all the flexibility and power of direct SQL with the benefits of rich data manipulation via objects, and is fast, very fast. And I'm sorry, but OOP is a well proven, very effective design strategy if you know what you are doing, i. e. , you are a pro. I see three major problems with the node. js approach that no one seems to have a good answer for. So you start with the premise that there are such inefficiencies in waiting for IO that there is a huge potential there. So yeah, you've got great concurrency, right until you get to the first blocking library, a database, a file server, etc, which is practically every major piece of functionality written. So it's just hurry up and wait for 10,000 connections instead of 100, ok that's something, but where does it get you? So then you start rewriting all those services asynchronously, but that's just a snake eating its own tail, because that's hurry up and wait too. Because in the end every database on earth ultimately comes to a magnetic arm skipping across a disk or reading solid state memory, and that's assuming you're on the same machine, as opposed to distributing data across a pool of far slower network connections. Then you have the single threaded issue. There is probably no more misused language than Javascript because the barriers of entry are so low. And while early adopters might understand a bad practice when they see one, most javascript programmers simply have no idea what they are doing. Thirdly, Javascript is not exactly a particularly fast language, so the advice seems to be don't do compute intensive tasks. Where does that get you? So you end up with an elegant solution to one category of issues, but you're trapped there, with no way out of the non-compute intensive, hurry up and wait ghetto

Wow, that is one seriously ignorant statement. Uploading files to webservers is *THE* stated rational of node. js's inventor for why he wanted a non-blocking library. So when you fanboi's break out of the single threaded, slow dynamic world of cut and paste code with zero type safety, multithreading, and only one trick pony (lambdas) to match . Net's multiple asynchronous capablities, (all so that you can get 10x more users to hurry up and wait for IO), then you can lecture us about "sophistication". The . Net framework has a vastly more advanced feature set than any language you can name, period, and IIS, properly configured, can beat the piss out of Apache and can readily match nginx as a reverse proxy or for static content. In the end you've got several problems which are intractable. 1. Javascript is slow, and your technology of choice is single-threaded, so intensive compute tasks are off the table. 2. Javascript debugging and testing blows in comparison with any typed language. Pro's use extensive testing, not fly by the pants 'hey it works'. 3. The 'everything is modular' approach is not an architecture, it's an invitation to chaos, like Perl or PHP. 4. Concurrency doesn't buy you crap if all you are doing is waiting for some other IO bound process, which is pretty much everything worth doing with computers. 5. The quality and experience of many javascript programmers (not node. js programmers necessarily, but it's popularity will bring them) is remarkably poor, as demonstrated by comments in which fanboi's prove that they have no idea how other systems that actually don't ignore any computing problem they can't solve work

Lambda Pool

ORM is just a work around for the problem of impedance mismatch, nothing else. Its not big deal, about OO its a cross paradigm like AOP and its not really based in nothing else beyond encapsulation. Without procedural paradigm OO does nothing, every real skilled programmer already knows that

Lambda Pool

Impedance mismatch involves all sorts of ramifications, especially in regards to maintainability, portability, extensibility and performance. To quote Ethan above (since my explanation obviously didn't take). ". it's a tool used to encapsulate database concerns, isolating them from the application. There are several benefits, but ultimately, it makes applications easier to test and maintain years down the road. " "about OO its a cross paradigm like AOP and its not really based in nothing else beyond encapsulation. Without procedural paradigm OO does nothing" Ok, I'll be sure to spread the word that we should stop fooling around with all this esoteric OOP stuff and get back to a language that lets us do everything vis-a-vis encapsulation. VB6. You'd think a Javascript programmer might want to mention inheritance, if not polymorphism, since javascript has a relatively unusual mechanism for it. prototypes

A singleton is an instantiable (non-static) object with a private constructor so that only a single instance can be created. (Imagine an instance class with a static property exposing an instance of itself that depends upon a private instance constructor). It was actually implemented in Java before . Net existed. Perhaps what you are thinking of is a non-blocking Callback mechanism, which is handled in C# via delegates, events (multicast delegates) and the new async and await keywords that transform standard C# into a lambda to be executed at compile time. It also handles multi-threaded asynchronous operations via it's Parallel extensions, which permit spreading load across multiple threads/cores as long as that work is not serial in nature. Also, I would encourage you to check out a micro-ORM like Dapper. It's far less comprehensive than EF, but it's far more flexible and gets out of the way, plus it's significantly more efficient than Hibernate and EF (about 5x faster for reads)

Qalandr

Yes this article rocked tits. Esp good for a Croat with ESL. ;) #nodeboy

Qalandr

Yes this article rocked tits. Esp good for a Croat with ESL. ;) #nodeboy

Ty Turner

We are searching for a Node. js developer. Please see http. //altaits. com/careers/search-jobs/ for details. Thank you

Ty Turner

We are searching for a Node. js developer. Please see http. //altaits. com/careers/search-jobs/ for details. Thank you

Vob Bobily

So after reading your article I still havent figured out why Node js want to reinvent the wheel. I still think node js and the likes are crap

Vob Bobily

So after reading your article I still havent figured out why Node js want to reinvent the wheel. I still think node js and the likes are crap

cintalauraramarimari

A great introduction to find out what it is JavaScript and once the answer to from bagaimana tips mengatasi wanita frigid

cintalauraramarimari

A great introduction to find out what it is JavaScript and once the answer to from bagaimana tips mengatasi wanita frigid

Daniel

Noob questions. Um, isn't the ease with which you can move request data (i. e. untrusted data) into database (where data is assumed to be trusted) a big hazard? How do you ensure that you never forget to inspect every piece of incoming data when it arrives, before you start trusting it? Generally, I would assume something as popular as Node. js would have thought of this, but I remember back when Rails had blanket model update. That changed real quick when Github's use of this "feature" was exploited (fortunately, by a whitehat). Also, of course, just because you add a conversion speed bump does not mean that people won't make mistakes, but at least they're more likely to give it some thought, which probably means they're going to make less mistakes

Daniel

I don't understand the angst against using an ORM. Were you in a proper environment where concerns were separated? The ones bashing ORM just sound like they don't know what they're doing or how to engineer proper software. Why on earth would I want to go from writing software in Java/C#/_whatever_ to drop into SQL where it is hard to version, properly test, and can apparently cause severe brain damage? Everything is a double edged sword - an implementation or a convention like using an ORM over raw SQL really doesn't matter. Depending on the situation raw SQL might be best. it might be better to use a NoSQL store. maybe an ORM is fine. Usually, from my experience, I can tell you that an ORM is better for a lot of reasons, and they have been relayed by M. I spent the time to write my own libraries to abstract vendor specific implementations and you need to create your own mappings. You can easily spawn from a certain state or use existing data structures. It took time to write my libraries and it was not easy at all to do it but it was well worth my time to do it since I can now reuse my libraries. Is it the BEST? I don't know. I like it but I certainly won't go around to arbitrary technical articles that have nothing to do about SQL and post something like "Yes this technology is good but stay away from raw SQL. " I just don't see a need to be bashing anything here, especially an ORM when the article is exclusively about JS and NodeJS

Michael

Probably one of the main points of this article, that gives Node is supposed scalability, is the offloading to a Queue or Service Bus that leads to asynchronous processing. That is a well proven architectural pattern, available in many languages, is especially used in CQRS (Command Query Responsibility Segregation) with Event Sourcing, is very well suited to be used by technologies such . Net Reactive Extensions that provide considerably greater functionality and flexibility than Node. Asynchronous programming and handling its pitfalls has been around without Node for years, if you had knowledge of enterprise development. As for the hate against ORMs. you guys crticising it seem to be moving from front-end development into an area where you have no knowledge or expertise in OO, BDD, TDD or any other proven Enterprise level methodology. No concept of integration other than Twitter feeds. No experience of complex Workflow or scalable caching. This is one of the dangers - you know JavaScript, and a bit of SQL. So everything else is superfluous - until you need it, such as the attempts to bring an element of type checking to JavaScript. Seriously, each technology has its place, but there is no one size fits all approach. Appreciate the strengths of each technology, and use them where appropriate

Michael

Reo

Great introduction to node. js. Thanks, i samo naprjed

Reo

Great introduction to node. js. Thanks, i samo naprjed

Richard Bellantoni

Because they suck for a complex application. Sure if your scenario where you spent all this time trying to make the ORM work the way you need it to, you could have just put that same effort into writing the SQL properly and making sure it's organized etc and you would be further along in the project and have more control over the application. ORM's are great at saving time on a small to medium scale project, but once you delve into more complex and larger applications, you're going to spend either A. ) A lot of time coding to make the ORM work the way you need it or B. ) Just decide to write the SQL yourself because the time it takes to make the tool work how you need it just isn't worth it

Richard Bellantoni

sinta maharani

JavaScript is better than some of the other programming languages. therefore cara menghilangkan gatal keputihan better fit with JavaScript

sinta maharani

JavaScript is better than some of the other programming languages. therefore cara menghilangkan gatal keputihan better fit with JavaScript

naseya10

Great, informative article. Thanks for sharing this. Unlockpwd

naseya10

Great, informative article. Thanks for sharing this. Unlockpwd

Eric Elliott

Pot, meet kettle. Those may be intractable problems if any of them were true. None of them are. 1. a) JavaScript is all JIT these days and delivers 1-2x native code performance (faster than any other dynamic language I'm aware of). b) Non-blocking by default can deliver orders-of-magnitude improvements in code efficiency - transparently. 2. Almost all modern editors support type inference for JS. ESLint, Closure Compiler, and a number of other options offer sophisticated static analysis capabilities. TypeScript even offers a nice structural type system. 3. The opposite of modular is a tightly coupled monolith. That's a bad idea in ANY language. 4. "if all you are doing is waiting for some other IO bound process" - Non-blocking by default means you're NEVER waiting for some other IO bound process. That's why Node delivers such huge improvements on resource utilization. 5. 2006 called. They want their language-snob attitude back. The days when serious engineers considered JS to be a toy are long since over. JS powers sophisticated enterprise applications at just about every fortune 500 today. Additional point. JS is the only language with fully native support for isomorphic code (meaning you reuse most of your application on both servers and clients). You can write JS ONCE, and it will power the server, the web browser, and mobile devices including iOS and Android. See React Native. https. //leanpub. com/learn-javascript-react-nodejs-es6/

Eric Elliott

1) 1-2x native code performance? Do the electrons run faster on node code? Not a good start. 2) Type inference is mapping variable declarations to types without explicit syntax, i. e. , a) it requires actual types, and b) compilers enforce type safety, not editors. And you can dress it up any way you want, but there is no way to enforce sophisticated state analysis with slop-tastic dictionaries of whatever stored in strings & functional delegates. Also, Typescript is not Javascript, it is Javascript with a half-assed type system pasted on top. Even Google is abandoning Js for Typescript in Angular 2. 0 Why? Because Google has decided that an untyped system is insufficient for serious work. But is that type system anywhere near as sophisticated as a compiled language? Nope, not even close. 3) You are misunderstanding what I was characterizing as "modular design". The alternative is not monolithic code, but encapsulation, specialization via inheritance (or prototyping), polymorphism, and externalizing dependencies via IoC. The alternative is SOLID, i. e. , modern Object Orientation. 4) Your process may not be waiting, but your customers are waiting for the callback. My point is that being able to serve more requests doesn't do you any good if every served request then has to wait on yet another operation. In the end, somewhere somehow, you will eventually be going to a disk or waiting for IO, because that's where the information the customer wants lives. 5) I didn't say that JavaScript was a toy language, I said that most JavaScript developers are well-meaning, cut and paste amateurs, and they will invade the ranks of node. js developers as it becomes more popular. I'll take a strong type system over "full native support" (that's not native) for "isometric" code that can run on clients or servers [you say that like that's a good thing] any day. Wow, Js on android and iOS. I guess the days of Apple adding another strongly typed, native language for iOS are over Obviously you've never heard of Mono, the cross platform . Net that compiles and runs on every major OS, produces native runtimes for all three major mobile platforms, and runs on everything from beowulf clusters to wearable devices. This is why we don't respect you. You don't know or understand anything that came before, or anything outside of your javascript bubble. You don't solve any problems that weren't solved before, but yet you're convinced you have all the answers. That seems to be a common theme with anyone whose education system stressed self-esteem over critical thinking

Eric Elliott

This reply just strikes me as willful ignorance. 1. Really? Rather than investigate and learn the truth, you just want to ridicule the answer? I'm not taking the bait. Watch Brendan Eich's Fluent talks if you're interested in actually learning something. 2. I know what types and type inference are, and I know the benefits of static types. I've been in this game since before JavaScript was invented. TypeScript is a superset of JavaScript that compiles to JS & allows for sophisticated static analysis. It's structural type system is better than the type system Java had back when I was coding in Java, and it's much better (as in more reliable and flexible) than C and C++. 3. "encapsulation, specialization via inheritance (or prototyping), polymorphism, and externalizing dependencies via IoC" - these are all forms of modularity, and JavaScript modules provide viable alternatives to all of them - and in the case of class inheritance, it's far superior. See https. //medium. com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3 4. "your customers are waiting for the callback. " Fortunately, that's where the performance I talked about in point 1 shines. JS provides efficient utilization of I/O resources. In fact, dealing with I/O bottlenecks is the entire reason that Node was invented. I've ported several large production projects from PHP and Ruby to Node, and seen dramatic reductions in response times, both average response times and response time ranges - and since a typical Node app utilizes a small fraction of the memory required for C# applications, your customer I/O competes less with the RAM paging you might experience with a compiled C# application. 5. "you say that like that's a good thing" I've seen objectively measurable increases in team velocity ranging from 40% - 60% improvements. Believe it or not, it's a fact, and being more able to adapt to changing needs and experiment more (particularly in the UI layer) delivers very real business value. Why do you think so many enterprise organizations are adopting Node? It's not because some dev prefers JS. It's because they ran the tests themselves and figured out it's a huge win. "Obviously you've never heard of Mono, the cross platform . Net that compiles and runs on every major OS" Yeah, I have - what I haven't heard of is Mono delivering anywhere near the value that Node delivers in enterprise production. Got a good article on that? 'Cause a quick Google search isn't turning up much. Check out this awesome result in the top 3 of the SERP. http. //www. đại số. com/Tại sao-không-C-với-Mono-phổ biến-cho-doanh nghiệp-ứng dụng-trên-máy chủ Linux. nhưng tìm kiếm nhanh trên Google cho Enterprise Node. js cung cấp khá nhiều. Đây là 3 kết quả tìm kiếm hàng đầu mà tôi thấy. http. //Blog. tăng chồng. com/node-js-is-enterprise-ready/ https. //www. hân hoan. com/nodejs-hỗ trợ https. //www. centurylinkcloud. com/blog/post/node-js-is-taking-over-the-enterprise-whether-you-like-it-or-not/ There's really no contest here

Eric Elliott

1, yes, I'm mocking your evidently accidental claim that JavaScript makes electrons run faster, or even as fast as native, because it's patent nonsense. Not only is that impossible, it ignores one of node. js' acknowledged weaknesses. It sucks on compute intensive operations, because it's single threaded, which means compute intensive operations block execution. duh. 2. Your knowledge of Java does not qualify you to understand what a competent type system is. Java's generics are a largely useless, johnny come lately me-too feature when compared against to C# generics because they suffer from run-time erasure, in other words, the generic type safety and reflection only works at compile time, because at run time, everything is cast to an object. So when you are going on about static analysis, you are effectively trying to claim it's as good as compile time + run time type reflection, which is very far from the truth. 3. Meh. Chopping up everything into discrete functions is a form of modularity too, but it's vastly inferior to SOLID, which was my point in the first place. And while prototype based inheritance is interesting, it's hardly better than real inheritance, which permits far more flexible arrangements. 4. I don't see how it's impressive to speed up a Ruby app, or refactor some craptastic PHP into something faster. Your memory overhead claims are equally baseless. Tôi có thể chạy micro. Net on a watch or on an arduino device. I can write . Net that runs very well on an under-powered phone. Look at the memory chrome consumes for an SPA, or try to run a complex javascript app on a tablet, and then tell me how "lightweight" JavaScript is. 5. The lack of a proper separation of concerns (which is the cause of most maintainability problems) is the number one issue I encounter at enterprise scaled customers, and an impressive team velocity is always how they got there. Why do I think a number of organizations are choosing node? Because typically a mediocre, over-sized team of moderate competence f'd up the previously shiny new thing that was supposed to solve all their problems, so they want to believe the hype that the problem is not them, but their previous technology choices

Eric Elliott

1. I think you misunderstood my meaning. JS runs 1-2x SLOWER than native -- much better perf than any other dynamic language I know of. It's fast enough to run AAA game engines like Unreal Engine and Unity in stunning quality at 60+ fps. 2. I actually think that a good native type tool would be a good addition to JavaScript, but only if they're user-definable structural types. That said, JavaScript does support static analysis via type inference, and there are a number of ways to provide type hints for dev tools. In addition, JavaScript also has an impressive array of runtime analysis tools. 3. "hardly better than real inheritance, which permits far more flexible arrangements. " Wrong. https. //medium. com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3 4. My apologies. I was not aware of micro. Net. JavaScript also runs as-is on low-powered devices including Arduino, Tessel, and a number of others. Node works great on most of them. If that's not small enough, you can create a custom Node compile, drop features, even swap out the V8 engine for a different JS engine if you need to. You can also restrict yourself to using tiny JS libraries (of which there are many on npm) to keep your codebase compact. 5. ". they want to believe the hype that the problem is not them, but their previous technology choices. " That might explain an experiment or two, but the Node takeover is much more than that. We're rapidly replacing apps in a variety of languages with Node. Having worked at a fortune 500 during the transition to Node, I can tell you our justifications. We did experimental ports to Node, found. 1. that the app was faster and more reliable, delivering huge wins in both average response time, and the number of requests we could serve with the same machine, and 2. The developers were more productive for a variety of reasons, including the fact that JavaScript specialists could more easily work on both sides of the stack without context switching, and a lot of code could be shared in both the server and the client. Those advantages have real, measurable influences on the company's bottom line. That's why Node is taking over at both startups and enterprise companies

Eric Elliott

Kesava Velugubantla

especially with edge it is really handy

Kesava Velugubantla

especially with edge it is really handy

pawan kumar

Thanks Tamisalv I was looking for quick reference read for understanding node. js and why projects might use it. Reading this gave me a better understanding of advantages of this this technology and also when one might use it. Cheers

pawan kumar

Jay

"After over 20 years of stateless-web based on the stateless request-response paradigm, we finally have web applications with real-time, two-way connections. " As a result we have webpages which take longer to load nowadays when we have Internet speeds in the order of megabytes per second, than back in the day when our speeds were in the order of bytes per second but our webpages were plain simple HTML. Nowadays we have webpages which load halfway and then stop, which crash at the slightest network error i. e. dynamic IP address reassigning, or a momentary lapse in the WiFi signal forcing you to reload the whole page, whereas browsers are designed to gracefully handle those errors or resume once the network connection is restored, buggy Javascript scripts don't handle errors as well

Jay

adroittech

Tôi chỉ có 1 câu hỏi ở đây với tuyên bố của bạn. "It's structural type system is better than the type system Java had back when I was coding in Java, and it's much better (as in more reliable and flexible) than C and C++. " I can not take that. How? can you examplify? Some Facts (with obviously answer in no) - Why did Node inventor used V8 engine which was made in C++ to power node, if the js type system was so flexible and much better? - Can nodejs decode vp8 codec video by itself as efficiently as C/C++? - Could you build nodejs on top of pure javascript instead of C++? - Is there any such thing as pure javascript? You really have to understand my friend that it is a type system that can take advantage of underlying hardware and makes your program efficient at CPU and memory. Strongly typed C++ can solve any problem, even build node js. Node shines at non-blocking i/o and that is about it, it can not do anything else. Yes you can chop-off node code and make it work on micro devices but will it be efficient and make sense? Can you make product like node where you have to code in C++, yes you can but it would not make sense as power of C/C++ in not in web, its optimizations and hardware. It not like non-blocking I/O is something new, we have had that in many technologies including java, . Net, basic, python and perl, this is very old. The only reason why this thing is in limelight is it has enabled millions of frontend javascript developers, who do not understand pointers and bash about C++, to write server code, which is simply overwhelming, that's why the buzz. And about "Node in particular are actually very well suited to handle distributed computation", why on earth one would write such a statement? Node is not made for computation. it can not compute as efficiently as C/C++/Java. Period. With all due respect, lets not bring C++ in picture here, there is simply no practical comparison at all, or it will be very touchy

adroittech

Eric Elliott

You may be interested in this. https. //medium. com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6

Eric Elliott

You may be interested in this. https. //medium. com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6

Ken Kopelson

Actually, Javascript in the V8 server engine is QUITE fast. The statement that Javascript is not fast is outdated. You combine Node with Chrome and you get a very fast environment. If you understand how Node works, it has an event loop that processes all code that is ready to run. So, you call a function that has a blocking database call inside and a callback when finished, it allows the the function to be called, which returns immediately allowing you to get on with other things while the database call is being processed. So you aren't "hurry-up and waiting" as you suppose. You get on with other things, and once the database call finishes, execution will continue to the callback which is invoked after the database call returns. So, you get the same basic abilities as a multi-threaded environment without all the extra overhead incurred by thread-state swapping. Because you don't get "time slicing" you have to be careful that no piece of code takes too long to run, and if it does, you just break it up using packages like "async". I come from a long C, C++, Delphi, Java background, having mastered the multi-threaded paradigm, and I can state assuredly that the Node single-threaded async paradigm is super cool, fast, and highly scalable. IF YOU KNOW WHAT YOU'RE DOING. But that's the same for any of the other technologies as well. None of these technologies are for neophytes

Ken Kopelson

A complex application is precisely where well tailored Domain objects and properly decoupled subsystems are most necessary. If you are spending all your time trying to get the ORM to work you should either learn that ORM better or get another ORM. I would assume the former goes without saying so if you are still fighting your ORM it's time to choose one that just works

Excepting your last comment that these technologies are not for neophytes, I think you are ignoring the last two paragraphs you were responding to. Even the founder of node. js says to avoid compute intensive operations. Yes, V8 speeds up javascript, but that doesn't solve the problem of a compute intensive operation or IO dependent operations blocking a single thread. You then respond that node. js is non-blocking and therefore it can be awaited. Great, I got that, sure, but what are you waiting on? Some code that isn't written in node. js apparently, (so much for the claimed benefit of "one true language to rule them all"), because your single threaded node. js process is happily moved on to something else until the callback. So, node. js works great just as long as you can rely on other processes handling the workload that is blocking (like waiting for IO), or another instance of single threaded node. js, that will (if written "correctly") undoubtable kick the can down the road to yet another process. And that's the issue. there are a limited subset of stuff done in programs that can be executed in parallel/out of order, and/or doesn't rely on blocking operations. Multi-threading is more complicated and has some overhead every time there is a context switch, but it means that more cores can be thrown at parallelizable units of work, and even discrete operations can be handled by the different threads. In a "node. js solves everything" world, you are either relying on something not written in node. js or waiting for your single threaded node. js application to finish up all the stuff that must be done, one way or another

Ken Kopelson

You know what? You seem to just like spouting on about something you are clearly not qualified to speak about. You obviously have never built anything serious in Node. js. Well, I have, and I can tell you that it works great if you actually program it correctly. That means you use things like job queues, you use the clustering that Node provides, you make sure you do everything with callbacks and promises, you use "async" and "setImmediate" to properly share the processor between code that is waiting and code can now execute, you make sure UI code has priority over CPU intensive code, etc. For example, I wrote an "async" heap sort algorithm that works great, sorting massive lists while not blocking for any appreciable amount of time. I also have a 5000 line heuristic algorithm that is quite complex that I split up so that the main loops are executed using async constructs. I then have these executed from a job queue called "Kue" that allows for efficient use of all cores, no threads, great UI response time, and complex calculation jobs being executed in the background using all available processor power. This is ALL done in javascript with excellent performance in both CPU intensive tasks and response to front-end data requests. In other words mate, the UI is super responsive, and the background processing (complex heuristic calculation) performed quickly and very responsively. This is all done with a single language for both backend and front end, which is a huge deal when it comes to system architecture

Ken Kopelson

Jacob Ross

Why are they not for "neophytes"? Is it alcoholic?

Jacob Ross

Why are they not for "neophytes"? Is it alcoholic?

Jacob Ross

I agree. Most times that I think an ORM is inadequate for complex queries, I write out raw SQL, later to find out the ORM has an "app for that". I like using an ORM as much as possible, but I won't spend too much time making it work for me, otherwise, as M said, I'll find another ORM

Jacob Ross

JF80

Sounds like the words from a "Michael" I know. ;) I agree with your last statement. "each technology has it place". But why do you assume all Node developers are front-end developers with no back-end knowledge? Why is it NOT possible for these developers to make a scalable solution? Like or not Node is being used in Enterprise today and will continue to be adopted

JF80

TerraT

Javascript is a poor choice of language for enterprise/complex development. It is messy, difficult to read, difficult to organise, doesn't support an entire raft of OO paradigms that save a lot of code repetition and provide readable abstraction, predominantly gives run time errors, no AOP, no by convention, no reflection, no generics/templates, no precision of scope, no rich low level processing, and it is not type safe. We are stuck with it in the browser, and frankly it is only inertia and legacy support that means it is still used there. In all rights it should have gone the way of the dinosaurs 10 years ago. The main driver to move away from scripting languages was that they were a maintenance nightmare and led to ball of mud applications that had constant bugs that couldn't be tracked. It has only been a short 10 years since we breathed a huge sigh of relief when serious development moved off of scripting languages and here we are doing it again unwilling to learn from the past, convinced that this is "new and cutting edge", rather than just old, tired and regurgitated. It will end up the same way as it did last time, being talked about with disgust like classic asp and perl cgi. I can only conclude the developers championing it now were just not around to see the fallout of this last time around. Every new generation of developer is convinced they have discovered "the truth", those of us who have seen this cycle of pain just have to sit back and shake our heads in disbelief. Unfortunately you can't teach experience, it is something you have to learn the hard way. Sure if you are an amateur and know nothing else then by all means, but anyone trying to do a professional job needs to leave this alone and stop making populist technology choices without considering the outcomes. If you can't evaluate the long term limitations of a technology for yourself you shouldn't be working in development. Developers need to stop being so childish, acting like a bunch of deluded fan boys, this is a serious business, not a game

TerraT

adroittech

OMG. Eric . Are you for real? Do you even know how Nodejs works? Did you even try to look at backbone of Nodejs? Just download yourself a source-code and checkout. IT IS IN PLAIN C/C++. http_parcer is C++ lib. libuv is another and single most important C++ library in nodejs backbone which makes nodejs async, event driven and non blocking. Javascript by itself is body without a soul and life. JAVASCRIPT is just a script that you use to script your logic. One day if smeoene ports lua with this libs, he will not need Javascript to code. same for python etc. But the basic fact remains the same. IT IS C++ code that makes what nodejs is, not that javascript is too fast. in fact javascript is slowest in all of the scripting language. So don't flatter yourself in believing that just java-script is great and other things are shit. And do not insult C/C++ if you have no knowledge of it. So, again, i urge you to take back your words. "Javascript type system is better then C++". (Javascript has no type system. and if you still believe that it has one, you are in a very wrong field, go build some scaffolding) Also, these companies are not choosing nodejs for the reason you mentioned. This is possible in almost all languages. The reason why companies are choosing nodejs is that, they get ready made javascript coders, which are in millions and can not do c++/java code, to do server side because it is cheaper. Another reason -> its ecosystem. Yet another reason -> Its lot easier to conduct load tests in nodejs than other scripts. Liên kết bạn đã đề cập là công việc dự định sẽ được bắt đầu. Why do not you suggest them that please write this web-assembly compiler in nodejs rather than c/c++/assembly because according to you that is superior. C'Mon man, how can you compare Nodejs (A technology) with a C++ (language) they are not in the same league. C++ makes node possible, its not visa versa

adroittech

oberona

"The main driver to move away from scripting languages was that they were a maintenance nightmare and led to ball of mud applications" -- could you clarify what you mean by scripting languages, and what replacements "serious developers" migrated to over the past ten years? I was pleased to see a reference to Django in the article and have not run across maintainability issues caused by the use of Python, SQL, or ORMs in general. On the contrary, Python is my go-to language precisely for its maintainability. Your criticisms of js are spot on, but I can't see how they apply across the entire universe of scripting languages

oberona

TerraT

Well I define scripting languages as runtime compilation languages, but there is a lot of overlap these days. I prefer the reassurance of compile time verification of at least coding accuracy but that is not the only factor. The depth of invasion into the inner workings of the compiler that tend to be exposed by compiled languages these days allow for a whole range of design constructs and patterns that allow programming to be more "intelligent", I just don't find this level of sophistication in the scripting languages I have used. It is a severe limitation for serious enterprise development. ORMs are an ugly approach to data access on relational databases, but you would probably have to be a database developer to realise why. Data design and Program design have different constraints, ORMs do either an injustice or have to be modified so much that they provide no productivity. There are many issues such as security, isolation, atomic operations that ORMs break, and remember a database is a living system and may require changes in between code releases as a matter of course. ORMs are a blunt tool if you want real performance from your database and want high concurrency without locking. Its a detailed subject I could probably write a book on it, so sorry if this isn't conclusive enough for you. Can't say much about Python other than I have heard good things in general. I'm the other end of the market on . Net, I crucify the open source guys next door in productivity and my defect level is about 1% of theirs. I think you need a large system before it makes significant differences, as you need to invest in framework and substrate to get the main benefits back, its "mass coding" that is the enemy here. When you have over a 100,000 code files you need a higher level of maintainability as it is simply beyond human capability to do it file by file (and certainly beyond maintenance budgets). By making core services that consume code as content you can achieve a high level of quality while keeping everything granular and ensuring release are small and targeted rather than entire system drops. Each to their own, but if you are an IT pro you must have seen the millions of script based systems festering away in businesses because no one can find anything or understand how it works. It's such a common complaint I should think it doesn't need justifying

TerraT

P. S. I think "serious developers" have migrated to either Java, C# or back to C++ (along with their associated web techs etc). I wasn't really intending to be derogatory but these three probably account for 90% of all commercial development atm. C# wins out on the commercial front for me solely on Microsoft's considerable ongoing investment and new found modernist approach. C++ is not very productive and Java is really starting to look a little dated. Still I work in all three and they get the job done, each have their place

TerraT

P. P. S. "Python is my go-to language precisely for its maintainability". What do you consider maintainability? It is often not what people think it is (or is not as simple as they think). It encompasses the cost of change and that is the primary cost on the business for a living project. Example. I have a service with 1000 public methods and the business asks me to de-prioritise all calls that take over 2 seconds. If I have to modify any of the code in those 1000 calls then my code has seriously poor maintainability. What I should be making is one code change in my service substrate pipeline. I should not even be modifying the substrate I should be probably writing a statistics module and a de-prioritise module for that substrate loaded in a separate dll that can be loaded dynamically. Now my testing is isolated to just this dll (reverse harness testing) and when ready for release I can add this dll and maybe make one small config change, that's it, no regression testing and no risk to existing code, so no production bugs in the service methods. So many typical code bases would require all 1000 methods to be altered or at least marked for an AOP operation. Enterprise design requires upfront anticipation of future "crazy" business requests. I find with most scripting languages and even with Java that finding insertion angles later on is nearly impossible. Even if I have a complete mare in C# I can emit the code directly into the methods using reflection, I have never seen this level of access on a scripting language and even if it was there it would be dangerous code to emit into runtime compiled operations (because I am literally changing the operations content so I would need to test the result of each). This is just one example I could probably come up with 100s. I'm a technical architect (framework and substrate) so it is my place to "save" my devs from backing themselves into a corner. If I do a good job I can reduce the coding and testing effort to 1% of a "mass coded" system. There is a whole other level of development that most devs will never see or appreciate, this means they are never equipped to make the most appropriate technology choices

TerraT

Josh Morgan

Interesting article, I've got quite a bit of experience in other realms but I'm somewhat new to Node. js. There's a few things I'd like to clear up. Flash was always async as well, it merely emulated threads much like it sounds like node does by using an event queue. However, I believe it is technical ignorance to claim that trusting thread management to a 3rd or 4th generation language would be better than trusting a well-tuned JRE or operating system optimized for it's multi-core chipset. How exactly do you think threads work in the lower levels anyway? It isn't some "magic", the only way to get true simultaneous code execution is via multiple processors, something you simply can't accomplish with a single thread. It's also a mistake to say that a new "event" does not add memory or clock cycles taken to a stack just because said events are managed by an interpreted scripting language rather than optimized, compiled C++. I'd bet my lunch that a well-written multi-threaded web application written in C or C++ will blow away any node. js hiệu suất khôn ngoan và thậm chí không cần truy cập vào máy chủ và kiến trúc bộ xử lý đa lõi hiện tại của chúng. If you've got a quad or 8-core server running a single node thread. you're only firing on one piston (quite ironic that Google calls their engine "V8" when considering such a fact). Another thing to realize is that while Flash (or even Java applets) ran in their own runtimes, so does node -- it's just hidden to the user. That is nothing more than "good" (perhaps hostile?) business moves on Google's part. Lets be honest here, if all browsers came with Flash automatically installed on them, and Apple actually supported Flash on their mobile devices, node probably wouldn't even exist today. I have other concerns about security. What kind of protection does it have against cross-site scripting and other attacks? Earlier today I stumbled across a TOR/Bittorrent client that ran in my browser window, and after opening it my computer wouldn't shut down nicely (it scares me to think what it could have been seeding. ). No warnings about security or what types of connections my browser window was opening up, just went along with it's P2P business. the hacker side of me could have a real hay day with those kind of "features". I doubt that kind of stuff has been tested much either which means there's a lot of room for bugs, and where there's a lot of room for bugs there's a lot of room for vulnerabilities. But hey, at least your entire stack is all in the same language. Means you can hire less experienced developers for less money, right? ;)

Josh Morgan

iwebworld

Good Article for Node JS, you can learn Node JS online in http. //iwebworld. info or send a email iwebworldinfo@gmail. com

iwebworld

Good Article for Node JS, you can learn Node JS online in http. //iwebworld. info or send a email iwebworldinfo@gmail. com

Avinash Shah

You could remove all the pitfalls of JS by using the its superset aka TypeScript

Avinash Shah

You could remove all the pitfalls of JS by using the its superset aka TypeScript

evanplaice

Tl;dr Use node for IO-heavy processing and delegating CPU-intensive processing to a cluster of specialized worker nodes (ex database, media processing, etc). This isn't exactly new information. I covered this topic back in '12. http. //programmers. stackexchange. com/a/179499/1256 Ideally, the HTTP and API servers should be mostly stateless (excl session management) and disposable. They're just a functional pipeline that translates the raw data into consumable representations. That way, the servers are easy to provision/destroy dynamically to meet the spikey nature of demand. I'm not sure why so many of the commenters are vehemently arguing in favor of multi-purpose vertically-scalable server architectures. By nature, vertical scaling will always have an upper limit predicated by hardware capacity. No matter how efficient the code is. The writing is on the wall. You can spend a fortune on hardware and lose sleep questioning the validity of your risk assessment (aka WAG). Vào cuối ngày, kim loại trần là một tài sản cố định. Best case, it meets expected demand and justifies the cost. Worst case, it either costs more than it's worth or lacks the capacity to meet demand. Alternatively, you can embrace distributive computing and automate the infrastructure to grow/contract relative to demand. For the people fighting religious wars over which language is best, node . C# . java. Who cares. All 3 allow 'functional-style' programming. All 3, support async processing (natively or through extensions). All 3 can be managed via provisioning. All 3 are perfectly valid for building distributive infrastructure. Choosing which one to use depends on the quality of the tools, whether or not it will be used to extend existing infrastructure, and the perception of the client. Build whatever you're good at building. If you're really good; build whatever is easiest to implement, support, and generate the most profit (or save the most on cost). BTW, kudos to the author. It's nice to see somebody do a comprehensive (and mostly objective) writeup on this topic

evanplaice

Yes, both languages support horizontal scaling with asynchronous message management infrastructure. CQRS is nothing but an API implementation pattern. CRUD is the typical use case (as it should be) but Node doesn't automagically scaffold 1. 1 mappings between DB and CRUD (see rails/laravel/django for that). Node isn't a framework at all, it's just a HTTP server. You can leverage frameworks (ex Express) to make life easier by providing sane defaults and better structure but you still have to manually specify your API routes. . Net Reactive Extensions have been ported to JS. https. //www. npmjs. com/package/rx In fact, even LINQ has been ported to JS (yes, seriously). http. //linqjs. codeplex. com/ "Any application that can be written in Javascript, will be written in Javascript" - Atwood's Law ORMs are only an issue because they require an additional layer of abstraction from the underlying data. If (read when) the data models need to change to adapt to business demands, both the ORM and the database schema will need to be updated and tested to reflect the changes. Which is not really a big deal if there's a good update strategy in place. As for the rest of your comment, you'd do well if you stepped out of your comfort zone once in a while to see how JS development really works. 1. JS classes are currently supported now via ES6 (also, available client-side via polyfills). Prototypes really aren't much different than classes in terms of encapsulation (except they're a lot more flexible). Compile-time static type checking is even supported via TypeScript/Dart if that's what floats your boat, it's just not the default. 2. TDD/BDD isn't a feature exclusive to statically typed languages. There are a lot of great testing frameworks available in JS (both server/client-side). Choose your flavor, unit testing (Mocha), behavior driven unit testing (Chai), api testing (SuperTest), and continuous integration testing (TravisCI, and many others) are all used extensively throughout the community. JSUnit (the JS equivalent of JUnit/NUnit) is even available if you miss unit testing in Java/. NET. If anything, testing is a basic requirement of any non-trivial JS app that goes into production because you don't have a compile-time type checker to hold your hand. 3. Complex workflow? Seriously? So, you've never heard of NPM scripting, grunt, gulp? Automating any-and-everything in JS is pretty easy. Style enforcement, linting, documentation generation, scaffolding, one-click-deployment, language transpilation, bundling, distribution building, package/dependency management, release management, etc. 4. . cringe. if you rely on the compile-time static type checking system alone to validate user input, you're doing it wrong. Building a data layer in any language requires constraints above-and-beyond what the default types provide. So, either way you'll have to extend your data models with custom validation checks. The cool part about handling validation in JS is you can use the same routines to check user input on both the client/server-side. Ít trùng lặp nỗ lực hơn FTW. Contrary to what you think. Javascript really is a 'one size fits all' approach if you prefer to use it as such. Seriously, you can even compile C/C++ directly to javascript using asm. js. Does that mean you have to use it? Of course not. Any developer with a speck of sense wouldn't fault you for choosing C#, it's a great language. I have experience writing code in many languages, including building non-trivial desktop applications in C#. Given a choice, I'd prefer to use Javascript. The mix of, looser constraints and functional/imperative/prototype styles allow for a level of creativity I haven't experienced in any other language. The tools are great, the module system is amazing, and the language itself is getting substantially better with each update

evanplaice

Upload Files. http. //howtonode. org/really-simple-file-uploads "All the I/O operations is handled by Node. js is using multiple threads internally; it's the programming interface to that I/O functionality that's single threaded, event-based, and asynchronous. " http. //stackoverflow. com/a/22981768/290340 Libuv uses a thread-pool to handle I/O operations (files, sockets, etc) in an asynchronous manner. Where most languages block by default during CPU-heavy I/O operations, Node doesn't. It simply fires an event when the I/O operation completes on the worker thread. Active Directory. https. //github. com/gheeres/node-activedirectory https. //github. com/auth0/passport-windowsauth

evanplaice

The distinction is that Node is async by default So, the number of developers doing async programming in other languages are the minority so they're not as well represented. "I can't come up with any good reason to use it on the server side in favor to other available languages. " Not gonna lie, using Node at first was. Challenging to say the least. Getting used to async-by-default is not an easy transition. The nice part Node is, the primary focus of the platform is building servers/clients so the ecosystem has a lot of powerful tools to do anything dealing with web development. ". have better standard libraries, tools and resources. " I'm not sure what gave you that impression. It doesn't use the monolithic-everything-and-the-kitchen-sink base class library approach. The core itself is very small but that's a benefit as it's much lighter to deploy. It also includes a very powerful, full-featured package manager by default so you're expected to add the dependencies your project needs. NPM (Node Package Manager) has over 200K packages and counting. Since the majority of the modules are developed independently from the core, they iterate and improve much faster than the equivalent core libraries in other languages. Dependencies are managed locally on a per-project basis in the package. json file. Typically, it's bad form for a module author to require that their package be installed globally. Installing packages locally prevents version conflicts at the global level and guarantees that -- when you install a package -- everything required to use the module is included. It may seem inefficient at first glance because many dependencies may have copies of the same sub-dependencies (or sub-subdeps, etc) but compared to the cost of including a massive standard library, the storage space is insignificant. The workflow to setup a project is. - clone the source - run 'npm install' NPM will automatically download and install all of the dependencies (incl sub-deps, sub-sub-deps, etc). Since the dependencies (and their specific versions) are explicitly defined in the config, you don't need to check them into source control. In addition, with ES6 (incl the new ES6-module-loader) about to be released, a new JSPM (Javascript Package Manager) has been created to manage client-side javascript dependencies. Module imports in the browser have finally been formalized in the language spec, so Bower and the variety of module-loading pseudo-standards (ex AMD, CommonJS, UMD) will go away

evanplaice

TerraT

As said above modern OO languages have a vast array of options to formalize and control your code and solutions that are lacking in scripting languages. That's just the plain truth, no amount of griping is going to change that. My point is there are a lot of developers choosing technology by popularity rather than suitability, that's what makes them fan boys. Công cụ phù hợp cho công việc phù hợp, áp dụng trong mọi giao dịch ngoại trừ phát triển phần mềm. But that is probably because most developers aren't true "Tradesman", more glorified "DIY'ers". The industry is full of amateurs who don't even know enough to know that they know nothing. They think because they can write an if statement and a while loop they are pros. Techno-weenies

TerraT

evanplaice

System level I/O operations (such as files, sockets) in Node are handled by libuv which does use a background thread pool. The difference is, the main thread can fire and forget the task to a background thread and the background thread will notify the main thread (via firing an event) when the operation is completed. Even with background thread processing, doing lots of I/O operations doesn't scale very well. For long-running CPU-heavy tasks (ex image/movie encoding) offloading the tasks to worker nodes is still preferable. In most languages, I/O operations are handled in a synchronous manner so if they requests are made on the main thread, they'll block execution until completed. The reason you don't see a noticeable pause in the UI when this happens is because the UI is asynchronous/event-based and runs on a thread separate from the main context

evanplaice

There's nothing stopping you from exposing the API as a microservice. WebKit just allows you to run a native JS client. I may be wrong but from what I understand, unlike the browser a webkit client isn't as strictly sandboxed so you can make system calls (ex to open/save files without user input)

evanplaice

TerraT

I think you made my point for me, frothing unthinking, emotional nonsense, with very little in the way of fact, from a mind so fanatic about one thing it can't even see its failings. You seem to have made a fair few assumptions about what I do and don't know, I have been doing Javascript for 20 years, I know its short comings, I can work effectively in probably 30+ languages, I use what is appropriate, I never indicated otherwise. You need to grow up or find a new industry to work in. People like you are the problem with Software Development, know nothing nobodies who can't even make a case for a technology, let alone use one. Please stay away from the keyboard and do the rest of us a favour

TerraT

evanplaice

Do you use version control with a standard workflow (ex Gitflow workflow) where developers make changes on feature branches and code is peer reviewed before being merged? I've been messing around with trying to build an Angular2 website lately and the Angular2 project is still in early alpha so breaking changes are a regular (albeit unfortunate) occurrence. All of the available examples online are pretty-much broken so I've been monitoring the project development on Github. The rate that the core developers are thrashing on the codebase is truly remarkable. What's even more amazing is that every PR is unit tested and continuous integration tested well enough that every release is guaranteed to be fully functional (as far as they've implemented it so far)

evanplaice

Following what Tracker1 is saying. Linting is the equivalent of compile-time checking in JS. I even use a Sublime extension that shows linter errors directly in the gutter of the editor as I'm writing code. If you want stricter checking you can add a style checker such as 'semistandard' which guarantees code styling on a project-wide basis. That means, spaces-not-tabs, indent 2 spaces, consistent functions, curly braces, etc. Type checking is good for superficial bugs (ex uninitialized variables, dead branches, invalid values) but eventually you'll have to verify the code doesn't have logic bugs through unit testing, continuous integration testing, api testing

evanplaice

Node uses async event-based I/O via libuv (incl a thread pool reserved for I/O requests). The main thread absolutely does not block during I/O operations. It works the same way cluster would except it's built into Node. Check out one of the presentations on libuv for more details

evanplaice

Performance wise, PayPal seems to think good things about Node http. //dongnotes. blogspot. com/2013/12/paypals-nodejs-versus-java-benchmark. html For security, the 'cors' module is pluggable to Express and can be used for all the usual CORS control stuff. The 'helmet' module -- also pluggable to Express -- exposes a small suite of features to protect against malicious users including additional cross site scripting protection. I'm not sure if I'd call a Fullstack JS dev 'inexperienced'. Having a solid understanding of multiple domains in a development ecosystem that is constantly evolving is maddening. ya know, "10 years of experience vs 1 year of experience 10 times"

evanplaice

Josh Morgan

Node. js hasn't even been around for 10 years (which is funny considering I have seen job postings actually asking for 10 years experience with it). I understand that following evolving technology is a challenge, and after 20 years I can tell you that by the time you get completely comfortable with any "full stack" it will be less relevant because technology is always advancing. Nothing will change that, it's just how things work. However, you can't really have your cake and eat it too there. Newer technology is less tested and therefore less secure, but older technology does not have as many features. There's always a trade-off there. Anybody who claims otherwise is selling you something

Josh Morgan

Anil Verma

I am sold on Node. JS (if your application is into building high scalability networking applications), Node. JS is the way to go in 2015. No wonder why so many startups and large corporations are adopting it. C++, Java, Ruby and Python havew their place in their respective domains. New companies and products will be getting built on wide variety of languages. I predict ROR adoption would still be high in coming years for building web applications (simply because ROR developers are easily available and time to market is so small). Excellent article though Tomislav

Anil Verma

Daniel Jawna

So true. My job is the maintainance of legacy apps usually SQL Server dB's + ms access or php fronteds. These were usually made by "the grandson who is good with computers" Kind of guy. No foreign keys, but custom date + time functions. Your post is my sentiment exactly

Daniel Jawna

JPoet

I find Java very unproductive and very expensive for a lot of low level tedious work. C++ is for programmers who can handle memory access/pointers. Most corporate programmers cannot. Back in the day you had PL/1 and C for software engineers and COBOL for information technology programmers

JPoet

joselie castañeda

thanks. this is so helpful as i am going to make a heavy-computation enterprise application. i think i'll try node. js on other application. for now, i'll use ruby on rails

joselie castañeda

thanks. this is so helpful as i am going to make a heavy-computation enterprise application. i think i'll try node. js on other application. for now, i'll use ruby on rails

Túlio Spuri

When this article was written ?

Túlio Spuri

When this article was written ?

armandoali

Great article

armandoali

Great article

Olivier

Thanks for this article I think than the argument of same langage for front and dev is the worst I can liste or read. Organized à good coding with js is the more horrible things append in a team. I work since last year on backend project and where this should be coded in some times with mature framework like django it took too much time understand hundreds bugs. Where mongodb feels cool ? Never. I realy thinks than nodejs is a big joke and not So cool. The package manager give us some cool package to patch and hide the bad side of node but there is nothing to do about the callback hell. Finally the code looks like a big sand box than i hatte to open a file for debug or add some lines of code. So my conclusion is than for small app why not but for big and evolutive project not use nor nodejs and mongodb. Regards

Olivier

buffonomics

This is a fairly ill-informed comment as ES6 was alive and well as at a year ago. Besides the OO from ES6, there is also TypeScript which adds even more enterprise-level OO and enforcable static-typing to JavaScript. Like . NET is compiled to raw clr, TypeScript may also be "transpiled" to raw Javascript. NodeJS allows for pretty much all of this now with an even still better utilization of server resources and no OS lock-in. Think cutting your infrastructure costs by over 2000% because you really don't need to scale too vertically or pay for those . NET licenses per node of scale. Even if you were going the Mono route, lol. I'll let you research how that compares on your own. Fintech companies like Paypal that know a thing or 2 about load are happily doing great things with node as well so I highly doubt this comment of yours comes from a place of knowledge about what the NodeJS eco-system truly has to offer the enterprising product built in "this era", with a focus in micro-services (in the true-est sense of the word) and not "monolithic services" as you might be more used to. Also no matter what personal opinions you may have regarding ORMs, the logical fact of it all is that ORMS use more memory resources than is needed to run a backend. Họ cũng đánh vào nguồn dữ liệu của bạn nhiều hơn mức cần thiết. You also said something regarding caching and ORMs to which I'm guessing you are referring to ORM-level caching (e. g. L1/2 Cache in Hibernate). I hope you understand that you don't actually NEED ORMs to do your caching for you. You can do this using efficient and beautifully-decoupled tools. and at that more flexibly. It's important to keep in mind that, even now, someone out there is still defending Fortran as the one true tool to building software. Things move quite fast in this industry. The pride is understandable, but my recommendation to you is to get involved in at least 1 new technoverse every couple years at most. You'll stay relevant and thank me later

buffonomics

I really wanna be able to try out Node. js but it's such a pain in the effing ass to get something running. Installing a "simple" app always turns in to a list of things you need to do, install shit globally (which is NOT always possible), edit files, try to figure out what the damn devs mean in their scant instructions. It quickly goes to shit if you do the slightest thing wrong. If it's so great why hasn't anyone figured out a way to make simple installers with this thing?

Alexis Menest

Ghost blogging platform https. //github. com/TryGhost/Ghost/blob/master/package. json

Alexis Menest

Ghost blogging platform https. //github. com/TryGhost/Ghost/blob/master/package. json

David

Vâng, thật tuyệt nếu có một buổi hẹn hò. Tôi cho rằng họ không hiển thị nó vì họ biết mọi người có thành kiến như thế nào đối với thông tin mới - nhưng sẽ không có ý nghĩa gì nếu che giấu nó trong một bài báo về công nghệ đang phát triển nhanh chóng

David

Samuel_Ogden

Nút sẽ là một ý tưởng tồi cho một cái gì đó như 9gag. com thì sao?

Samuel_Ogden

Nút sẽ là một ý tưởng tồi cho một cái gì đó như 9gag. com thì sao?

chaitanya

Này Tomislav, Bài báo tuyệt vời. Tôi muốn biết rằng nếu giả sử tôi muốn nhận đầu ra phần cứng bên ngoài trong ứng dụng của mình, e. g, máy quét hoặc chữ ký điện tử (nếu người dùng đang thực hiện chữ ký điện tử hoặc nhận bản sao được quét từ máy quét), thì tôi có thể truy cập trực tiếp vào ứng dụng của mình không?

chaitanya

Misha R

TypeScript là trình bao bọc cú pháp trên JavaScript tiêu chuẩn và biên dịch thành JavaScript tiêu chuẩn. Nó được phát minh để làm cho mã có thể bảo trì được và cho phép nó được sử dụng giống như một ngôn ngữ lập trình thực sự. Cho rằng bạn phải sử dụng JS khi thích hợp, nó làm cho việc viết nó trở nên quen thuộc hơn với các lập trình viên thực thụ và làm cho nó có thể bảo trì được. Điều đó nói rằng, mọi thứ JS và Node đều phù hợp với các ứng dụng web mỏng, nhẹ cần được kết hợp với nhau một cách nhanh chóng và hiệu quả, cho những thứ như ASP. NET, JSP, Ruby, v.v. hơi quá mức cần thiết. Tin rằng người ta không thể sử dụng Node thần kỳ mới cho mọi thứ chỉ vì một anh chàng có thể viết cả front và back end là nghiệp dư

Misha R

ellisgl

Đóng gói một ngôn ngữ bằng một ngôn ngữ khác mà bạn phải dịch sẽ thêm chi phí. Ngoài ra có những thứ không dịch được, chỉ là trong cuộc sống thực, dịch giữa các ngôn ngữ, bạn mất một cái gì đó. Trong trường hợp này, bạn mất tốc độ (phải dịch từ cái này sang cái khác) và tối ưu hóa, vì lý do một. ORM không làm tất cả. Ban đầu, tôi dành cho ORM, sau đó tôi tìm hiểu sâu về nó và bạn kết thúc với câu "Tôi làm điều này như thế nào?", "Ồ, bạn không thể dễ dàng, bạn phải thực hiện 10 truy vấn khác", hoặc bạn kết thúc . ORM đơn giản là "Chọn blah blah từ bảng trong đó x = y". Yếu tố đổi thưởng nhỏ duy nhất của một số ORM là chúng sẽ chuyển đổi ngôn ngữ của chúng sang bất kỳ DB nào. Nhưng nếu bạn được trả tiền để làm việc trên một ứng dụng cấp doanh nghiệp, thì bạn chỉ đang xử lý 1 - 3 cơ sở dữ liệu, được sử dụng cho những thứ riêng biệt. Nếu bạn có 500 nhân viên và 10.000 khách hàng, ORM có thể bị tắc nghẽn

ellisgl

quả cầu Nils

Này, có thư viện/công cụ nào bạn đã sử dụng để tạo đồ họa không?

quả cầu Nils

Này, có thư viện/công cụ nào bạn đã sử dụng để tạo đồ họa không?

Praveen kumar Pamani

Cảm ơn bạn vì bài viết này, tôi sẽ đề xuất bài viết này nếu mọi người muốn biết node là gì và chúng ta có thể làm gì với nodejs

Praveen kumar Pamani

Cảm ơn bạn vì bài viết này, tôi sẽ đề xuất bài viết này nếu mọi người muốn biết node là gì và chúng ta có thể làm gì với nodejs

dohkoo

Bài viết hay, cảm ơn vì cái nhìn tổng quan. http. //www. steshadoku. com

dohkoo

Bài viết hay, cảm ơn vì cái nhìn tổng quan. http. //www. steshadoku. com

subkuchsell. com

thanks for great article really very helpful to understand the node. js subkuchsell. com

subkuchsell. com

thanks for great article really very helpful to understand the node. js subkuchsell. com

Tomislav Capan

Yes, this is true, article was authored and published in August 2013. (sorry for such a late confirmation, haven't seen this earlier)

Tomislav Capan

Yes, this is true, article was authored and published in August 2013. (sorry for such a late confirmation, haven't seen this earlier)

golfman484

In what universe can Mongo DB be referred to as an Object DB? It doesn't support inheritance. It's a Document Oriented DB not an Object Oriented DB. I just don't want any of the kiddies to get confused

golfman484

We switched to one language for backend and UI but we decided to keep the language that runs lightning bolt fast at runtime and has type safety and supports standard ORMs with lazy loading etc. , We didn't want to throw all those things away, which is what you have to do when you go with a JS solution on your backend. Java on the backend is a no brainer (so long as you don't over engineer and over complicate your app with memory and CPU sapping Spring). The key to using Java for the UI is use a Java framework that does all the JS for you - so you can live in a world devoid of having to deal with JS and stick with compiled, typesafe, enterprise suitable code. This solution is also scalable - J2SE has supported clustering for nearly two decades now. One such Java UI framework that covers all our JS needs and gives us all the 'partial updates' goodness with an AJAX event driven model with websockets option is Wicket

golfman484

Rumana Amin

Hi Tomislav, your article is really nice and informative. It helped me a lot to understand Node. js và nó sử dụng

Rumana Amin

Hi Tomislav, your article is really nice and informative. It helped me a lot to understand Node. js và nó sử dụng

WarrEagle

The simple answer is do not use Node. js for that. What part of that are you missing? You want to serve GEO data coordinates to 500K connected clients?. easy. Do a massive JOIN statement across a million rows on a RDBS? You're screwed. Surgeons do not work with chainsaws. Neither should programmers

WarrEagle

golfman484

You underate ORM as most of the people who have never built an OO system with a decent highly performant ORM that rocks do (and by 'decent' ORM I'm NOT referring to the ORM most people think of using, Hibernate. )

golfman484

I agree - this article and associated comments by the JS fan boys confirms my fears that most JavaScript apps must have anemic domain models (https. //martinfowler. com/bliki/AnemicDomainModel. html) that are quite trivial and virtually expression less - all the work will be done in disassociated (not encapsulated and definitely not polymorphic) business logic

golfman484

I'm guessing your experience with 'ORMs' is limited to Hibernate. I had a similar experience until I thought there must be better ORMs out there - look around - others exist

golfman484

I'm guessing your experience with 'ORMs' is limited to Hibernate. I had a similar experience until I thought there must be better ORMs out there - look around - others exist

golfman484

Good points Adin - I was about to make the same ones. In regard to the article's claim that traditional frameworks "spawn a new thread for each connection (request)". So, so wrong. Must have made more than a few people livid to see such an error which either a) the author knows is clearly wrong and persists with the view or b) has never used any other backend framework and so doesn't realize that he is so wrong. The conflation of connection with request is also interesting. Does his knowledge not extend to understand the concept of connection "keep alives". A connection does not have a one to one relationship to requests as he suggests. This kind of skewed, twisted view of how intelligent, mature, highly evolved frameworks (eg. , Java/Tomcat and I'm sure . net/ASP) handle requests makes me feel like this article is tainted and not representing the truth about alternatives. In regard to moving away from the Request/Response mentality - many existing frameworks have done this also and created a component oriented architecture that supports asynchronous model based updates. eg. , Java Wicket or Angular JS. It's almost like running JS (a type unsafe, non OO language - if you're a believer that manual, self assembly 'prototype' inheritance is in the true OO spirit) on the server is not a concept that has enough merit without twisting the truth about how traditional server side frameworks work. Nó là như vậy hoặc có thể nó là như vậy

golfman484

Not every client who has an active session needs to be allocated their own thread - threads are shared and each user only needs a thread to service requests. Requests come in in short bursts and don't need to tie up a thread for very long if the back end code is executing in a highly optimized, compiled language and a fast database. For this reason you can't say "System A can support 10,000 threads therefore it can only support 10,000 clients". The number of clients supported is orders of magnitude greater than the number of threads available because of diversity. Hầu hết các giao diện người dùng, nếu được viết tốt, chỉ 'điện thoại về nhà' cho máy chủ khi thực sự cần thiết - không phải "mọi lúc"

golfman484

Nó giống như nút. js mọi người nghĩ rằng JS là ngôn ngữ duy nhất hỗ trợ đồng thời (mặc dù họ quảng bá giải pháp máy chủ web một luồng -WTF?) và không chặn I/O - tất nhiên không phải vậy nhưng bạn có vẻ rất hào hứng với những thứ như vậy mà tôi có thể

golfman484

Tomislav Capan

Tất nhiên bạn hiểu đây là hình minh họa. Trong thực tế, đó là một nhóm luồng, bị giới hạn bởi bộ nhớ khả dụng và có độ lớn theo thứ tự nhỏ hơn những gì giao diện sự kiện có thể hỗ trợ. Cảm ơn vì nhận xét, mặc dù

Tomislav Capan

Trưởng khoa Radcliffe

Chết tiệt, đây là một oldie nhưng goodie. Tôi nói chuyện như thế này, và có thể mượn slide của bạn. Theo những ý định ban đầu này của nút để thực hiện những điều tuyệt vời như ghi db theo hàng đợi và đẩy máy chủ, thật ngạc nhiên là hầu hết các ứng dụng nút ngày nay vẫn được xây dựng trên mô hình yêu cầu/phản hồi và chờ đợi ghi db một cách đồng bộ (nhưng không theo khối)

Trưởng khoa Radcliffe

Ulyana

Nội thất tuyệt vời, cảm ơn vì bài viết. Nút. js có rất nhiều lợi thế. nó nhẹ, hiệu quả và cung cấp khả năng sử dụng Javascript trên cả giao diện người dùng và phụ trợ mở ra những khả năng mới. Tuy nhiên, nó cũng có nhược điểm bạn cần lưu ý. We have tried to describe some in the article https. //www. chuyên gia mạng. co/blog/pros-cons-use-node. js-backend Ý kiến của bạn sẽ được đánh giá cao

Ulyana

Maq Said

Điều tuyệt vời. MongoDB tôi chưa bao giờ khám phá. Bạn có thể nói thêm về nó không và tại sao nó hoạt động tốt với Node. js

Maq Said

Điều tuyệt vời. MongoDB tôi chưa bao giờ khám phá. Bạn có thể nói thêm về nó không và tại sao nó hoạt động tốt với Node. js

Misha Kov

Đây chính xác là bài viết tôi đang tìm kiếm, Ví dụ về nơi Node. js có thể được sử dụng. Cảm ơn

Misha Kov

Đây chính xác là bài viết tôi đang tìm kiếm, Ví dụ về nơi Node. js có thể được sử dụng. Cảm ơn

Jessica Barnes

Node.js has the concept of asynchronous execution of Input-output based events through a thread pool. And it concentrates in execution and topping well for low-CPU, highly I/O-bound operations. Just starting to work on Node.js will allow a developers to analyze how to exploit it for maximum performance.

Jessica Barnes

Janguk James Lee

Đây là một bài viết khá hay thúc đẩy tôi tiếp nhận Node. js

Janguk James Lee

Đây là một bài viết khá hay thúc đẩy tôi tiếp nhận Node. js

Magdalena Mbn

nếu họ không thể học cách xử lý con trỏ thì họ không thể lập trình

Magdalena Mbn

nếu họ không thể học cách xử lý con trỏ thì họ không thể lập trình

web đặt hàng

TwaT - bạn có thể cho tôi biết quán rượu / quán bar nào bạn ghé thăm để tôi có thể tránh bạn không. Tôi sẽ không ngạc nhiên nếu bạn OrgASM khi bạn đọc lại bình luận của mình

web đặt hàng

philippe

Tôi muốn có nhiều Java hơn cho phía máy khách hơn là nhiều Javascript hơn cho phía máy chủ. Tái cấu trúc Javascript là một cơn ác mộng. Bạn nào làm phần mềm 4000 - 10000 class như mình thì biết mình đang nói cái gì. Tôi thấy việc quản lý luồng là một điểm cộng (nếu bạn nhắm mục tiêu chạy một trang web như Facebook thì bạn không quan tâm. Nội dung tĩnh của bạn sẽ sử dụng đám mây bùng phát là 4000 kết nối CÙNG LÚC chỉ là lưu lượng truy cập điên cuồng nên tôi sẽ không ảnh hưởng đến khả năng bảo trì VS khả năng mở rộng) Ít nhất là không hợp lệ từ các ứng dụng mạng nội bộ. Tôi tò mò liệu phiên bản tương lai của Tomcat có sử dụng mẫu lò phản ứng hay không, bản thân Java cũng cung cấp hỗ trợ cho việc này. Bạn có thể xử lý nội dung tĩnh bằng Nginx có mẫu lò phản ứng được triển khai https. //www. pascaldimassimo. com/2011/02/10/java-and-the-reactor-pattern Vẫn cho các trang động, tôi chưa tìm thấy bất kỳ manh mối nào. Một chủ đề không giữ bối cảnh phiên vì vậy tôi thực sự nghi ngờ về việc có 2Mb trong đó. Trừ khi được mã hóa kém

philippe

Cody Donelson

Sự kiện mặc dù bài viết đã được vài năm nhưng nó đưa ra một số điểm tuyệt vời về Node. js. Đọc qua các bình luận, tôi đã thấy một số bài đăng về cách Node. js là một điều tuyệt vời và những điều khác về cách các ngôn ngữ hàng đầu là C#, Java hoặc Ruby. Chúng tôi biết rằng JavaScript sẽ mang đến một số phức tạp vì nó liên quan đến Lập trình hướng đối tượng, Ánh xạ quan hệ đối tượng, cơ sở dữ liệu quan hệ, v.v. Tôi nghĩ rằng hầu hết các nhà phát triển/người quản lý dự án đang đánh mất điều gì tạo nên JavaScript và Node. js (cũng như AngularJS) thật tuyệt vời. Chúng tôi có thể triển khai ngôn ngữ phía máy khách ở phía máy chủ và làm cho nó thực hiện chính xác như bất kỳ ngôn ngữ phía máy chủ nào khác. Cá nhân tôi thích sử dụng Node. js, mặc dù thật khó để tôi hoàn toàn chìm đắm trong một ngôn ngữ không có kiểu chữ. Khi tôi hiểu được thực tế rằng bầu trời là giới hạn đối với các đối tượng của tôi và tôi không phải ánh xạ các đối tượng của mình từ loại này sang loại khác (như bạn làm trong C# hoặc Java), khả năng viết mã của tôi đã thực hiện . Gần đây tôi đã dạy một vài kỹ thuật viên PC tại công ty mà tôi làm việc về lập trình. Sếp của tôi rất kiên quyết rằng Node. js là con đường của tương lai (đặc biệt là việc ngừng sử dụng các trình cắm Java trong những năm tới) Tôi có xu hướng đồng ý. Tôi không hiểu tại sao lại có một cuộc tranh luận như vậy khi có liên quan đến các đối tượng trong Node. js/JavaScript. Tôi thấy việc sử dụng các đối tượng dễ dàng hơn và tôi có thể sử dụng chúng linh hoạt hơn VÌ có JavaScript. Tôi sẽ sớm triển khai các thuộc tính HTML trong các đối tượng cho các ứng dụng Express 4 của mình. Tôi nhận thấy rằng PUG (trước đây là Jade) cực kỳ có khả năng xử lý các đối tượng và mảng, do đó, giúp ai đó dễ dàng thay đổi động loại, giá trị hoặc thẻ dựa trên đối tượng được gửi qua GET hoặc . I believe once everyone gets on board with understanding the way Node. js operates, how you can effectively implement standards that are usually enforced in typed languages, and over the fact that Node. js có một số điều kỳ quặc về nó, liệu chúng ta có thực sự có thể tiến lên phía trước và làm cho ngôn ngữ này trở nên mạnh mẽ như các ngôn ngữ trước nó không. Lastly, I'll add that the ability to utilize Node. js hầu như ở mọi nơi làm cho nó tốt hơn nhiều. Cho dù đó là ứng dụng Express được triển khai trên máy chủ Linux, ứng dụng Electron được triển khai trên máy chủ đầu cuối, Node. js thực tế là một sự phù hợp hoàn hảo cho bất kỳ khối lượng công việc nào cần phải hoàn thành

Cody Donelson

Gage Poon

Nhanh như chớp, nhẹ, phát triển mượt mà và hiệu suất tốt hơn, đây là một số thay đổi mang tính cách mạng do Node js mang lại trong lĩnh vực phát triển web. Node js mang đến sự tự do sáng tạo, nguồn tài nguyên phong phú như NPM (Trình quản lý gói nút), là thư viện chia sẻ các mô-đun và công cụ. Ngoài ra, các ứng dụng web được phát triển bằng khung phát triển web này có khả năng mở rộng hơn. This JavaScript framework is very popular among the startups. However, big names like Netflix, Paypal, eBay, Microsoft, Uber, DivBox. in etc. cũng đang sử dụng khung phát triển web giàu tính năng này

Gage Poon

rajivkumar bonam

what is node js how to write code in node js

rajivkumar bonam

what is node js how to write code in node js

Chế độ quân chủ dẫn đến tự do

Bài báo tuyệt vời, cảm ơn

Chế độ quân chủ dẫn đến tự do

Bài báo tuyệt vời, cảm ơn

csps1343

Nice node.js tutorials, thanks for sharing.

csps1343

Nice node.js tutorials, thanks for sharing.

Rahul Raut

thank you so much. learn node https://monkelite.com/what-is-node-js-learn-step-by-step/

Rahul Raut

thank you so much. learn node https://monkelite.com/what-is-node-js-learn-step-by-step/

Chương 247- Nhà Phát Triển Phần Mềm

"Why The Hell Would I Use Node.js? A Case-by-Case Tutorial". Every beginner must required to read this article. It's so easy to understand main Node.Js concept and programming overviews. Hire Node js development company

Sam Watt

Wow, this is a very detailed and insightful article based on cases. Tôi thích đọc nó, và hy vọng sẽ thấy nhiều bài báo như vậy. Cảm ơn bạn

ThinkStart Pvt Ltd

bài hữu ích. Cảm ơn bạn đã chia sẻ thông tin tuyệt vời này

w3villa

Xin chào, tôi thích đọc blog thông tin của bạn. Cám ơn vì đã chia sẻ

marie adams

Tôi đã thực hiện một số khoản đầu tư thành công với nhà môi giới này trước khi mất 40% số tiền tiết kiệm của mình vì trò lừa đảo giao dịch. Tôi đã tốn rất nhiều tiền và đau đớn khi đầu tư vào một khoản đầu tư thậm chí không có thật. Tôi đã có thể thu hồi phần lớn số tiền và chúng tôi vẫn đang cố gắng thu hồi phần còn lại. Tôi thực sự khuyên bạn nên AN TOÀN ĐỂ ĐẦU TƯ TỐT cho bất kỳ ai tham gia vào một vụ lừa đảo giao dịch trực tuyến Lừa đảo giao dịch đã thu hồi 350.000 đô la DƯỚI ĐÂY LÀ LIÊN HỆ CỦA HỌ. safe2investwell@gmail. cuộc gọi / whatsapp. +14638887391

marie adams

Tôi đã thực hiện một số khoản đầu tư thành công với nhà môi giới này trước khi mất 40% số tiền tiết kiệm của mình vì trò lừa đảo giao dịch. Tôi đã tốn rất nhiều tiền và đau đớn khi đầu tư vào một khoản đầu tư thậm chí không có thật. I was able to recover the majority of the funds, and we are still attempting to recover the rest. I highly recommend SECURE TO INVEST WELL for anyone involved in an online trading scam Trading scam $350,000 recovered BELOW IS THEIR CONTACT. secure2investwell@gmail. cuộc gọi / whatsapp. +14638887391

Joshua Flynn

Viết rất hay nhưng bạn có thể làm điều tương tự bằng cách sử dụng ngăn xếp đèn thông thường với lệnh gọi JQuery thông qua AJAX giống như tất cả các trình nhắn tin tức thời trước đây đã thực hiện mà không gặp rắc rối nào không? . I have read hundreds of articles around the web about why someone should use node but they all cover something that could be done with technology we had back in the 90s. Vậy nút có gì đặc biệt mà tôi nên tìm hiểu về nó với công nghệ 30 năm tuổi đã hỗ trợ các loại ứng dụng giống như bạn đã đề cập trong bài viết này 15 năm trước khi nút xuất hiện và quay trở lại khi quay số nhanh. So if it was fast enough to do the same thing over a dial up connection what has node done too improve the ecosystem of the internet

programming javascript

Sử dụng bộ nhớ javascript

nút là gì. js?

Why Use Node. js?

Nút như thế nào. js Work?

npm. Trình quản lý gói nút

Nơi sử dụng nút. js

Trò chuyện

API trên đầu DB đối tượng

Đầu vào xếp hàng

Truyền dữ liệu

Ủy quyền

Môi giới/Bảng điều khiển của nhà giao dịch chứng khoán

Bảng điều khiển giám sát ứng dụng

Bảng điều khiển giám sát hệ thống

Nơi sử dụng nút. js, nhưng thận trọng

Ứng dụng web phía máy chủ

Nơi không sử dụng nút. js

Ứng dụng web phía máy chủ với ứng dụng cơ sở dữ liệu quan hệ

Xử lý và/hoặc tính toán phía máy chủ nặng

Tại sao chọn nút. js?

Hiểu những điều cơ bản

nút là gì. js?

nút là gì. js dùng để làm gì?

một khuôn khổ web là gì?

là nút. js là một khuôn khổ?

là nút. js một ngôn ngữ lập trình?

Tại sao là nút. js phổ biến?

Sự khác biệt giữa nút là gì. js và Góc/AngularJS?

Tại sao là nút. js xấu?

Bình luận

Bài Viết Liên Quan

Quảng Cáo

Có thể bạn quan tâm

Toplist được quan tâm

Quảng cáo

Xem Nhiều

Quảng cáo

Chúng tôi

Điều khoản

Trợ giúp

Mạng xã hội