Nodejs ghi luồng

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

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

ĐĂNG LẠI

ĐĂNG LẠI

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

Nodejs ghi luồng
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 tái sử dụng tối ưu tài nguyên của nhà phát triển. 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

Nút. js cung cấp cho các nhà phát triển một công cụ toàn diện để làm việc trong mô hình I/O không chặn, hướng sự kiện. Ryan Dahl, người tạo ra Nút. js được “lấy cảm hứng từ các ứng dụng như Gmail” và—trong việc tạo Node. js—nhằm mục đích tạo các trang web thời gian thực với khả năng đẩy

Sau hơn 20 năm web không trạng thái dựa trên mô hình phản hồi yêu cầu không trạng thái, cuối cùng chúng ta cũng có các ứng dụng web với kết nối hai chiều, thời gian thực

Tại sao nên sử dụng nút. js?

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. Sau hơn 20 năm web không trạng thái dựa trên mô hình phản hồi yêu cầu không trạng thái, cuối cùng chúng ta cũng có các ứng dụng web với kết nối hai chiều, thời gian thực, trong đó cả máy khách và máy chủ đều có thể bắt đầu giao tiếp, cho phép chúng trao đổi dữ liệu tự do hơn. Điều này hoàn toàn trái ngược với mô hình phản hồi web điển hình, nơi khách hàng luôn bắt đầu giao tiếp

Người ta có thể lập luận rằng chúng ta đã có công nghệ này trong nhiều năm dưới dạng Flash và Java Applet. Tuy nhiên, trên thực tế, đó chỉ là những môi trường hộp cát sử dụng web làm giao thức vận chuyển để gửi đến máy khách. Ngoài ra, các Applet Flash và Java được chạy độc lập và thường hoạt động trên các cổng không chuẩn, có thể yêu cầu thêm quyền

Nút như thế nào. js Công việc?

Node thực sự tỏa sáng trong việc xây dựng các ứng dụng mạng nhanh, có khả năng mở rộng. Đ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 duy nhất, 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

Traditional vs. Node.js Server Thread

Theo bài báo 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 sẽ 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 luồ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)

Một công cụ tạo khuôn mẫu lấy cảm hứng từ HAML, một công cụ 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

khoảng khăc. 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

  1. 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à
  2. 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

  1. 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
  2. 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à điều sẽ xảy ra

  1. Trình duyệt bắt nút 'Gửi' khi nhấp qua trình xử lý JavaScript. Nó lấy 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)
  2. 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á
  3. 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

Có những tình huống mà Node có thể không phải là công cụ tốt nhất cho công việc

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

Ruby on Rails đã từng là lựa chọn rõ ràng như một công cụ để truy cập các cơ sở dữ liệu quan hệ như PostgreSQL, MySQL và Microsoft SQL Server. Điều này là do các công cụ DB quan hệ cho 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ệ

Nhưng mọi thứ đã thay đổi. Sequelize, TypeORM và Bookshelf đã đi một chặng đường dài để trở thành giải pháp ORM trưởng thành. 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ó. Điều này là do các yêu cầu đến bị chặn trong khi chuỗi đang bận rộn với việc xử lý số của bạn—giả sử bạn đang cố gắng chạy các phép tính trong cùng một phiên bản Node được sử dụng để phản hồi các yêu cầu

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. Ngoài ra, bạn có thể chạy một số 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

Thông tin về các 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 biến đám mây 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

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)

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

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

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. Tuy nhiên, cuối cùng bạn có thể chặn Nút của mình. js nếu bạn quá hạn, nhưng điều đó cũng đúng với máy chủ luồng truyền thống

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. Tuy nhiên, cuối cùng bạn có thể chặn Nút của mình. js nếu bạn quá hạn, nhưng điều đó cũng đúng với máy chủ luồng truyền thố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?

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 để xử lý một yêu cầu bằng cách chỉ cần đặt nó vào hàng đợi xử lý, trả lại một thông báo cho khách hàng với nội dung như "tính toán. ". 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, sau đó sẽ chuyển tiếp nó trở lại ứng dụng khách ban đầu? . Bất cứ điều gì như thế này có thể?

irneb

Bất kỳ hệ thống hybrid như vậy? . Sử dụng nút. js để xử lý một yêu cầu bằng cách chỉ cần đặt nó vào hàng đợi xử lý, trả lại một thông báo cho khách hàng với nội dung như "tính toán. ". 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, sau đó sẽ chuyển tiếp nó trở lại ứng dụng khách ban đầu? . Bất cứ điều gì như thế này có thể?

zivkovic_milan

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

zivkovic_milan

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

Gerd Jungbluth

Tomislav, cảm ơn vì bài viết rất hay và súc tích này. Chúng tôi đã sử dụng MongoDB và 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

Tomislav, cảm ơn vì bài viết rất hay và súc tích này. Chúng tôi đã sử dụng MongoDB và 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

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

Đó 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

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 không khó để học. =)

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 không khó để học. =)

Tomislav Capan

Đúng vậy, nhưng tôi nghĩ chúng ta với tư cách là một ngành công nghiệp đã vượt qua ý tưởng viết tất cả SQL theo cách thủ công. Các công cụ rất tốt cho các hoạt động thông thường, các công cụ không cần thiết khi cầ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

Đúng vậy, nhưng tôi nghĩ chúng ta với tư cách là một ngành công nghiệp đã vượt qua ý tưởng viết tất cả SQL theo cách thủ công. Các công cụ rất tốt cho các hoạt động thông thường, các công cụ không cần thiết khi cầ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

Xin chào Adin, cho phép tôi bình luận lại 1) kịch bản tương tự xảy ra, có một số lượng chủ đề giới hạn phục vụ số lượng khách hàng hạn chế. 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

Xin chào Adin, cho phép tôi bình luận lại 1) kịch bản tương tự xảy ra, có một số lượng chủ đề giới hạn phục vụ số lượng khách hàng hạn chế. 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

Có, bạn có thể có nhiều worker process, thậm chí giao tiếp qua 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

Có, bạn có thể có nhiều worker process, thậm chí giao tiếp qua 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

Bất kỳ tính toán nào khiến CPU bận rộn cho đến khi tính toán kết thúc. Hãy tưởng tượng một số thao tác cần 2 giây để thực hiện phép tính. Đạt được điều đó với 100 khách hàng - bạn nhận được độ trễ 200 giây. Lưu ý bài viết tôi đã tham khảo, giải thích về việc chặn vòng lặp sự kiện. http. //zef. me/4561/node-js-and-the-case-of-the-blocked-event-loop

Tomislav Capan

Bất kỳ tính toán nào khiến CPU bận rộn cho đến khi tính toán kết thúc. Hãy tưởng tượng một số thao tác cần 2 giây để thực hiện phép tính. Đạt được điều đó với 100 khách hàng - bạn nhận được độ trễ 200 giây. Lưu ý bài viết tôi đã tham khảo, giải thích về việc chặn vòng lặp sự kiện. 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

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 vì đó là thứ chạy JS trên máy chủ, nhưng bạn cũng có thể sử dụng các ngôn ngữ khác để thực hiện công việc cụ thể một cách nhanh chóng

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 vì đó là thứ chạy JS trên máy chủ, nhưng bạn cũng có thể sử dụng các ngôn ngữ khác để thực hiện công việc cụ thể một cách nhanh chóng

ellisgl

Đối với các ORM nói chung, tôi chỉ xem chúng như một công cụ có thể hoàn thành công việc nhanh chóng cho một người mới, nhưng cuối cùng lại thực sự làm hỏng công việc sau này. 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

Đối với các ORM nói chung, tôi chỉ xem chúng như một công cụ có thể hoàn thành công việc nhanh chóng cho một người mới, nhưng cuối cùng lại thực sự làm hỏng công việc sau này. 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

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 đó. (Điều đó là công bằng, vì đó là một hội chợ chớp nhoáng và có thể mang tính luận chiến một chút. 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. ) Có thể nói sự khác biệt giữa điểm chuẩn nginx và apache hoàn toàn là do chuyển đổi ngữ cảnh là một sự đơn giản hóa quá mức. 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. ). Bạn có thể đo lường cụ thể chi phí chuyển đổi ngữ cảnh và tôi cá rằng điều đó không đáng kể. 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 đề. Có nhiều yếu tố thiết kế quan trọng hơn ở đó, chi phí hệ điều hành của các thực thể đó khá tầm thường. Do đó, tôi ghét khi mọi người áp dụng một thiết kế ngớ ngẩn dựa trên ý tưởng luồng-là-xấu hoặc quy trình-là-xấu hoặc một số điều vô nghĩa khác)

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 đó. (Điều đó là công bằng, vì đó là một hội chợ chớp nhoáng và có thể mang tính luận chiến một chút. 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. ) Có thể nói sự khác biệt giữa điểm chuẩn nginx và apache hoàn toàn là do chuyển đổi ngữ cảnh là một sự đơn giản hóa quá mức. 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. ). Bạn có thể đo lường cụ thể chi phí chuyển đổi ngữ cảnh và tôi cá rằng điều đó không đáng kể. 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 đề. Có nhiều yếu tố thiết kế quan trọng hơn ở đó, chi phí hệ điều hành của các thực thể đó khá tầm thường. Do đó, tôi ghét khi mọi người áp dụng một thiết kế ngớ ngẩn dựa trên ý tưởng luồng-là-xấu hoặc quy trình-là-xấu hoặc một số điều vô nghĩa khác)

Tomislav Capan

Mọi thứ luôn cần được đặt trong bối cảnh phù hợp. Tôi đã trình bày các tình huống có thể xảy ra, để phân tích sâu từng cái tôi cần một cuốn sách. -) 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

Mọi thứ luôn cần được đặt trong bối cảnh phù hợp. Tôi đã trình bày các tình huống có thể xảy ra, để phân tích sâu từng cái tôi cần một cuốn sách. -) 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 đó

Aaron Vương

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 Vương

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

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

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

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

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?

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

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?

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

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

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

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

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

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ủ đề

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

> 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

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. )

TZ

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?

TZ

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

Đố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)

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

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

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

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

Đố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

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

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, tôi không chắc liệu tôi có tìm thấy bất kỳ cách sử dụng nào cho một Node hay không. js, mặc dù nhà thiết kế web của chúng tôi có thể. Một lưu ý khác, tôi muốn thêm ý kiến ​​​​của riêng mình về việc sử dụng ORM. 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. Tuy nhiên, vì ORM là các lớp cấp cao nên chúng thường không phải là tùy chọn hiệu quả nhất để sử dụng đối với cơ sở dữ liệu trong khi truy cập trực tiếp thông qua các nhà cung cấp bản địa là. Trong nhiều khía cạnh, tốt hơn là thực hiện mã hóa lặp đi lặp lại để đạt hiệu quả hơn là áp dụng lớp tạm thời có trọng lượng nặng, chẳng hạn như ORM

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, tôi không chắc liệu tôi có tìm thấy bất kỳ cách sử dụng nào cho một Node hay không. js, mặc dù nhà thiết kế web của chúng tôi có thể. Một lưu ý khác, tôi muốn thêm ý kiến ​​​​của riêng mình về việc sử dụng ORM. 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. Tuy nhiên, vì ORM là các lớp cấp cao nên chúng thường không phải là tùy chọn hiệu quả nhất để sử dụng đối với cơ sở dữ liệu trong khi truy cập trực tiếp thông qua các nhà cung cấp bản địa là. Trong nhiều khía cạnh, tốt hơn là thực hiện mã hóa lặp đi lặp lại để đạt hiệu quả hơn là áp dụng lớp tạm thời có trọng lượng nặng, chẳng hạn như ORM

openas

Quan sát rất thú vị. Tôi muốn ai đó giải thích thêm một chút về điều đó. Tôi muốn một ví dụ cụ thể hơn, chẳng hạn như một số đoạn mã cụ thể gọi một hàm tính toán nặng không đồng bộ và ai đó giải thích điều gì sẽ xảy ra nếu nó được chạy trong một thiết bị đa lõi. Chuỗi đang thu thập các yêu cầu http có bị chặn không?

openas

Quan sát rất thú vị. Tôi muốn ai đó giải thích thêm một chút về điều đó. Tôi muốn một ví dụ cụ thể hơn, chẳng hạn như một số đoạn mã cụ thể gọi một hàm tính toán nặng không đồng bộ và ai đó giải thích điều gì sẽ xảy ra nếu nó được chạy trong một thiết bị đa lõi. Chuỗi đang thu thập các yêu cầu http có bị chặn không?

Derrick Simpson

Node là một máy chủ web khủng khiếp. Ngay cả người sáng tạo cũng gợi ý rằng đây không phải là mục đích của Node và nó nên được tận dụng vì thế mạnh của nó. JavaScript "Mọi thứ", giống như các quy trình công nhân, thật lố bịch

Derrick Simpson

Node là một máy chủ web khủng khiếp. Ngay cả người sáng tạo cũng gợi ý rằng đây không phải là mục đích của Node và nó nên được tận dụng vì thế mạnh của nó. JavaScript "Mọi thứ", giống như các quy trình công nhân, thật lố bịch

Eric Elliott

Điều này thật là buồn cười. 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. Nó đang nhanh chóng thay thế Ruby và PHP trong nhiều tổ chức doanh nghiệp vì nó đã tăng hiệu suất ứng dụng một cách đáng kể (giảm thời gian tải trang, v.v. ) và năng suất của nhà phát triển

Eric Elliott

Điều này thật là buồn cười. 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. Nó đang nhanh chóng thay thế Ruby và PHP trong nhiều tổ chức doanh nghiệp vì nó đã tăng hiệu suất ứng dụng một cách đáng kể (giảm thời gian tải trang, v.v. ) và năng suất của nhà phát triển

jonpress

Trên thực tế, bạn có thể tạo các máy chủ đa luồng bằng Node. js để cung cấp hiệu suất ổn định hơn nhưng phải làm thêm nhiều việc (xem mô-đun cụm tích hợp và mô-đun child_ process). Tôi đã tạo một khung chạy trên nhiều lõi CPU và giải quyết được nhiều vấn đề được thảo luận trong bài đăng này. Kiểm tra nó ra. http. // nombo. io/

jonpress

Trên thực tế, bạn có thể tạo các máy chủ đa luồng bằng Node. js để cung cấp hiệu suất ổn định hơn nhưng phải làm thêm nhiều việc (xem mô-đun cụm tích hợp và mô-đun child_ process). Tôi đã tạo một khung chạy trên nhiều lõi CPU và giải quyết được nhiều vấn đề được thảo luận trong bài đăng này. Kiểm tra nó ra. http. // nombo. io/

Connor Leech

làm điều gì đó giống cầy mangut. js giải quyết vấn đề cơ sở dữ liệu quan hệ nút? . // mongoosejs. com/

Connor Leech

làm điều gì đó giống cầy mangut. js giải quyết vấn đề cơ sở dữ liệu quan hệ nút? . // mongoosejs. com/

Rob Tweed

Có - xem cách tiếp cận nhóm công nhân hàng đợi/phân nhánh trước được EWD áp dụng. js. http. //gradvs1. đường cổng. com/tải xuống/EWDjs. pdf Tóm tắt tại đây. http. //gradvs1. đường cổng. com/download/EWDjsMechanics. pdf

Rob Tweed

Có - xem cách tiếp cận nhóm công nhân hàng đợi/phân nhánh trước được EWD áp dụng. js. http. //gradvs1. đường cổng. com/tải xuống/EWDjs. pdf Tóm tắt tại đây. http. //gradvs1. đường cổng. com/download/EWDjsMechanics. pdf

keith

vâng, tôi cũng đã tự hỏi về nó. hình ảnh tuyệt vời + bài viết tuyệt vời

keith

vâng, tôi cũng đã tự hỏi về nó. hình ảnh tuyệt vời + bài viết tuyệt vời

Carlos Ballena

bài viết rất hữu ích

Carlos Ballena

bài viết rất hữu ích

Chúa Giêsu Nunez

npm cài đặt felixge/nút-mysql. Đó có thể là kho lưu trữ hữu ích nhất mà tôi từng thấy từ lâu

Chúa Giêsu Nunez

npm cài đặt felixge/nút-mysql. Đó có thể là kho lưu trữ hữu ích nhất mà tôi từng thấy từ lâu

Matthias Lienau

Bài viết hay thật đấy. Nhưng, @hfuti. disqus, bạn đã sai khi nói "NodeJS không chạy trong một luồng đơn lẻ. mỗi lời gọi hàm cho mỗi sự kiện sẽ chạy trong một chuỗi riêng biệt. " Theo như tôi hiểu, vòng lặp sự kiện chính của NodeJS sử dụng mã JS của bạn trên thực tế chạy trong một luồng đơn. 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). Và vâng, có các dự án env thời gian chạy xử lý nhiều quy trình nút và luồng của chúng trên cùng một máy hoặc cụm cpu. 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

Bài viết hay thật đấy. Nhưng, @hfuti. disqus, bạn đã sai khi nói "NodeJS không chạy trong một luồng đơn lẻ. mỗi lời gọi hàm cho mỗi sự kiện sẽ chạy trong một chuỗi riêng biệt. " Theo như tôi hiểu, vòng lặp sự kiện chính của NodeJS sử dụng mã JS của bạn trên thực tế chạy trong một luồng đơn. 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). Và vâng, có các dự án env thời gian chạy xử lý nhiều quy trình nút và luồng của chúng trên cùng một máy hoặc cụm cpu. Nhưng nó là một câu chuyện khác. Hãy sửa tôi nếu tôi sai

josep2

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

josep2

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

Jacopo Chiapparino

Bài viết hay, cảm ơn bạn

Jacopo Chiapparino

Bài viết hay, cảm ơn bạn

NoobMovies. com

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

NoobMovies. com

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

Alex Viết

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 Viết

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

ak

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

ak

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

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

Đã đồ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

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

tôi đồng ý, bài tốt

gianlucca

tôi đồng ý, bài tốt

gianlucca

Vâng tôi đồng ý

gianlucca

Vâng tôi đồng ý

gianlucca

chắc chắn rồi

gianlucca

chắc chắn rồi

Toulon

Bài viết rất tốt. Bạn đã suy nghĩ rất nhiều về nó. Nút nhanh/câu hỏi nhanh Tôi đang thêm mục nhập dữ liệu nhanh, không theo lô, mục nhập dữ liệu vào hệ thống của tôi Tôi có một biểu mẫu (mfntapes) hoạt động tốt. Tôi có một biểu mẫu kiểm tra (joe) lời nhắc về số lần tôi muốn gọi biểu mẫu mfntapes Ý chính chứa mã, không hoạt động, sau khi nhắc cnt cố gắng gọi mfntapes cnt lần. Lỗi là "ReferenceError. biểu mẫu không được xác định" trong dòng 87 của ý chính. Câu hỏi đặt ra là làm thế nào để gọi biểu mẫu mfntapes x số lần trong đó x là khả dụng? Xem các dòng 45-55 của https. //ý chính. github. com/toulon/9571625

Toulon

Bài viết rất tốt. Bạn đã suy nghĩ rất nhiều về nó. Nút nhanh/câu hỏi nhanh Tôi đang thêm mục nhập dữ liệu nhanh, không theo lô, mục nhập dữ liệu vào hệ thống của tôi Tôi có một biểu mẫu (mfntapes) hoạt động tốt. Tôi có một biểu mẫu kiểm tra (joe) lời nhắc về số lần tôi muốn gọi biểu mẫu mfntapes Ý chính chứa mã, không hoạt động, sau khi nhắc cnt cố gắng gọi mfntapes cnt lần. Lỗi là "ReferenceError. biểu mẫu không được xác định" trong dòng 87 của ý chính. Câu hỏi đặt ra là làm thế nào để gọi biểu mẫu mfntapes x số lần trong đó x là khả dụng? Xem các dòng 45-55 của https. //ý chính. github. com/toulon/9571625

Chúa Giêsu Bejarano

ORM cho các dự án thực tế là vô ích

Chúa Giêsu Bejarano

ORM cho các dự án thực tế là vô ích

Thomas

bài viết hay. -) > ỨNG DỤNG WEB PHÍA MÁY CHỦ W/ MỘT DB QUAN HỆ SAU ĐÓ Tôi tự hỏi tại sao Node không tốt cho việc đó? . Nút không có sự phản đối với cơ sở dữ liệu quan hệ. nó không quan tâm đến việc chỉ chặn trình điều khiển I/O. Quan hệ hay không quan hệ

Thomas

bài viết hay. -) > ỨNG DỤNG WEB PHÍA MÁY CHỦ W/ MỘT DB QUAN HỆ SAU ĐÓ Tôi tự hỏi tại sao Node không tốt cho việc đó? . Nút không có sự phản đối với cơ sở dữ liệu quan hệ. nó không quan tâm đến việc chỉ chặn trình điều khiển I/O. Quan hệ hay không quan hệ

Seb

Tôi ước gì NodeJS không (gần như) được trình bày một cách có hệ thống dưới dạng THE de facto thay thế cho máy chủ web theo luồng truyền thống. Async IO không dành riêng cho NodeJS. Hầu hết các ngôn ngữ chính hiện có - bao gồm Java và PHP - đều có khung IO không đồng bộ tương tự như NodeJS. Trang wiki này liệt kê hầu hết chúng. http. // vi. wikipedia. org/wiki/Reactor_potype Tôi không nói rằng NodeJS không có giá trị của nó, nhưng tôi phát ốm và mệt mỏi khi thấy mọi người đổ xô vào nó như thể đó là ngăn xếp IO *chỉ* không đồng bộ có sẵn và là giải pháp thay thế *chỉ* cho . Thành thật mà nói, chúng tôi có thể bị mắc kẹt với Javascript trên trình duyệt và sẽ còn rất lâu (trừ khi Javascript trở thành một nền tảng/ngôn ngữ mục tiêu khác nhờ asm. js), nhưng tôi không thể đưa ra bất kỳ lý do chính đáng nào để sử dụng nó ở phía máy chủ có lợi cho các ngôn ngữ khả dụng khác. Hầu hết các lựa chọn thay thế chỉ là ngôn ngữ tốt hơn, có thư viện, công cụ và tài nguyên tiêu chuẩn tốt hơn. Chỉ là ý kiến ​​cá nhân. Tóm lại, Node JS rất tuyệt, nhưng chắc chắn có một framework tương tự được viết bằng ngôn ngữ yêu thích của bạn. Vui lòng dành 5 phút để nghiên cứu về nó trước khi chuyển sang NodeJS

Seb

Tôi ước gì NodeJS không (gần như) được trình bày một cách có hệ thống dưới dạng THE de facto thay thế cho máy chủ web theo luồng truyền thống. Async IO không dành riêng cho NodeJS. Hầu hết các ngôn ngữ chính hiện có - bao gồm Java và PHP - đều có khung IO không đồng bộ tương tự như NodeJS. Trang wiki này liệt kê hầu hết chúng. http. // vi. wikipedia. org/wiki/Reactor_potype Tôi không nói rằng NodeJS không có giá trị của nó, nhưng tôi phát ốm và mệt mỏi khi thấy mọi người đổ xô vào nó như thể đó là ngăn xếp IO *chỉ* không đồng bộ có sẵn và là giải pháp thay thế *chỉ* cho . Thành thật mà nói, chúng tôi có thể bị mắc kẹt với Javascript trên trình duyệt và sẽ còn rất lâu (trừ khi Javascript trở thành một nền tảng/ngôn ngữ mục tiêu khác nhờ asm. js), nhưng tôi không thể đưa ra bất kỳ lý do chính đáng nào để sử dụng nó ở phía máy chủ có lợi cho các ngôn ngữ khả dụng khác. Hầu hết các lựa chọn thay thế chỉ là ngôn ngữ tốt hơn, có thư viện, công cụ và tài nguyên tiêu chuẩn tốt hơn. Chỉ là ý kiến ​​cá nhân. Tóm lại, Node JS rất tuyệt, nhưng chắc chắn có một framework tương tự được viết bằng ngôn ngữ yêu thích của bạn. Vui lòng dành 5 phút để nghiên cứu về nó trước khi chuyển sang NodeJS

Jarle Leopold Moe

Làm thế nào bạn sẽ tải lên các tập tin? . Nút. js là _single-threaded_ nó chỉ áp dụng cho một số loại tác vụ nhất định

Jarle Leopold Moe

Làm thế nào bạn sẽ tải lên các tập tin? . Nút. js là _single-threaded_ nó chỉ áp dụng cho một số loại tác vụ nhất định

Eric Elliott

Đây là những ví dụ tuyệt vời về lý do tại sao Node tốt hơn nhiều so với sự cạnh tranh tại các dịch vụ web. Không ai trong số đó đang chặn hoạt động trong Node. Chúng không đồng bộ. Trong khi các máy chủ khác lãng phí tài nguyên khi chạy các luồng riêng biệt, Node kích hoạt hoạt động không đồng bộ theo hướng sự kiện và tiếp tục nhận nhiều yêu cầu hơn trong thời gian chờ đợi. Kết quả thực tế là việc chuyển các dịch vụ web từ PHP hoặc Ruby có thể mang lại những cải tiến từ 2 đến 10 lần trong các kết nối đồng thời và thường là 30% - 60% cải thiện về thời gian phản hồi trung bình. Rất nhiều công ty lớn đang thực hiện các dự án Node web chỉ vì những lý do này, bao gồm Adobe, Paypal, eBay, Walmart, Yahoo. , Groupon, Uber, v.v.

Eric Elliott

Đây là những ví dụ tuyệt vời về lý do tại sao Node tốt hơn nhiều so với sự cạnh tranh tại các dịch vụ web. Không ai trong số đó đang chặn hoạt động trong Node. Chúng không đồng bộ. Trong khi các máy chủ khác lãng phí tài nguyên khi chạy các luồng riêng biệt, Node kích hoạt hoạt động không đồng bộ theo hướng sự kiện và tiếp tục nhận nhiều yêu cầu hơn trong thời gian chờ đợi. Kết quả thực tế là việc chuyển các dịch vụ web từ PHP hoặc Ruby có thể mang lại những cải tiến từ 2 đến 10 lần trong các kết nối đồng thời và thường là 30% - 60% cải thiện về thời gian phản hồi trung bình. Rất nhiều công ty lớn đang thực hiện các dự án Node web chỉ vì những lý do này, bao gồm Adobe, Paypal, eBay, Walmart, Yahoo. , Groupon, Uber, v.v.

jenit shah

bài viết rất hay và suy nghĩ rất rõ ràng về nút. js nên sử dụng ở đâu và không ở đâu

jenit shah

bài viết rất hay và suy nghĩ rất rõ ràng về nút. js nên sử dụng ở đâu và không ở đâu

BòQuy Định

Mọi nền tảng phát triển ứng dụng chính đều đã hỗ trợ HTML5 trong vài năm qua, bao gồm cả ổ cắm web để liên lạc hai chiều. Thêm vào đó là các loại mạnh, đa luồng và hàng tấn thứ khác mà các ngôn ngữ như Java phải cung cấp và tôi thực sự đặt câu hỏi tại sao mọi người lại lãng phí thời gian của họ khi sử dụng ngôn ngữ này

BòQuy Định

Mọi nền tảng phát triển ứng dụng chính đều đã hỗ trợ HTML5 trong vài năm qua, bao gồm cả ổ cắm web để liên lạc hai chiều. Thêm vào đó là các loại mạnh, đa luồng và hàng tấn thứ khác mà các ngôn ngữ như Java phải cung cấp và tôi thực sự đặt câu hỏi tại sao mọi người lại lãng phí thời gian của họ khi sử dụng ngôn ngữ này

robertcook

Chỉ muốn đề cập rằng nút đó không phải là tùy chọn phía máy chủ duy nhất cho javascript, đặc biệt là khi Oracle đặt công cụ javascript nashorn trên jdk. Bây giờ bạn cũng có thể sử dụng tất cả tính năng tốt của jvm từ javascript mà chúng tôi đang sử dụng vert. x làm máy chủ không đồng bộ và nashorn để sử dụng javascript. Bạn có thể xem một số mẫu mã trong mô-đun này https. //github. com/core9/module-nashorn trang web dự án là core9. io

robertcook

Chỉ muốn đề cập rằng nút đó không phải là tùy chọn phía máy chủ duy nhất cho javascript, đặc biệt là khi Oracle đặt công cụ javascript nashorn trên jdk. Bây giờ bạn cũng có thể sử dụng tất cả tính năng tốt của jvm từ javascript mà chúng tôi đang sử dụng vert. x làm máy chủ không đồng bộ và nashorn để sử dụng javascript. Bạn có thể xem một số mẫu mã trong mô-đun này https. //github. com/core9/module-nashorn trang web dự án là core9. io

Vô danh

Đây là một tổng quan tuyệt vời. Cảm ơn bạn

Vô danh

Đây là một tổng quan tuyệt vời. Cảm ơn bạn

Vishnu Tekale

Viết rất tốt. Cám ơn vì đã chia sẻ

Vishnu Tekale

Viết rất tốt. Cám ơn vì đã chia sẻ

Gleb Bahmutov

Tại sao Nút lại khác - sử dụng thanh làm http tương tự. // bamutov. cái ghim. co/tại sao-nút-là-khác. html

Gleb Bahmutov

Tại sao Nút lại khác - sử dụng thanh làm http tương tự. // bamutov. cái ghim. co/tại sao-nút-là-khác. html

FluckerSputter

Chỉ để cho bạn biết rằng bạn có "hỗ trợ hỗ trợ" trong Cách thức hoạt động cơ bản khá 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 các cuộc gọi I/O không chặn, cho phép nó 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)

FluckerSputter

Chỉ để cho bạn biết rằng bạn có "hỗ trợ hỗ trợ" trong Cách thức hoạt động cơ bản khá 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 các cuộc gọi I/O không chặn, cho phép nó 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)

piloh23

Nút. js sẽ không bao giờ thay thế Rails để trở thành web framework số một

piloh23

Nút. js sẽ không bao giờ thay thế Rails để trở thành web framework số một

Alifa Nurani Putri

Xin chào, Nút có phải là lựa chọn tốt nhất để truyền và tải video lên không?

Alifa Nurani Putri

Xin chào, Nút có phải là lựa chọn tốt nhất để truyền và tải video lên không?

SleightDifference

Tại sao PHP không được đề cập để tương tác với cơ sở dữ liệu quan hệ?

SleightDifference

Tại sao PHP không được đề cập để tương tác với cơ sở dữ liệu quan hệ?

Clain Dsilva

Cảm ơn bạn đã dành thời gian giải thích về Node. js. Tôi thực sự gặp khó khăn trong việc hiểu nó từ trang web của họ cũng như Wikipedia. Bài viết tốt. Giữ nó lên

Clain Dsilva

Cảm ơn bạn đã dành thời gian giải thích về Node. js. Tôi thực sự gặp khó khăn trong việc hiểu nó từ trang web của họ cũng như Wikipedia. Bài viết tốt. Giữ nó lên

Cézar Luiz

Còn https này thì sao. //github. com/felixge/nút-mysql? . Cảm ơn

Cézar Luiz

Còn https này thì sao. //github. com/felixge/nút-mysql? . Cảm ơn

Marcelo Lima

Cảm ơn bạn cho bài viết này. Đã xóa rất nhiều câu hỏi của tôi về nội bộ Node

Marcelo Lima

Cảm ơn bạn cho bài viết này. Đã xóa rất nhiều câu hỏi của tôi về nội bộ Node

điều hướng

Điều tuyệt vời

điều hướng

Điều tuyệt vời

Abdelhakim

https. //www. demy. com/nodejs-tutorial-from-scratch-by-examples/?couponCode=NewOffer 1. Truy cập trọn đời 24 bài giảng 2. Hơn 120 phút nội dung chất lượng cao. 2. Tham gia cộng đồng hơn 2687 sinh viên cùng nhau học tập. 4. Thông tin khóa học và cập nhật thường xuyên 5. Tìm hiểu nút. js và mongoDB từ đầu bằng các ví dụ. 6. Thông tin khóa học và cập nhật thường xuyên. 7. Diễn đàn thảo luận mà chúng tôi khuyến khích bạn tận dụng -- vừa để đặt câu hỏi về tài liệu cho người hướng dẫn khóa học vừa để trao đổi ý kiến ​​với các bạn cùng lớp. số 8. Hỗ trợ khóa học chất lượng cao

Abdelhakim

https. //www. demy. com/nodejs-tutorial-from-scratch-by-examples/?couponCode=NewOffer 1. Truy cập trọn đời 24 bài giảng 2. Hơn 120 phút nội dung chất lượng cao. 2. Tham gia cộng đồng hơn 2687 sinh viên cùng nhau học tập. 4. Thông tin khóa học và cập nhật thường xuyên 5. Tìm hiểu nút. js và mongoDB từ đầu bằng các ví dụ. 6. Thông tin khóa học và cập nhật thường xuyên. 7. Diễn đàn thảo luận mà chúng tôi khuyến khích bạn tận dụng -- vừa để đặt câu hỏi về tài liệu cho người hướng dẫn khóa học vừa để trao đổi ý kiến ​​với các bạn cùng lớp. số 8. Hỗ trợ khóa học chất lượng cao

rahul gag

Theo sự hiểu biết của tôi với bài viết, nếu bạn gửi bất kỳ yêu cầu nào tới máy chủ nút, nó sẽ thực sự xử lý trên một số luồng nền (libuv. dll). Bây giờ tôi muốn đăng một số tệp qua máy chủ nút, tại sao nó chặn máy chủ nút trong khi nó thực sự sẽ xử lý trên luồng nền và khi hoàn tất, chỉ phản hồi sẽ được trả về bởi luồng nút?

rahul gag

Theo sự hiểu biết của tôi với bài viết, nếu bạn gửi bất kỳ yêu cầu nào tới máy chủ nút, nó sẽ thực sự xử lý trên một số luồng nền (libuv. dll). Bây giờ tôi muốn đăng một số tệp qua máy chủ nút, tại sao nó chặn máy chủ nút trong khi nó thực sự sẽ xử lý trên luồng nền và khi hoàn tất, chỉ phản hồi sẽ được trả về bởi luồng nút?

siddesh

Siêu Bài Viết

siddesh

Siêu Bài Viết

fanck

Không thể lấy ngày đăng bài viết của bạn? . Thật sự rất khó chịu khi đọc các bài viết kỹ thuật không có ngày tháng. cảm ơn

fanck

Không thể lấy ngày đăng bài viết của bạn? . Thật sự rất khó chịu khi đọc các bài viết kỹ thuật không có ngày tháng. cảm ơn

nam mô

Bạn đề cập đến Nút. js tốt cho ứng dụng trò chuyện vì nó không tốn nhiều CPU. Tôi không thể nghĩ ra quá nhiều trường hợp sử dụng không yêu cầu nhiều CPU. Ví dụ: Twitter có thể được xây dựng bằng Node không? . Nút. js sử dụng chắc chắn không thể quá hẹp

nam mô

Bạn đề cập đến Nút. js tốt cho ứng dụng trò chuyện vì nó không tốn nhiều CPU. Tôi không thể nghĩ ra quá nhiều trường hợp sử dụng không yêu cầu nhiều CPU. Ví dụ: Twitter có thể được xây dựng bằng Node không? . Nút. js sử dụng chắc chắn không thể quá hẹp

Ian Kaplan

Bài báo tuyệt vời. Cảm ơn. Có một trò đùa cũ. bạn không phải là một kẻ hoang tưởng nếu họ thực sự ra ngoài để có được bạn. Đó là thái độ nên có khi nói đến bảo mật ứng dụng Web. Một điều làm phiền tôi về Node. js là tôi không hiểu rõ về mức độ an toàn của nó. Khi một môi trường như Grails, nơi tôi có Java/Groovy chạy trên Tomcat, tôi có chút tin tưởng vào bảo mật của Tomcat, nếu không vì lý do nào khác ngoài thực tế là Tomcat đã tồn tại từ lâu và đã phát triển. Điều này không đúng với Node. js. Tôi cũng đang xem Node. thư viện js. Ít nhất là đối với quyền truy cập tệp, nó dường như chẳng khác gì một lớp mỏng trên các cuộc gọi hệ thống tệp POSIX. Tôi thích phần trừu tượng hóa tệp Java hoặc thậm chí C++ hơn. Đối số chính mà tôi thấy cho Node. js (được thực hiện trong bài đăng này) là nó có các luồng thực sự nhẹ và bạn có thể có JavaScrip ở mọi nơi. Vấn đề cuối cùng này là một điểm thu hút đối với những người chỉ biết JavaScript. Đối với các chủ đề trọng lượng nhẹ, đây không phải là vấn đề về ngôn ngữ mà là vấn đề hỗ trợ nền tảng. Có thể hỗ trợ loại mô hình luồng này bằng ngôn ngữ khác

Ian Kaplan

Bài báo tuyệt vời. Cảm ơn. Có một trò đùa cũ. bạn không phải là một kẻ hoang tưởng nếu họ thực sự ra ngoài để có được bạn. Đó là thái độ nên có khi nói đến bảo mật ứng dụng Web. Một điều làm phiền tôi về Node. js là tôi không hiểu rõ về mức độ an toàn của nó. Khi một môi trường như Grails, nơi tôi có Java/Groovy chạy trên Tomcat, tôi có chút tin tưởng vào bảo mật của Tomcat, nếu không vì lý do nào khác ngoài thực tế là Tomcat đã tồn tại từ lâu và đã phát triển. Điều này không đúng với Node. js. Tôi cũng đang xem Node. thư viện js. Ít nhất là đối với quyền truy cập tệp, nó dường như chẳng khác gì một lớp mỏng trên các cuộc gọi hệ thống tệp POSIX. Tôi thích phần trừu tượng hóa tệp Java hoặc thậm chí C++ hơn. Đối số chính mà tôi thấy cho Node. js (được thực hiện trong bài đăng này) là nó có các luồng thực sự nhẹ và bạn có thể có JavaScrip ở mọi nơi. Vấn đề cuối cùng này là một điểm thu hút đối với những người chỉ biết JavaScript. Đối với các chủ đề trọng lượng nhẹ, đây không phải là vấn đề về ngôn ngữ mà là vấn đề hỗ trợ nền tảng. Có thể hỗ trợ loại mô hình luồng này bằng ngôn ngữ khác

Web khổng lồ

Nhà thiết kế Toptal đã thiết kế cho họ

Web khổng lồ

Nhà thiết kế Toptal đã thiết kế cho họ

Scott

Bài báo tuyệt vời. cảm ơn vì những thông tin

Scott

Bài báo tuyệt vời. cảm ơn vì những thông tin

daimmo

tôi đồng ý. Tôi đoán đó là khoảng "một năm trước" vì hầu hết các bình luận của Disqus. Điều này được lấy từ các thẻ meta của họ. 2013-08-13

daimmo

tôi đồng ý. Tôi đoán đó là khoảng "một năm trước" vì hầu hết các bình luận của Disqus. Điều này được lấy từ các thẻ meta của họ. 2013-08-13

Vua Adnan

đẹp

Vua Adnan

đẹp

Ethan Garofolo

Nút. js không phải là một khung web. Đó là thời gian chạy V8 được đóng gói với một số thư viện lõi được đính kèm. Node giống mri trong thế giới Ruby hơn Rails

Ethan Garofolo

Nút. js không phải là một khung web. Đó là thời gian chạy V8 được đóng gói với một số thư viện lõi được đính kèm. Node giống mri trong thế giới Ruby hơn Rails

Khách mời

Nút. js giống Rack hơn, nhưng không giống. MRI chỉ là một ngôn ngữ thực hiện

Khách mời

Nút. js giống Rack hơn, nhưng không giống. MRI chỉ là một ngôn ngữ thực hiện

Bể bơi Lambda

vấn đề là mongodb, quá rủi ro khi sử dụng cơ sở dữ liệu không thể di chuyển

Bể bơi Lambda

vấn đề là mongodb, quá rủi ro khi sử dụng cơ sở dữ liệu không thể di chuyển

Bể bơi Lambda

đúng vậy, ORM là một thực tế tồi sau tất cả

Bể bơi Lambda

đúng vậy, ORM là một thực tế tồi sau tất cả

Bể bơi Lambda

có nhưng nó hoạt động theo một cách rất không hiệu quả

Bể bơi Lambda

có nhưng nó hoạt động theo một cách rất không hiệu quả

Bể bơi Lambda

bản thân công cụ cơ sở dữ liệu sẽ tinh vi hơn bất kỳ thư viện ORM nào do người khác tạo ra

Bể bơi Lambda

bản thân công cụ cơ sở dữ liệu sẽ tinh vi hơn bất kỳ thư viện ORM nào do người khác tạo ra

John Bailo

Thật thú vị khi web vẫn không đồng bộ như thế nào. Thật vậy, giống như một chiếc máy trả lời điện thoại, tiện ích của nó nằm ở chỗ

John Bailo

Thật thú vị khi web vẫn không đồng bộ như thế nào. Thật vậy, giống như một chiếc máy trả lời điện thoại, tiện ích của nó nằm ở chỗ

Jayaraj Poroor

Tôi đồng ý - Tôi cũng không phải là người hâm mộ ORM. ORM là một ví dụ cổ điển về sự trừu tượng bị rò rỉ

Jayaraj Poroor

Tôi đồng ý - Tôi cũng không phải là người hâm mộ ORM. ORM là một ví dụ cổ điển về sự trừu tượng bị rò rỉ

Jayaraj Poroor

Về việc sử dụng Node. js với cơ sở dữ liệu quan hệ. Shelloid (http. // vỏ sò. org) là một máy chủ ứng dụng mã nguồn mở cho Node. js mà chúng tôi đã phát triển để đơn giản hóa nhiều tác vụ của lập trình viên. e. g. , Bạn có thể khai báo các truy vấn SQL có tên dưới dạng chú thích và một hàm có tên đó sẽ tự động được thêm vào đối tượng DB để bạn sử dụng

Jayaraj Poroor

Về việc sử dụng Node. js với cơ sở dữ liệu quan hệ. Shelloid (http. // vỏ sò. org) là một máy chủ ứng dụng mã nguồn mở cho Node. js mà chúng tôi đã phát triển để đơn giản hóa nhiều tác vụ của lập trình viên. e. g. , Bạn có thể khai báo các truy vấn SQL có tên dưới dạng chú thích và một hàm có tên đó sẽ tự động được thêm vào đối tượng DB để bạn sử dụng

M

Tôi nghĩ bạn chưa hiểu rõ về lý do cũng như đặc điểm của ORM. ORM không chỉ cô lập các mối quan tâm về dữ liệu, chúng còn cung cấp khả năng kiểm tra và tính linh hoạt cao hơn so với các máy khách SQL truyền thống. ORM cũng cung cấp quyền truy cập bộ nhớ thay cho các phép nối không hiệu quả, vì vậy chúng thực sự có thể hiệu quả hơn nhiều so với SQL trong các tình huống trong thế giới thực. Ngoài ra, với sự lựa chọn thực hiện các hoạt động tập hợp phức tạp trong ngôn ngữ tập hợp thủ tục hạn chế như SQL hoặc phức tạp trong các hoạt động bộ nhớ bằng cách sử dụng ngôn ngữ phong phú hơn, biểu cảm hơn và dễ bảo trì hơn, ngôn ngữ phong phú hơn sẽ chiến thắng nếu bạn mong muốn duy trì hoặc mở rộng ứng dụng

M

Tôi nghĩ bạn chưa hiểu rõ về lý do cũng như đặc điểm của ORM. ORM không chỉ cô lập các mối quan tâm về dữ liệu, chúng còn cung cấp khả năng kiểm tra và tính linh hoạt cao hơn so với các máy khách SQL truyền thống. ORM cũng cung cấp quyền truy cập bộ nhớ thay cho các phép nối không hiệu quả, vì vậy chúng thực sự có thể hiệu quả hơn nhiều so với SQL trong các tình huống trong thế giới thực. Ngoài ra, với sự lựa chọn thực hiện các hoạt động tập hợp phức tạp trong ngôn ngữ tập hợp thủ tục hạn chế như SQL hoặc phức tạp trong các hoạt động bộ nhớ bằng cách sử dụng ngôn ngữ phong phú hơn, biểu cảm hơn và dễ bảo trì hơn, ngôn ngữ phong phú hơn sẽ chiến thắng nếu bạn mong muốn duy trì hoặc mở rộng ứng dụng

M

Bạn không biết những gì bạn đang nói về. Nếu bạn đang viết một ứng dụng không tầm thường và không sử dụng ORM thì tôi chắc chắn rằng sẽ có nhiều nhà phát triển cả hiện tại và trong tương lai sẽ nguyền rủa tên bạn khi họ lướt qua hàng đống SQL lố bịch. Khả năng kiểm tra? . Khi tôi thấy những bình luận lố bịch như thế này đến từ nút. js fanboi, điều đó khiến tôi nghi ngờ rằng họ sẽ hát một giai điệu khác nếu nút. js có khả năng RDBMS tốt

M

Bạn không biết những gì bạn đang nói về. Nếu bạn đang viết một ứng dụng không tầm thường và không sử dụng ORM thì tôi chắc chắn rằng sẽ có nhiều nhà phát triển cả hiện tại và trong tương lai sẽ nguyền rủa tên bạn khi họ lướt qua hàng đống SQL lố bịch. Khả năng kiểm tra? . Khi tôi thấy những bình luận lố bịch như thế này đến từ nút. js fanboi, điều đó khiến tôi nghi ngờ rằng họ sẽ hát một giai điệu khác nếu nút. js có khả năng RDBMS tốt

Bể bơi Lambda

bạn chỉ đánh giá quá cao ORM, chẳng hạn như hầu hết các fanboy OO đều làm

Bể bơi Lambda

bạn chỉ đánh giá quá cao ORM, chẳng hạn như hầu hết các fanboy OO đều làm

Bể bơi Lambda

nhận xét của bạn cũng thật nực cười, ORM không phải là mẫu được mọi người chấp nhận

Bể bơi Lambda

nhận xét của bạn cũng thật nực cười, ORM không phải là mẫu được mọi người chấp nhận

M

Điều trớ trêu là lambda's (hay còn gọi là phương thức ẩn danh) là cơ sở của cả javascript và kỹ thuật ưa thích để triển khai nhiều kiểu gọi lại của C #, mặc dù có kiểu an toàn đầy đủ. Trên thực tế, các đặc điểm chính của nút (2 chiều, nhẹ, không đồng bộ đã được triển khai hiệu quả trong C# dưới dạng "SignalR" và có một số tính năng ngôn ngữ vừa không đồng bộ vừa đa luồng, (không giống như nút. js). Bây giờ tôi có thể hiểu nếu trải nghiệm của bạn với ORM bị giới hạn ở Hibernate (hoàn toàn khủng khiếp, một trong những triển khai tồi tệ nhất của một khái niệm chính mà tôi từng không hài lòng khi làm việc) hoặc thậm chí là EF, ít nhất là khá mạnh mẽ và biểu cảm do . Nhưng một ORM vi mô như Dapper mang lại cho bạn tất cả tính linh hoạt và sức mạnh của SQL trực tiếp với lợi ích của việc thao tác dữ liệu phong phú thông qua các đối tượng và nhanh, rất nhanh. Và tôi xin lỗi, nhưng OOP là một chiến lược thiết kế rất hiệu quả, đã được chứng minh nếu bạn biết mình đang làm gì, tôi. e. , bạn là dân chuyên nghiệp. Tôi thấy có ba vấn đề lớn với nút. js mà dường như không ai có câu trả lời hay cho. Vì vậy, bạn bắt đầu với tiền đề rằng việc chờ đợi IO không hiệu quả đến mức có tiềm năng to lớn ở đó. Vì vậy, vâng, bạn đã có tính đồng thời tuyệt vời, ngay cho đến khi bạn đến thư viện chặn đầu tiên, cơ sở dữ liệu, máy chủ tệp, v.v., thực tế là mọi phần chính của chức năng được viết. Vì vậy, chỉ cần nhanh lên và đợi 10.000 kết nối thay vì 100, ok đó là điều gì đó, nhưng nó sẽ đưa bạn đến đâu? . Bởi vì cuối cùng, mọi cơ sở dữ liệu trên trái đất cuối cùng đều có một cánh tay từ tính lướt qua đĩa hoặc đọc bộ nhớ trạng thái rắn và điều đó giả định rằng bạn đang sử dụng cùng một máy, trái ngược với việc phân phối dữ liệu qua một nhóm kết nối mạng chậm hơn nhiều. Sau đó, bạn có vấn đề đơn luồng. Có lẽ không có ngôn ngữ nào bị lạm dụng nhiều hơn Javascript vì rào cản gia nhập quá thấp. Và mặc dù những người dùng đầu tiên có thể hiểu một cách làm không tốt khi họ nhìn thấy, nhưng hầu hết các lập trình viên javascript chỉ đơn giản là không biết họ đang làm gì. Thứ ba, Javascript không hẳn là một ngôn ngữ đặc biệt nhanh, vì vậy lời khuyên có vẻ là đừng thực hiện các tác vụ chuyên sâu về tính toán. Điều đó đưa bạn đến đâu?

M

Điều trớ trêu là lambda's (hay còn gọi là phương thức ẩn danh) là cơ sở của cả javascript và kỹ thuật ưa thích để triển khai nhiều kiểu gọi lại của C #, mặc dù có kiểu an toàn đầy đủ. Trên thực tế, các đặc điểm chính của nút (2 chiều, nhẹ, không đồng bộ đã được triển khai hiệu quả trong C# dưới dạng "SignalR" và có một số tính năng ngôn ngữ vừa không đồng bộ vừa đa luồng, (không giống như nút. js). Bây giờ tôi có thể hiểu nếu trải nghiệm của bạn với ORM bị giới hạn ở Hibernate (hoàn toàn khủng khiếp, một trong những triển khai tồi tệ nhất của một khái niệm chính mà tôi từng không hài lòng khi làm việc) hoặc thậm chí là EF, ít nhất là khá mạnh mẽ và biểu cảm do . Nhưng một ORM vi mô như Dapper mang lại cho bạn tất cả tính linh hoạt và sức mạnh của SQL trực tiếp với lợi ích của việc thao tác dữ liệu phong phú thông qua các đối tượng và nhanh, rất nhanh. Và tôi xin lỗi, nhưng OOP là một chiến lược thiết kế rất hiệu quả, đã được chứng minh nếu bạn biết mình đang làm gì, tôi. e. , bạn là dân chuyên nghiệp. Tôi thấy có ba vấn đề lớn với nút. js mà dường như không ai có câu trả lời hay cho. Vì vậy, bạn bắt đầu với tiền đề rằng việc chờ đợi IO không hiệu quả đến mức có tiềm năng to lớn ở đó. Vì vậy, vâng, bạn đã có tính đồng thời tuyệt vời, ngay cho đến khi bạn đến thư viện chặn đầu tiên, cơ sở dữ liệu, máy chủ tệp, v.v., thực tế là mọi phần chính của chức năng được viết. Vì vậy, chỉ cần nhanh lên và đợi 10.000 kết nối thay vì 100, ok đó là điều gì đó, nhưng nó sẽ đưa bạn đến đâu? . Bởi vì cuối cùng, mọi cơ sở dữ liệu trên trái đất cuối cùng đều có một cánh tay từ tính lướt qua đĩa hoặc đọc bộ nhớ trạng thái rắn và điều đó giả định rằng bạn đang sử dụng cùng một máy, trái ngược với việc phân phối dữ liệu qua một nhóm kết nối mạng chậm hơn nhiều. Sau đó, bạn có vấn đề đơn luồng. Có lẽ không có ngôn ngữ nào bị lạm dụng nhiều hơn Javascript vì rào cản gia nhập quá thấp. Và mặc dù những người dùng đầu tiên có thể hiểu một cách làm không tốt khi họ nhìn thấy, nhưng hầu hết các lập trình viên javascript chỉ đơn giản là không biết họ đang làm gì. Thứ ba, Javascript không hẳn là một ngôn ngữ đặc biệt nhanh, vì vậy lời khuyên có vẻ là đừng thực hiện các tác vụ chuyên sâu về tính toán. Điều đó đưa bạn đến đâu?

M

Wow, đó là một tuyên bố thiếu hiểu biết nghiêm trọng. Tải tệp lên máy chủ web là *THE* đã nêu lý do của nút. js về lý do tại sao anh ấy muốn có một thư viện không chặn. Vì vậy, khi bạn fanboi thoát ra khỏi thế giới cắt và dán mã đơn luồng, năng động chậm chạp với loại không an toàn, đa luồng và chỉ có một mẹo nhỏ (lambdas) để khớp. Nets nhiều khả năng không đồng bộ, (tất cả để bạn có thể thu hút thêm gấp 10 lần người dùng nhanh lên và chờ IO), sau đó bạn có thể giảng cho chúng tôi về "sự phức tạp". Các. Net framework có bộ tính năng tiên tiến hơn rất nhiều so với bất kỳ ngôn ngữ nào bạn có thể đặt tên, dấu chấm và IIS, được định cấu hình đúng cách, có thể đánh bại Apache và có thể dễ dàng khớp nginx làm proxy ngược hoặc cho nội dung tĩnh. Cuối cùng, bạn đã có một số vấn đề khó chữa. 1. Javascript chậm và công nghệ bạn chọn là đơn luồng, vì vậy các tác vụ điện toán chuyên sâu không phải bàn. 2. Gỡ lỗi Javascript và thử nghiệm vượt trội so với bất kỳ ngôn ngữ đánh máy nào. Chuyên gia sử dụng thử nghiệm rộng rãi, không bay theo quần 'này, nó hoạt động'. 3. Cách tiếp cận 'mọi thứ đều là mô-đun' không phải là một kiến ​​trúc, nó là một lời mời đến sự hỗn loạn, giống như Perl hoặc PHP. 4. Đồng thời không mua cho bạn những thứ tào lao nếu tất cả những gì bạn đang làm là chờ đợi một số quy trình ràng buộc IO khác, đó là hầu hết mọi thứ đáng để làm với máy tính. 5. Chất lượng và kinh nghiệm của nhiều lập trình viên javascript (không phải nút. js, nhưng sự phổ biến sẽ mang lại cho họ) rất kém, thể hiện qua các bình luận trong đó fanboi chứng minh rằng họ không biết làm thế nào các hệ thống khác thực sự không bỏ qua bất kỳ vấn đề máy tính nào mà họ không thể giải quyết được.

M

Wow, đó là một tuyên bố thiếu hiểu biết nghiêm trọng. Tải tệp lên máy chủ web là *THE* đã nêu lý do của nút. js về lý do tại sao anh ấy muốn có một thư viện không chặn. Vì vậy, khi bạn fanboi thoát ra khỏi thế giới cắt và dán mã đơn luồng, năng động chậm chạp với loại không an toàn, đa luồng và chỉ có một mẹo nhỏ (lambdas) để khớp. Nets nhiều khả năng không đồng bộ, (tất cả để bạn có thể thu hút thêm gấp 10 lần người dùng nhanh lên và chờ IO), sau đó bạn có thể giảng cho chúng tôi về "sự phức tạp". Các. Net framework có bộ tính năng tiên tiến hơn rất nhiều so với bất kỳ ngôn ngữ nào bạn có thể đặt tên, dấu chấm và IIS, được định cấu hình đúng cách, có thể đánh bại Apache và có thể dễ dàng khớp nginx làm proxy ngược hoặc cho nội dung tĩnh. Cuối cùng, bạn đã có một số vấn đề khó chữa. 1. Javascript chậm và công nghệ bạn chọn là đơn luồng, vì vậy các tác vụ điện toán chuyên sâu không phải bàn. 2. Gỡ lỗi Javascript và thử nghiệm vượt trội so với bất kỳ ngôn ngữ đánh máy nào. Chuyên gia sử dụng thử nghiệm rộng rãi, không bay theo quần 'này, nó hoạt động'. 3. Cách tiếp cận 'mọi thứ đều là mô-đun' không phải là một kiến ​​trúc, nó là một lời mời đến sự hỗn loạn, giống như Perl hoặc PHP. 4. Đồng thời không mua cho bạn những thứ tào lao nếu tất cả những gì bạn đang làm là chờ đợi một số quy trình ràng buộc IO khác, đó là hầu hết mọi thứ đáng để làm với máy tính. 5. Chất lượng và kinh nghiệm của nhiều lập trình viên javascript (không phải nút. js, nhưng sự phổ biến sẽ mang lại cho họ) rất kém, thể hiện qua các bình luận trong đó fanboi chứng minh rằng họ không biết làm thế nào các hệ thống khác thực sự không bỏ qua bất kỳ vấn đề máy tính nào mà họ không thể giải quyết được.

Bể bơi Lambda

ORM chỉ là giải pháp cho vấn đề trở kháng không phù hợp, không có gì khác. Nó không phải là vấn đề lớn, về OO, nó là một mô hình chéo giống như AOP và nó không thực sự dựa trên bất cứ thứ gì khác ngoài sự đóng gói. Không có mô hình thủ tục OO không làm gì cả, mọi lập trình viên lành nghề thực sự đều biết rằng

Bể bơi Lambda

ORM chỉ là giải pháp cho vấn đề trở kháng không phù hợp, không có gì khác. Nó không phải là vấn đề lớn, về OO, nó là một mô hình chéo giống như AOP và nó không thực sự dựa trên bất cứ thứ gì khác ngoài sự đóng gói. Không có mô hình thủ tục OO không làm gì cả, mọi lập trình viên lành nghề thực sự đều biết rằng

M

Sự không phù hợp trở kháng liên quan đến tất cả các loại phân nhánh, đặc biệt là liên quan đến khả năng bảo trì, tính di động, khả năng mở rộng và hiệu suất. Để trích dẫn Ethan ở trên (vì lời giải thích của tôi rõ ràng là không có). ". đó 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. " "về OO, nó là một mô hình chéo giống như AOP và nó không thực sự dựa trên bất cứ điều gì khác ngoài sự đóng gói. Nếu không có mô hình thủ tục thì OO chẳng làm được gì" Ok, tôi chắc chắn sẽ truyền bá thông điệp rằng chúng ta nên ngừng đùa giỡn với tất cả những thứ OOP bí truyền này và quay lại với một ngôn ngữ cho phép chúng ta thực hiện mọi thứ trực quan hóa sự đóng gói. VB6. Bạn sẽ nghĩ rằng một lập trình viên Javascript có thể muốn đề cập đến tính kế thừa, nếu không phải là tính đa hình, vì javascript có một cơ chế tương đối khác thường đối với nó. nguyên mẫu

M

Sự không phù hợp trở kháng liên quan đến tất cả các loại phân nhánh, đặc biệt là liên quan đến khả năng bảo trì, tính di động, khả năng mở rộng và hiệu suất. Để trích dẫn Ethan ở trên (vì lời giải thích của tôi rõ ràng là không có). ". đó 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. " "về OO, nó là một mô hình chéo giống như AOP và nó không thực sự dựa trên bất cứ điều gì khác ngoài sự đóng gói. Nếu không có mô hình thủ tục thì OO chẳng làm được gì" Ok, tôi chắc chắn sẽ truyền bá thông điệp rằng chúng ta nên ngừng đùa giỡn với tất cả những thứ OOP bí truyền này và quay lại với một ngôn ngữ cho phép chúng ta thực hiện mọi thứ trực quan hóa sự đóng gói. VB6. Bạn sẽ nghĩ rằng một lập trình viên Javascript có thể muốn đề cập đến tính kế thừa, nếu không phải là tính đa hình, vì javascript có một cơ chế tương đối khác thường đối với nó. nguyên mẫu

M

Một singleton là một đối tượng có thể khởi tạo (không tĩnh) với một hàm tạo riêng để chỉ có thể tạo một thể hiện duy nhất. (Hãy tưởng tượng một lớp thể hiện với một thuộc tính tĩnh hiển thị một thể hiện của chính nó phụ thuộc vào một hàm tạo cá thể riêng). Nó đã thực sự được thực hiện trong Java trước đây. mạng tồn tại. Có lẽ những gì bạn đang nghĩ đến là cơ chế Gọi lại không chặn, được xử lý trong C# thông qua các đại biểu, sự kiện (đại biểu phát đa hướng) và các từ khóa async và await mới biến C# tiêu chuẩn thành lambda để được thực thi tại thời điểm biên dịch. Nó cũng xử lý các hoạt động không đồng bộ đa luồng thông qua các tiện ích mở rộng Song song, cho phép trải tải trên nhiều luồng/lõi miễn là công việc đó không có tính chất nối tiếp. Ngoài ra, tôi khuyến khích bạn kiểm tra một ORM vi mô như Dapper. Nó kém toàn diện hơn nhiều so với EF, nhưng nó linh hoạt hơn nhiều và không gây cản trở, cộng với nó hiệu quả hơn đáng kể so với Hibernate và EF (nhanh hơn khoảng 5 lần để đọc)

M

Một singleton là một đối tượng có thể khởi tạo (không tĩnh) với một hàm tạo riêng để chỉ có thể tạo một thể hiện duy nhất. (Hãy tưởng tượng một lớp thể hiện với một thuộc tính tĩnh hiển thị một thể hiện của chính nó phụ thuộc vào một hàm tạo cá thể riêng). Nó đã thực sự được thực hiện trong Java trước đây. mạng tồn tại. Có lẽ những gì bạn đang nghĩ đến là cơ chế Gọi lại không chặn, được xử lý trong C# thông qua các đại biểu, sự kiện (đại biểu phát đa hướng) và các từ khóa async và await mới biến C# tiêu chuẩn thành lambda để được thực thi tại thời điểm biên dịch. Nó cũng xử lý các hoạt động không đồng bộ đa luồng thông qua các tiện ích mở rộng Song song, cho phép trải tải trên nhiều luồng/lõi miễn là công việc đó không có tính chất nối tiếp. Ngoài ra, tôi khuyến khích bạn kiểm tra một ORM vi mô như Dapper. Nó kém toàn diện hơn nhiều so với EF, nhưng nó linh hoạt hơn nhiều và không gây cản trở, cộng với nó hiệu quả hơn đáng kể so với Hibernate và EF (nhanh hơn khoảng 5 lần để đọc)

Qalandar

Có bài viết này làm rung chuyển ngực. Esp tốt cho người Croatia có ESL. ;) #nodeboy

Qalandar

Có bài viết này làm rung chuyển ngực. Esp tốt cho người Croatia có ESL. ;) #nodeboy

Ty Turner

Chúng tôi đang tìm kiếm một Nút. nhà phát triển js. Vui lòng xem http. // cao hơn. com/careers/search-jobs/ để biết chi tiết. Cảm ơn bạn

Ty Turner

Chúng tôi đang tìm kiếm một Nút. nhà phát triển js. Vui lòng xem http. // cao hơn. com/careers/search-jobs/ để biết chi tiết. Cảm ơn bạn

Vob Bobily

Vì vậy, sau khi đọc bài viết của bạn, tôi vẫn chưa hiểu tại sao Node js muốn phát minh lại bánh xe. Tôi vẫn nghĩ nút js và lượt thích là tào lao

Vob Bobily

Vì vậy, sau khi đọc bài viết của bạn, tôi vẫn chưa hiểu tại sao Node js muốn phát minh lại bánh xe. Tôi vẫn nghĩ nút js và lượt thích là tào lao

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

Đa-ni-ên

câu hỏi của người mới. Ừm, bạn có thể di chuyển dữ liệu yêu cầu không dễ dàng (tôi. e. dữ liệu không đáng tin cậy) vào cơ sở dữ liệu (nơi dữ liệu được coi là đáng tin cậy) là một mối nguy hiểm lớn? . js đã nghĩ đến điều này, nhưng tôi nhớ lại khi Rails cập nhật mô hình chăn. Điều đó đã thay đổi thực sự nhanh chóng khi việc sử dụng "tính năng" này của Github bị khai thác (may mắn thay, bởi một người mũ trắng). Ngoài ra, tất nhiên, chỉ vì bạn thêm một cú hích tốc độ chuyển đổi không có nghĩa là mọi người sẽ không mắc lỗi, nhưng ít nhất họ có nhiều khả năng sẽ suy nghĩ kỹ hơn, điều đó có thể có nghĩa là họ sẽ mắc ít lỗi hơn

Đa-ni-ên

câu hỏi của người mới. Ừm, bạn có thể di chuyển dữ liệu yêu cầu không dễ dàng (tôi. e. dữ liệu không đáng tin cậy) vào cơ sở dữ liệu (nơi dữ liệu được coi là đáng tin cậy) là một mối nguy hiểm lớn? . js đã nghĩ đến điều này, nhưng tôi nhớ lại khi Rails cập nhật mô hình chăn. Điều đó đã thay đổi thực sự nhanh chóng khi việc sử dụng "tính năng" này của Github bị khai thác (may mắn thay, bởi một người mũ trắng). Ngoài ra, tất nhiên, chỉ vì bạn thêm một cú hích tốc độ chuyển đổi không có nghĩa là mọi người sẽ không mắc lỗi, nhưng ít nhất họ có nhiều khả năng sẽ suy nghĩ kỹ hơn, điều đó có thể có nghĩa là họ sẽ mắc ít lỗi hơn

Q

Tôi không hiểu cảm giác lo lắng khi sử dụng ORM. Bạn có đang ở trong một môi trường thích hợp, nơi các mối quan tâm được tách biệt? . Tại sao tôi lại muốn chuyển từ việc viết phần mềm bằng Java/C#/_whatever_ sang SQL, nơi khó phiên bản, kiểm tra đúng cách và rõ ràng có thể gây tổn thương não nghiêm trọng? . Tùy thuộc vào tình huống SQL thô có thể là tốt nhất. có thể tốt hơn nếu sử dụng cửa hàng NoQuery. có lẽ một ORM là tốt. Thông thường, từ kinh nghiệm của tôi, tôi có thể nói với bạn rằng ORM tốt hơn vì nhiều lý do và chúng đã được chuyển tiếp bởi M. Tôi đã dành thời gian để viết các thư viện của riêng mình để trừu tượng hóa các triển khai cụ thể của nhà cung cấp và bạn cần tạo ánh xạ của riêng mình. Bạn có thể dễ dàng sinh ra từ một trạng thái nhất định hoặc sử dụng các cấu trúc dữ liệu hiện có. Tôi đã mất thời gian để viết các thư viện của mình và không hề dễ dàng chút nào để làm điều đó nhưng tôi rất xứng đáng với thời gian của mình vì giờ đây tôi có thể sử dụng lại các thư viện của mình. Nó có phải là TỐT NHẤT không? . Tôi thích nó nhưng tôi chắc chắn sẽ không đi đến các bài báo kỹ thuật tùy tiện không liên quan gì đến SQL và đăng những thứ như "Vâng, công nghệ này tốt nhưng hãy tránh xa SQL thô. " Tôi không thấy cần phải đả kích bất cứ thứ gì ở đây, đặc biệt là ORM khi bài viết chỉ nói về JS và NodeJS

Q

Tôi không hiểu cảm giác lo lắng khi sử dụng ORM. Bạn có đang ở trong một môi trường thích hợp, nơi các mối quan tâm được tách biệt? . Tại sao tôi lại muốn chuyển từ việc viết phần mềm bằng Java/C#/_whatever_ sang SQL, nơi khó phiên bản, kiểm tra đúng cách và rõ ràng có thể gây tổn thương não nghiêm trọng? . Tùy thuộc vào tình huống SQL thô có thể là tốt nhất. có thể tốt hơn nếu sử dụng cửa hàng NoQuery. có lẽ một ORM là tốt. Thông thường, từ kinh nghiệm của tôi, tôi có thể nói với bạn rằng ORM tốt hơn vì nhiều lý do và chúng đã được chuyển tiếp bởi M. Tôi đã dành thời gian để viết các thư viện của riêng mình để trừu tượng hóa các triển khai cụ thể của nhà cung cấp và bạn cần tạo ánh xạ của riêng mình. Bạn có thể dễ dàng sinh ra từ một trạng thái nhất định hoặc sử dụng các cấu trúc dữ liệu hiện có. Tôi đã mất thời gian để viết các thư viện của mình và không hề dễ dàng chút nào để làm điều đó nhưng tôi rất xứng đáng với thời gian của mình vì giờ đây tôi có thể sử dụng lại các thư viện của mình. Nó có phải là TỐT NHẤT không? . Tôi thích nó nhưng tôi chắc chắn sẽ không đi đến các bài báo kỹ thuật tùy tiện không liên quan gì đến SQL và đăng những thứ như "Vâng, công nghệ này tốt nhưng hãy tránh xa SQL thô. " Tôi không thấy cần phải đả kích bất cứ thứ gì ở đây, đặc biệt là ORM khi bài viết chỉ nói về JS và NodeJS

Michael

Có lẽ một trong những điểm chính của bài viết này, mang lại cho Node khả năng mở rộng, là việc giảm tải cho Hàng đợi hoặc Xe buýt dịch vụ dẫn đến xử lý không đồng bộ. Đó là một mẫu kiến ​​trúc đã được chứng minh rõ ràng, có sẵn trong nhiều ngôn ngữ, đặc biệt được sử dụng trong CQRS (Phân tách trách nhiệm truy vấn lệnh) với Tìm nguồn cung ứng sự kiện, rất phù hợp để sử dụng bởi các công nghệ như vậy. Net Reactive Extensions cung cấp chức năng và tính linh hoạt cao hơn đáng kể so với Node. Lập trình không đồng bộ và xử lý các cạm bẫy của nó đã tồn tại mà không có Node trong nhiều năm, nếu bạn có kiến ​​thức về phát triển doanh nghiệp. Đối với sự ghét bỏ đối với ORM. các bạn đang chỉ trích rằng có vẻ như nó đang chuyển từ phát triển giao diện người dùng sang một lĩnh vực mà bạn không có kiến ​​thức hoặc chuyên môn về OO, BDD, TDD hoặc bất kỳ phương pháp cấp Doanh nghiệp đã được chứng minh nào khác. Không có khái niệm tích hợp nào ngoài nguồn cấp dữ liệu Twitter. Không có kinh nghiệm về Quy trình làm việc phức tạp hoặc bộ nhớ đệm có thể mở rộng. Đây là một trong những mối nguy hiểm - bạn biết JavaScript và một chút SQL. Vì vậy, mọi thứ khác đều không cần thiết - cho đến khi bạn cần nó, chẳng hạn như nỗ lực đưa một phần tử kiểm tra kiểu vào JavaScript. Nghiêm túc mà nói, mỗi công nghệ đều có vị trí của nó, nhưng không có một cách tiếp cận nào phù hợp với tất cả. Đánh giá cao điểm mạnh của từng công nghệ và sử dụng chúng khi thích hợp

Michael

Có lẽ một trong những điểm chính của bài viết này, mang lại cho Node khả năng mở rộng, là việc giảm tải cho Hàng đợi hoặc Xe buýt dịch vụ dẫn đến xử lý không đồng bộ. Đó là một mẫu kiến ​​trúc đã được chứng minh rõ ràng, có sẵn trong nhiều ngôn ngữ, đặc biệt được sử dụng trong CQRS (Phân tách trách nhiệm truy vấn lệnh) với Tìm nguồn cung ứng sự kiện, rất phù hợp để sử dụng bởi các công nghệ như vậy. Net Reactive Extensions cung cấp chức năng và tính linh hoạt cao hơn đáng kể so với Node. Lập trình không đồng bộ và xử lý các cạm bẫy của nó đã tồn tại mà không có Node trong nhiều năm, nếu bạn có kiến ​​thức về phát triển doanh nghiệp. Đối với sự ghét bỏ đối với ORM. các bạn đang chỉ trích rằng có vẻ như nó đang chuyển từ phát triển giao diện người dùng sang một lĩnh vực mà bạn không có kiến ​​thức hoặc chuyên môn về OO, BDD, TDD hoặc bất kỳ phương pháp cấp Doanh nghiệp đã được chứng minh nào khác. Không có khái niệm tích hợp nào ngoài nguồn cấp dữ liệu Twitter. Không có kinh nghiệm về Quy trình làm việc phức tạp hoặc bộ nhớ đệm có thể mở rộng. Đây là một trong những mối nguy hiểm - bạn biết JavaScript và một chút SQL. Vì vậy, mọi thứ khác đều không cần thiết - cho đến khi bạn cần nó, chẳng hạn như nỗ lực đưa một phần tử kiểm tra kiểu vào JavaScript. Nghiêm túc mà nói, mỗi công nghệ đều có vị trí của nó, nhưng không có một cách tiếp cận nào phù hợp với tất cả. Đánh giá cao điểm mạnh của từng công nghệ và sử dụng chúng khi thích hợp

Reo

Giới thiệu tuyệt vời về nút. js. Cảm ơn, tôi đã ngủ trưa

Reo

Giới thiệu tuyệt vời về nút. js. Cảm ơn, tôi đã ngủ trưa

Richard Bellantoni

Bởi vì chúng không phù hợp với một ứng dụng phức tạp. Chắc chắn nếu kịch bản của bạn mà bạn đã dành toàn bộ thời gian để cố gắng làm cho ORM hoạt động theo cách bạn cần, thì bạn có thể chỉ cần nỗ lực như vậy để viết SQL đúng cách và đảm bảo rằng nó được tổ chức, v.v. và bạn sẽ tiến xa hơn trong . ORM rất tuyệt vời trong việc tiết kiệm thời gian cho một dự án quy mô vừa và nhỏ, nhưng một khi bạn nghiên cứu kỹ các ứng dụng lớn hơn và phức tạp hơn, bạn sẽ chi tiêu A. ) Mất nhiều thời gian viết mã để làm cho ORM hoạt động theo cách bạn cần hoặc B. ) Chỉ cần quyết định tự viết SQL vì thời gian cần thiết để làm cho công cụ hoạt động theo cách bạn cần là không xứng đáng

Richard Bellantoni

Bởi vì chúng không phù hợp với một ứng dụng phức tạp. Chắc chắn nếu kịch bản của bạn mà bạn đã dành toàn bộ thời gian để cố gắng làm cho ORM hoạt động theo cách bạn cần, thì bạn có thể chỉ cần nỗ lực như vậy để viết SQL đúng cách và đảm bảo rằng nó được tổ chức, v.v. và bạn sẽ tiến xa hơn trong . ORM rất tuyệt vời trong việc tiết kiệm thời gian cho một dự án quy mô vừa và nhỏ, nhưng một khi bạn nghiên cứu kỹ các ứng dụng lớn hơn và phức tạp hơn, bạn sẽ chi tiêu A. ) Mất nhiều thời gian viết mã để làm cho ORM hoạt động theo cách bạn cần hoặc B. ) Chỉ cần quyết định tự viết SQL vì thời gian cần thiết để làm cho công cụ hoạt động theo cách bạn cần là không xứng đáng

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

Nồi, gặp ấm đun nước. Đó có thể là những vấn đề nan giải nếu bất kỳ vấn đề nào trong số đó là sự thật. Không ai trong số họ là. 1. a) Ngày nay, JavaScript hoàn toàn là JIT và mang lại hiệu suất mã gốc gấp 1-2 lần (nhanh hơn bất kỳ ngôn ngữ động nào khác mà tôi biết). b) Không chặn theo mặc định có thể mang lại các cải tiến về mức độ hiệu quả của mã - một cách minh bạch. 2. Hầu như tất cả các trình soạn thảo hiện đại đều hỗ trợ suy luận kiểu cho JS. ESLint, Trình biên dịch đóng cửa và một số tùy chọn khác cung cấp khả năng phân tích tĩnh tinh vi. TypeScript thậm chí còn cung cấp một hệ thống kiểu cấu trúc đẹp. 3. Đối lập với mô-đun là một khối nguyên khối được liên kết chặt chẽ. Đó là một ý tưởng tồi trong bất kỳ ngôn ngữ nào. 4. "nếu tất cả những gì bạn đang làm là chờ đợi một số quy trình ràng buộc IO khác" - Không chặn theo mặc định có nghĩa là bạn KHÔNG BAO GIỜ chờ đợi một số quy trình ràng buộc IO khác. Đó là lý do tại sao Node mang lại những cải tiến lớn như vậy về việc sử dụng tài nguyên. 5. 2006 được gọi là. Họ muốn thái độ hợm hĩnh ngôn ngữ của họ trở lại. Những ngày mà các kỹ sư nghiêm túc coi JS là một món đồ chơi đã qua lâu rồi. JS cung cấp năng lượng cho các ứng dụng doanh nghiệp phức tạp chỉ với 500 tài sản ngày nay. điểm bổ sung. JS là ngôn ngữ duy nhất có hỗ trợ hoàn toàn riêng cho mã đẳng cấu (có nghĩa là bạn sử dụng lại hầu hết ứng dụng của mình trên cả máy chủ và máy khách). Bạn có thể viết JS MỘT LẦN và nó sẽ cung cấp năng lượng cho máy chủ, trình duyệt web và thiết bị di động bao gồm iOS và Android. Xem phản ứng bản địa. https. // leanpub. com/learning-javascript-react-nodejs-es6/

Eric Elliott

Nồi, gặp ấm đun nước. Đó có thể là những vấn đề nan giải nếu bất kỳ vấn đề nào trong số đó là sự thật. Không ai trong số họ là. 1. a) Ngày nay, JavaScript hoàn toàn là JIT và mang lại hiệu suất mã gốc gấp 1-2 lần (nhanh hơn bất kỳ ngôn ngữ động nào khác mà tôi biết). b) Không chặn theo mặc định có thể mang lại các cải tiến về mức độ hiệu quả của mã - một cách minh bạch. 2. Hầu như tất cả các trình soạn thảo hiện đại đều hỗ trợ suy luận kiểu cho JS. ESLint, Trình biên dịch đóng cửa và một số tùy chọn khác cung cấp khả năng phân tích tĩnh tinh vi. TypeScript thậm chí còn cung cấp một hệ thống kiểu cấu trúc đẹp. 3. Đối lập với mô-đun là một khối nguyên khối được liên kết chặt chẽ. Đó là một ý tưởng tồi trong bất kỳ ngôn ngữ nào. 4. "nếu tất cả những gì bạn đang làm là chờ đợi một số quy trình ràng buộc IO khác" - Không chặn theo mặc định có nghĩa là bạn KHÔNG BAO GIỜ chờ đợi một số quy trình ràng buộc IO khác. Đó là lý do tại sao Node mang lại những cải tiến lớn như vậy về việc sử dụng tài nguyên. 5. 2006 được gọi là. Họ muốn thái độ hợm hĩnh ngôn ngữ của họ trở lại. Những ngày mà các kỹ sư nghiêm túc coi JS là một món đồ chơi đã qua lâu rồi. JS cung cấp năng lượng cho các ứng dụng doanh nghiệp phức tạp chỉ với 500 tài sản ngày nay. điểm bổ sung. JS là ngôn ngữ duy nhất có hỗ trợ hoàn toàn riêng cho mã đẳng cấu (có nghĩa là bạn sử dụng lại hầu hết ứng dụng của mình trên cả máy chủ và máy khách). Bạn có thể viết JS MỘT LẦN và nó sẽ cung cấp năng lượng cho máy chủ, trình duyệt web và thiết bị di động bao gồm iOS và Android. Xem phản ứng bản địa. https. // leanpub. com/learning-javascript-react-nodejs-es6/

M

1) Hiệu suất mã gốc gấp 1-2 lần? . 2) Suy luận kiểu đang ánh xạ các khai báo biến thành các kiểu không có cú pháp rõ ràng, tôi. e. , a) nó yêu cầu các loại thực tế và b) trình biên dịch thực thi an toàn loại, không phải trình chỉnh sửa. Và bạn có thể trang trí nó theo bất kỳ cách nào bạn muốn, nhưng không có cách nào để thực thi phân tích trạng thái phức tạp với các từ điển cẩu thả của bất kỳ thứ gì được lưu trữ trong chuỗi và các đại biểu chức năng. Ngoài ra, Bản mô tả không phải là Javascript, nó là Javascript với hệ thống loại nửa vời được dán lên trên. Ngay cả Google cũng đang từ bỏ Js cho Bản mô tả trong Angular 2. 0 Tại sao? . Nhưng liệu hệ thống kiểu đó có phức tạp như một ngôn ngữ được biên dịch không? . 3) Bạn đang hiểu sai những gì tôi đã mô tả là "thiết kế mô-đun". Giải pháp thay thế không phải là mã nguyên khối, mà là đóng gói, chuyên môn hóa thông qua kế thừa (hoặc tạo mẫu), đa hình và phụ thuộc bên ngoài thông qua IoC. Thay thế là RẮN, tôi. e. , Hướng đối tượng hiện đại. 4) Quá trình của bạn có thể không chờ đợi, nhưng khách hàng của bạn đang chờ gọi lại. Quan điểm của tôi là việc có thể phục vụ nhiều yêu cầu hơn không giúp ích gì cho bạn nếu mọi yêu cầu được phục vụ sau đó phải chờ một hoạt động khác. Cuối cùng, ở một nơi nào đó, cuối cùng bạn sẽ chuyển sang đĩa hoặc chờ IO, bởi vì đó là nơi thông tin mà khách hàng muốn tồn tại. 5) Tôi không nói rằng JavaScript là ngôn ngữ đồ chơi, tôi đã nói rằng hầu hết các nhà phát triển JavaScript đều có ý tốt, cắt và dán nghiệp dư và họ sẽ xâm chiếm hàng ngũ nút. js khi nó trở nên phổ biến hơn. Tôi sẽ sử dụng một hệ thống loại mạnh thay vì "hỗ trợ gốc đầy đủ" (không phải gốc) cho mã "đẳng cấp" có thể chạy trên máy khách hoặc máy chủ [bạn nói rằng đó là một điều tốt] bất kỳ ngày nào. Wow, Js trên Android và iOS. Tôi đoán rằng thời của Apple bổ sung một ngôn ngữ bản địa, được gõ mạnh khác cho iOS đã qua Rõ ràng là bạn chưa bao giờ nghe nói về Mono, nền tảng chéo. Net biên dịch và chạy trên mọi hệ điều hành chính, tạo thời gian chạy gốc cho cả ba nền tảng di động chính và chạy trên mọi thứ từ cụm beowulf đến thiết bị đeo được. Đây là lý do tại sao chúng tôi không tôn trọng bạn. Bạn không biết hoặc không hiểu bất cứ điều gì xảy ra trước đó hoặc bất kỳ điều gì bên ngoài bong bóng javascript của bạn. Bạn không giải quyết được bất kỳ vấn đề nào chưa được giải quyết trước đây, nhưng bạn tin rằng mình có tất cả các câu trả lời. Đó dường như là một chủ đề phổ biến với bất kỳ ai có hệ thống giáo dục nhấn mạnh lòng tự trọng hơn tư duy phản biện

M

1) Hiệu suất mã gốc gấp 1-2 lần? . 2) Suy luận kiểu đang ánh xạ các khai báo biến thành các kiểu không có cú pháp rõ ràng, tôi. e. , a) nó yêu cầu các loại thực tế và b) trình biên dịch thực thi an toàn loại, không phải trình chỉnh sửa. Và bạn có thể trang trí nó theo bất kỳ cách nào bạn muốn, nhưng không có cách nào để thực thi phân tích trạng thái phức tạp với các từ điển cẩu thả của bất kỳ thứ gì được lưu trữ trong chuỗi và các đại biểu chức năng. Ngoài ra, Bản mô tả không phải là Javascript, nó là Javascript với hệ thống loại nửa vời được dán lên trên. Ngay cả Google cũng đang từ bỏ Js cho Bản mô tả trong Angular 2. 0 Tại sao? . Nhưng liệu hệ thống kiểu đó có phức tạp như một ngôn ngữ được biên dịch không? . 3) Bạn đang hiểu sai những gì tôi đã mô tả là "thiết kế mô-đun". Giải pháp thay thế không phải là mã nguyên khối, mà là đóng gói, chuyên môn hóa thông qua kế thừa (hoặc tạo mẫu), đa hình và phụ thuộc bên ngoài thông qua IoC. Thay thế là RẮN, tôi. e. , Hướng đối tượng hiện đại. 4) Quá trình của bạn có thể không chờ đợi, nhưng khách hàng của bạn đang chờ gọi lại. Quan điểm của tôi là việc có thể phục vụ nhiều yêu cầu hơn không giúp ích gì cho bạn nếu mọi yêu cầu được phục vụ sau đó phải chờ một hoạt động khác. Cuối cùng, ở một nơi nào đó, cuối cùng bạn sẽ chuyển sang đĩa hoặc chờ IO, bởi vì đó là nơi thông tin mà khách hàng muốn tồn tại. 5) Tôi không nói rằng JavaScript là ngôn ngữ đồ chơi, tôi đã nói rằng hầu hết các nhà phát triển JavaScript đều có ý tốt, cắt và dán nghiệp dư và họ sẽ xâm chiếm hàng ngũ nút. js khi nó trở nên phổ biến hơn. Tôi sẽ sử dụng một hệ thống loại mạnh thay vì "hỗ trợ gốc đầy đủ" (không phải gốc) cho mã "đẳng cấp" có thể chạy trên máy khách hoặc máy chủ [bạn nói rằng đó là một điều tốt] bất kỳ ngày nào. Wow, Js trên Android và iOS. Tôi đoán rằng thời của Apple bổ sung một ngôn ngữ bản địa, được gõ mạnh khác cho iOS đã qua Rõ ràng là bạn chưa bao giờ nghe nói về Mono, nền tảng chéo. Net biên dịch và chạy trên mọi hệ điều hành chính, tạo thời gian chạy gốc cho cả ba nền tảng di động chính và chạy trên mọi thứ từ cụm beowulf đến thiết bị đeo được. Đây là lý do tại sao chúng tôi không tôn trọng bạn. Bạn không biết hoặc không hiểu bất cứ điều gì xảy ra trước đó hoặc bất kỳ điều gì bên ngoài bong bóng javascript của bạn. Bạn không giải quyết được bất kỳ vấn đề nào chưa được giải quyết trước đây, nhưng bạn tin rằng mình có tất cả các câu trả lời. Đó dường như là một chủ đề phổ biến với bất kỳ ai có hệ thống giáo dục nhấn mạnh lòng tự trọng hơn tư duy phản biện

Eric Elliott

Câu trả lời này chỉ gây ấn tượng với tôi là sự thiếu hiểu biết cố ý. 1. Có thật không? . Xem các bài nói chuyện trôi chảy của Brendan Eich nếu bạn thực sự muốn học điều gì đó. 2. Tôi biết kiểu và suy luận kiểu là gì, và tôi biết lợi ích của kiểu tĩnh. Tôi đã tham gia trò chơi này từ trước khi JavaScript được phát minh. TypeScript là một siêu bộ JavaScript biên dịch thành JS & cho phép phân tích tĩnh tinh vi. Hệ thống kiểu cấu trúc của nó tốt hơn hệ thống kiểu mà Java đã có khi tôi viết mã bằng Java và nó tốt hơn nhiều (về độ tin cậy và linh hoạt hơn) so với C và C++. 3. "đóng gói, chuyên môn hóa thông qua kế thừa (hoặc tạo mẫu), đa hình và phụ thuộc bên ngoài thông qua IoC" - đây đều là các dạng mô-đun và các mô-đun JavaScript cung cấp các lựa chọn thay thế khả thi cho tất cả chúng - và trong trường hợp kế thừa lớp, nó vượt trội hơn nhiều. Xem https. //vừa phải. com/javascript-scene/hai-trụ-của-javascript-ee6f3281e7f3 4. "khách hàng của bạn đang chờ cuộc gọi lại. " May mắn thay, đó là nơi màn trình diễn mà tôi đã nói ở điểm 1 tỏa sáng. JS cung cấp khả năng sử dụng hiệu quả tài nguyên I/O. Trên thực tế, xử lý tắc nghẽn I/O là toàn bộ lý do mà Node được phát minh. Tôi đã chuyển một số dự án sản xuất lớn từ PHP và Ruby sang Node và thấy thời gian phản hồi giảm đáng kể, cả thời gian phản hồi trung bình và phạm vi thời gian phản hồi - và vì một ứng dụng Node điển hình sử dụng một phần nhỏ bộ nhớ cần thiết cho các ứng dụng C#, . 5. "bạn nói như vậy là tốt" Tôi đã thấy sự gia tăng có thể đo lường khách quan về tốc độ của nhóm, từ 40% - 60% cải thiện. Tin hay không thì tùy, đó là sự thật và khả năng thích ứng với nhu cầu thay đổi và thử nghiệm nhiều hơn (đặc biệt là trong lớp giao diện người dùng) mang lại giá trị kinh doanh rất thực tế. Bạn nghĩ tại sao rất nhiều tổ chức doanh nghiệp đang áp dụng Node? . Đó là bởi vì họ đã tự chạy thử nghiệm và nhận ra rằng đó là một chiến thắng lớn. "Rõ ràng là bạn chưa bao giờ nghe nói về Mono, nền tảng chéo. Net biên dịch và chạy trên mọi hệ điều hành chính" Vâng, tôi có - điều tôi chưa từng nghe nói là Mono cung cấp ở bất kỳ đâu gần giá trị mà Node mang lại trong sản xuất doanh nghiệp. Có một bài viết tốt về điều đó? . Kiểm tra kết quả tuyệt vời này trong top 3 của 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. thế kỷlinkcloud. com/blog/post/node-js-is-take-over-the-enterprise-whether-you-like-it-or-not/ Thực sự không có cuộc thi nào ở đây

Eric Elliott

Câu trả lời này chỉ gây ấn tượng với tôi là sự thiếu hiểu biết cố ý. 1. Có thật không? . Xem các bài nói chuyện trôi chảy của Brendan Eich nếu bạn thực sự muốn học điều gì đó. 2. Tôi biết kiểu và suy luận kiểu là gì, và tôi biết lợi ích của kiểu tĩnh. Tôi đã tham gia trò chơi này từ trước khi JavaScript được phát minh. TypeScript là một siêu bộ JavaScript biên dịch thành JS & cho phép phân tích tĩnh tinh vi. Hệ thống kiểu cấu trúc của nó tốt hơn hệ thống kiểu mà Java đã có khi tôi viết mã bằng Java và nó tốt hơn nhiều (về độ tin cậy và linh hoạt hơn) so với C và C++. 3. "đóng gói, chuyên môn hóa thông qua kế thừa (hoặc tạo mẫu), đa hình và phụ thuộc bên ngoài thông qua IoC" - đây đều là các dạng mô-đun và các mô-đun JavaScript cung cấp các lựa chọn thay thế khả thi cho tất cả chúng - và trong trường hợp kế thừa lớp, nó vượt trội hơn nhiều. Xem https. //vừa phải. com/javascript-scene/hai-trụ-của-javascript-ee6f3281e7f3 4. "khách hàng của bạn đang chờ cuộc gọi lại. " May mắn thay, đó là nơi màn trình diễn mà tôi đã nói ở điểm 1 tỏa sáng. JS cung cấp khả năng sử dụng hiệu quả tài nguyên I/O. Trên thực tế, xử lý tắc nghẽn I/O là toàn bộ lý do mà Node được phát minh. Tôi đã chuyển một số dự án sản xuất lớn từ PHP và Ruby sang Node và thấy thời gian phản hồi giảm đáng kể, cả thời gian phản hồi trung bình và phạm vi thời gian phản hồi - và vì một ứng dụng Node điển hình sử dụng một phần nhỏ bộ nhớ cần thiết cho các ứng dụng C#, . 5. "bạn nói như vậy là tốt" Tôi đã thấy sự gia tăng có thể đo lường khách quan về tốc độ của nhóm, từ 40% - 60% cải thiện. Tin hay không thì tùy, đó là sự thật và khả năng thích ứng với nhu cầu thay đổi và thử nghiệm nhiều hơn (đặc biệt là trong lớp giao diện người dùng) mang lại giá trị kinh doanh rất thực tế. Bạn nghĩ tại sao rất nhiều tổ chức doanh nghiệp đang áp dụng Node? . Đó là bởi vì họ đã tự chạy thử nghiệm và nhận ra rằng đó là một chiến thắng lớn. "Rõ ràng là bạn chưa bao giờ nghe nói về Mono, nền tảng chéo. Net biên dịch và chạy trên mọi hệ điều hành chính" Vâng, tôi có - điều tôi chưa từng nghe nói là Mono cung cấp ở bất kỳ đâu gần giá trị mà Node mang lại trong sản xuất doanh nghiệp. Có một bài viết tốt về điều đó? . Kiểm tra kết quả tuyệt vời này trong top 3 của 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. thế kỷlinkcloud. com/blog/post/node-js-is-take-over-the-enterprise-whether-you-like-it-or-not/ Thực sự không có cuộc thi nào ở đây

M

1, vâng, tôi đang chế nhạo tuyên bố rõ ràng là tình cờ của bạn rằng JavaScript làm cho các điện tử chạy nhanh hơn hoặc thậm chí nhanh như bản địa, bởi vì đó là bằng sáng chế vô nghĩa. Điều đó không chỉ là không thể, nó còn bỏ qua một trong các nút. điểm yếu được thừa nhận của js. Nó hút các hoạt động tính toán chuyên sâu, bởi vì nó là một luồng đơn, có nghĩa là thực thi khối các hoạt động chuyên sâu tính toán. tât nhiên. 2. Kiến thức về Java của bạn không đủ để bạn hiểu hệ thống loại có thẩm quyền là gì. Generics của Java phần lớn là vô dụng, johnny gần đây cũng xuất hiện tính năng giống tôi khi so sánh với các generics của C# bởi vì chúng bị xóa trong thời gian chạy, nói cách khác, sự an toàn và phản chiếu kiểu chung chỉ hoạt động tại thời điểm biên dịch, bởi vì tại thời điểm chạy, . Vì vậy, khi bạn đang tiếp tục phân tích tĩnh, bạn đang cố gắng tuyên bố rằng nó tốt như phản ánh kiểu thời gian biên dịch + thời gian chạy, điều này rất xa sự thật. 3. meh. Việc chia nhỏ mọi thứ thành các chức năng riêng biệt cũng là một dạng mô-đun, nhưng nó kém hơn rất nhiều so với RẮN, đó là quan điểm của tôi ngay từ đầu. Và mặc dù kế thừa dựa trên nguyên mẫu rất thú vị, nhưng nó khó tốt hơn kế thừa thực, cho phép sắp xếp linh hoạt hơn nhiều. 4. Tôi không thấy việc tăng tốc ứng dụng Ruby hay cấu trúc lại một số PHP nhảm nhí thành thứ gì đó nhanh hơn ấn tượng như thế nào. Yêu cầu chi phí bộ nhớ của bạn là vô căn cứ như nhau. Tôi có thể chạy micro. Net trên đồng hồ hoặc trên thiết bị arduino. tôi có thể viết. Net chạy rất tốt trên điện thoại yếu. Xem bộ nhớ mà chrome tiêu thụ cho một SPA hoặc thử chạy một ứng dụng javascript phức tạp trên máy tính bảng rồi cho tôi biết JavaScript "nhẹ" như thế nào. 5. Việc thiếu sự phân tách hợp lý các mối quan tâm (là nguyên nhân của hầu hết các vấn đề về khả năng bảo trì) là vấn đề số một mà tôi gặp phải ở các khách hàng có quy mô doanh nghiệp và tốc độ làm việc nhóm ấn tượng luôn là cách họ đạt được điều đó. Tại sao tôi nghĩ rằng một số tổ chức đang chọn nút?

M

1, vâng, tôi đang chế nhạo tuyên bố rõ ràng là tình cờ của bạn rằng JavaScript làm cho các điện tử chạy nhanh hơn hoặc thậm chí nhanh như bản địa, bởi vì đó là bằng sáng chế vô nghĩa. Điều đó không chỉ là không thể, nó còn bỏ qua một trong các nút. điểm yếu được thừa nhận của js. Nó hút các hoạt động tính toán chuyên sâu, bởi vì nó là một luồng đơn, có nghĩa là thực thi khối các hoạt động chuyên sâu tính toán. tât nhiên. 2. Kiến thức về Java của bạn không đủ để bạn hiểu hệ thống loại có thẩm quyền là gì. Generics của Java phần lớn là vô dụng, johnny gần đây cũng xuất hiện tính năng giống tôi khi so sánh với các generics của C# bởi vì chúng bị xóa trong thời gian chạy, nói cách khác, sự an toàn và phản chiếu kiểu chung chỉ hoạt động tại thời điểm biên dịch, bởi vì tại thời điểm chạy, . Vì vậy, khi bạn đang tiếp tục phân tích tĩnh, bạn đang cố gắng tuyên bố rằng nó tốt như phản ánh kiểu thời gian biên dịch + thời gian chạy, điều này rất xa sự thật. 3. meh. Việc chia nhỏ mọi thứ thành các chức năng riêng biệt cũng là một dạng mô-đun, nhưng nó kém hơn rất nhiều so với RẮN, đó là quan điểm của tôi ngay từ đầu. Và mặc dù kế thừa dựa trên nguyên mẫu rất thú vị, nhưng nó khó tốt hơn kế thừa thực, cho phép sắp xếp linh hoạt hơn nhiều. 4. Tôi không thấy việc tăng tốc ứng dụng Ruby hay cấu trúc lại một số PHP nhảm nhí thành thứ gì đó nhanh hơn ấn tượng như thế nào. Yêu cầu chi phí bộ nhớ của bạn là vô căn cứ như nhau. Tôi có thể chạy micro. Net trên đồng hồ hoặc trên thiết bị arduino. tôi có thể viết. Net chạy rất tốt trên điện thoại yếu. Xem bộ nhớ mà chrome tiêu thụ cho một SPA hoặc thử chạy một ứng dụng javascript phức tạp trên máy tính bảng rồi cho tôi biết JavaScript "nhẹ" như thế nào. 5. Việc thiếu sự phân tách hợp lý các mối quan tâm (là nguyên nhân của hầu hết các vấn đề về khả năng bảo trì) là vấn đề số một mà tôi gặp phải ở các khách hàng có quy mô doanh nghiệp và tốc độ làm việc nhóm ấn tượng luôn là cách họ đạt được điều đó. Tại sao tôi nghĩ rằng một số tổ chức đang chọn nút?

Eric Elliott

1. Tôi nghĩ bạn đã hiểu sai ý của tôi. JS chạy CHẬM 1-2 lần so với bản địa -- hiệu suất tốt hơn nhiều so với bất kỳ ngôn ngữ động nào khác mà tôi biết. Nó đủ nhanh để chạy các công cụ trò chơi AAA như Unreal Engine và Unity với chất lượng tuyệt đẹp ở hơn 60 khung hình / giây. 2. Tôi thực sự nghĩ rằng một công cụ kiểu gốc tốt sẽ là một bổ sung tốt cho JavaScript, nhưng chỉ khi chúng là các kiểu cấu trúc do người dùng định nghĩa. Điều đó nói rằng, JavaScript hỗ trợ phân tích tĩnh thông qua suy luận kiểu và có một số cách để cung cấp gợi ý kiểu cho các công cụ dành cho nhà phát triển. Ngoài ra, JavaScript còn có một loạt các công cụ phân tích thời gian chạy ấn tượng. 3. "hầu như không tốt hơn thừa kế thực sự, cho phép sắp xếp linh hoạt hơn nhiều. " Sai. https. //vừa phải. com/javascript-scene/hai-trụ-của-javascript-ee6f3281e7f3 4. Lời xin lỗi của tôi. Tôi đã không biết về vi mô. Mạng lưới. JavaScript cũng chạy nguyên trạng trên các thiết bị có công suất thấp bao gồm Arduino, Tessel và một số thiết bị khác. Nút hoạt động tốt trên hầu hết chúng. Nếu điều đó không đủ nhỏ, bạn có thể tạo một trình biên dịch Node tùy chỉnh, loại bỏ các tính năng, thậm chí hoán đổi công cụ V8 cho một công cụ JS khác nếu bạn cần. Bạn cũng có thể hạn chế sử dụng các thư viện JS nhỏ (trong đó có rất nhiều trên npm) để giữ cho cơ sở mã của bạn nhỏ gọn. 5. ". họ muốn tin vào sự cường điệu rằng vấn đề không phải ở họ, mà là do họ lựa chọn công nghệ trước đây. " Điều đó có thể giải thích cho một hoặc hai thử nghiệm, nhưng việc tiếp quản Node còn nhiều hơn thế. Chúng tôi đang nhanh chóng thay thế các ứng dụng bằng nhiều ngôn ngữ khác nhau bằng Node. Đã từng làm việc với số tiền 500 đô la trong quá trình chuyển đổi sang Node, tôi có thể cho bạn biết lý do của chúng tôi. Chúng tôi đã thử nghiệm chuyển sang Node, đã tìm thấy. 1. rằng ứng dụng nhanh hơn và đáng tin cậy hơn, mang lại những chiến thắng lớn về cả thời gian phản hồi trung bình và số lượng yêu cầu chúng tôi có thể phục vụ với cùng một máy và 2. Các nhà phát triển đã làm việc hiệu quả hơn vì nhiều lý do, bao gồm cả việc các chuyên gia JavaScript có thể làm việc dễ dàng hơn trên cả hai mặt của ngăn xếp mà không cần chuyển đổi ngữ cảnh và nhiều mã có thể được chia sẻ ở cả máy chủ và máy khách. Những lợi thế đó có ảnh hưởng thực sự, có thể đo lường được đến lợi nhuận của công ty. Đó là lý do tại sao Node đang chiếm lĩnh cả các công ty khởi nghiệp và doanh nghiệp

Eric Elliott

1. Tôi nghĩ bạn đã hiểu sai ý của tôi. JS chạy CHẬM 1-2 lần so với bản địa -- hiệu suất tốt hơn nhiều so với bất kỳ ngôn ngữ động nào khác mà tôi biết. Nó đủ nhanh để chạy các công cụ trò chơi AAA như Unreal Engine và Unity với chất lượng tuyệt đẹp ở hơn 60 khung hình / giây. 2. Tôi thực sự nghĩ rằng một công cụ kiểu gốc tốt sẽ là một bổ sung tốt cho JavaScript, nhưng chỉ khi chúng là các kiểu cấu trúc do người dùng định nghĩa. Điều đó nói rằng, JavaScript hỗ trợ phân tích tĩnh thông qua suy luận kiểu và có một số cách để cung cấp gợi ý kiểu cho các công cụ dành cho nhà phát triển. Ngoài ra, JavaScript còn có một loạt các công cụ phân tích thời gian chạy ấn tượng. 3. "hầu như không tốt hơn thừa kế thực sự, cho phép sắp xếp linh hoạt hơn nhiều. " Sai. https. //vừa phải. com/javascript-scene/hai-trụ-của-javascript-ee6f3281e7f3 4. Lời xin lỗi của tôi. Tôi đã không biết về vi mô. Mạng lưới. JavaScript cũng chạy nguyên trạng trên các thiết bị có công suất thấp bao gồm Arduino, Tessel và một số thiết bị khác. Nút hoạt động tốt trên hầu hết chúng. Nếu điều đó không đủ nhỏ, bạn có thể tạo một trình biên dịch Node tùy chỉnh, loại bỏ các tính năng, thậm chí hoán đổi công cụ V8 cho một công cụ JS khác nếu bạn cần. Bạn cũng có thể hạn chế sử dụng các thư viện JS nhỏ (trong đó có rất nhiều trên npm) để giữ cho cơ sở mã của bạn nhỏ gọn. 5. ". họ muốn tin vào sự cường điệu rằng vấn đề không phải ở họ, mà là do họ lựa chọn công nghệ trước đây. " Điều đó có thể giải thích cho một hoặc hai thử nghiệm, nhưng việc tiếp quản Node còn nhiều hơn thế. Chúng tôi đang nhanh chóng thay thế các ứng dụng bằng nhiều ngôn ngữ khác nhau bằng Node. Đã từng làm việc với số tiền 500 đô la trong quá trình chuyển đổi sang Node, tôi có thể cho bạn biết lý do của chúng tôi. Chúng tôi đã thử nghiệm chuyển sang Node, đã tìm thấy. 1. rằng ứng dụng nhanh hơn và đáng tin cậy hơn, mang lại những chiến thắng lớn về cả thời gian phản hồi trung bình và số lượng yêu cầu chúng tôi có thể phục vụ với cùng một máy và 2. Các nhà phát triển đã làm việc hiệu quả hơn vì nhiều lý do, bao gồm cả việc các chuyên gia JavaScript có thể làm việc dễ dàng hơn trên cả hai mặt của ngăn xếp mà không cần chuyển đổi ngữ cảnh và nhiều mã có thể được chia sẻ ở cả máy chủ và máy khách. Những lợi thế đó có ảnh hưởng thực sự, có thể đo lường được đến lợi nhuận của công ty. Đó là lý do tại sao Node đang chiếm lĩnh cả các công ty khởi nghiệp và doanh nghiệp

Kesava Velugubantla

đặc biệt là với cạnh nó thực sự tiện dụng

Kesava Velugubantla

đặc biệt là với cạnh nó thực sự tiện dụng

pawan kumar

Cảm ơn Tamisalv Tôi đang tìm tài liệu tham khảo đọc nhanh để hiểu về nút. js và tại sao các dự án có thể sử dụng nó. Đọc điều này giúp tôi hiểu rõ hơn về những ưu điểm của công nghệ này và cả khi người ta có thể sử dụng nó. Chúc mừng

pawan kumar

Cảm ơn Tamisalv Tôi đang tìm tài liệu tham khảo đọc nhanh để hiểu về nút. js và tại sao các dự án có thể sử dụng nó. Đọc điều này giúp tôi hiểu rõ hơn về những ưu điểm của công nghệ này và cả khi người ta có thể sử dụng nó. Chúc mừng

Jay

"Sau hơn 20 năm web không trạng thái dựa trên mô hình phản hồi yêu cầu không trạng thái, cuối cùng chúng tôi cũng có các ứng dụng web với kết nối hai chiều, thời gian thực. " Kết quả là ngày nay chúng tôi có các trang web mất nhiều thời gian tải hơn khi chúng tôi có tốc độ Internet theo thứ tự megabyte trên giây, so với trước đây khi tốc độ của chúng tôi theo thứ tự byte trên giây nhưng các trang web của chúng tôi đơn giản là HTML. Ngày nay, chúng ta có các trang web tải nửa chừng rồi dừng lại, các trang web này gặp sự cố do lỗi mạng nhỏ nhất. e. gán lại địa chỉ IP động hoặc mất tín hiệu WiFi tạm thời buộc bạn phải tải lại toàn bộ trang, trong khi các trình duyệt được thiết kế để xử lý các lỗi đó một cách khéo léo hoặc tiếp tục sau khi kết nối mạng được khôi phục, các tập lệnh Javascript có lỗi cũng không xử lý được các lỗi đó

Jay

"Sau hơn 20 năm web không trạng thái dựa trên mô hình phản hồi yêu cầu không trạng thái, cuối cùng chúng tôi cũng có các ứng dụng web với kết nối hai chiều, thời gian thực. " Kết quả là ngày nay chúng tôi có các trang web mất nhiều thời gian tải hơn khi chúng tôi có tốc độ Internet theo thứ tự megabyte trên giây, so với trước đây khi tốc độ của chúng tôi theo thứ tự byte trên giây nhưng các trang web của chúng tôi đơn giản là HTML. Ngày nay, chúng ta có các trang web tải nửa chừng rồi dừng lại, các trang web này gặp sự cố do lỗi mạng nhỏ nhất. e. gán lại địa chỉ IP động hoặc mất tín hiệu WiFi tạm thời buộc bạn phải tải lại toàn bộ trang, trong khi các trình duyệt được thiết kế để xử lý các lỗi đó một cách khéo léo hoặc tiếp tục sau khi kết nối mạng được khôi phục, các tập lệnh Javascript có lỗi cũng không xử lý được các lỗi đó

adroittech

Tôi chỉ có 1 câu hỏi ở đây với tuyên bố của bạn. "Hệ thống kiểu cấu trúc của nó tốt hơn hệ thống kiểu mà Java đã có khi tôi viết mã bằng Java, và nó tốt hơn nhiều (về độ tin cậy và linh hoạt hơn) so với C và C++. "Tôi không thể lấy cái đó. Làm sao? . C ++ được gõ mạnh có thể giải quyết mọi vấn đề, ngay cả khi xây dựng nút js. Nút tỏa sáng ở i/o không chặn và đó là về nó, nó không thể làm gì khác. Có, bạn có thể cắt mã nút và làm cho nó hoạt động trên các thiết bị siêu nhỏ nhưng liệu nó có hiệu quả và hợp lý không? . Nó không giống như I/O không chặn là một cái gì đó mới, chúng tôi đã có điều đó trong nhiều công nghệ bao gồm java,. Net, cơ bản, python và perl, cái này rất cũ. Lý do duy nhất khiến thứ này trở nên nổi tiếng là nó đã cho phép hàng triệu nhà phát triển javascript giao diện người dùng, những người không hiểu con trỏ và nói xấu về C ++, viết mã máy chủ, điều này đơn giản là quá sức, đó là lý do tại sao buzz. Và về "Nút nói riêng thực sự rất phù hợp để xử lý tính toán phân tán", tại sao người ta lại viết một tuyên bố như vậy? . nó không thể tính toán hiệu quả như C/C++/Java. Giai đoạn = Stage. Với tất cả sự tôn trọng, chúng ta đừng mang C++ vào đây, đơn giản là không có sự so sánh thực tế nào cả, nếu không nó sẽ rất nhạy cảm

adroittech

Tôi chỉ có 1 câu hỏi ở đây với tuyên bố của bạn. "Hệ thống kiểu cấu trúc của nó tốt hơn hệ thống kiểu mà Java đã có khi tôi viết mã bằng Java, và nó tốt hơn nhiều (về độ tin cậy và linh hoạt hơn) so với C và C++. "Tôi không thể lấy cái đó. Làm sao? . C ++ được gõ mạnh có thể giải quyết mọi vấn đề, ngay cả khi xây dựng nút js. Nút tỏa sáng ở i/o không chặn và đó là về nó, nó không thể làm gì khác. Có, bạn có thể cắt mã nút và làm cho nó hoạt động trên các thiết bị siêu nhỏ nhưng liệu nó có hiệu quả và hợp lý không? . Nó không giống như I/O không chặn là một cái gì đó mới, chúng tôi đã có điều đó trong nhiều công nghệ bao gồm java,. Net, cơ bản, python và perl, cái này rất cũ. Lý do duy nhất khiến thứ này trở nên nổi tiếng là nó đã cho phép hàng triệu nhà phát triển javascript giao diện người dùng, những người không hiểu con trỏ và nói xấu về C ++, viết mã máy chủ, điều này đơn giản là quá sức, đó là lý do tại sao buzz. Và về "Nút nói riêng thực sự rất phù hợp để xử lý tính toán phân tán", tại sao người ta lại viết một tuyên bố như vậy? . nó không thể tính toán hiệu quả như C/C++/Java. Giai đoạn = Stage. Với tất cả sự tôn trọng, chúng ta đừng mang C++ vào đây, đơn giản là không có sự so sánh thực tế nào cả, nếu không nó sẽ rất nhạy cảm

Eric Elliott

Bạn có thể quan tâm đến điều này. https. //vừa phải. com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6

Eric Elliott

Bạn có thể quan tâm đến điều này. https. //vừa phải. com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6

Ken Kopelson

Trên thực tế, Javascript trong công cụ máy chủ V8 CỰC nhanh. Tuyên bố rằng Javascript không nhanh đã lỗi thời. Bạn kết hợp Node với Chrome và bạn sẽ có một môi trường rất nhanh. Nếu bạn hiểu cách Node hoạt động, nó có một vòng lặp sự kiện xử lý tất cả mã sẵn sàng chạy. Vì vậy, bạn gọi một hàm có lệnh gọi cơ sở dữ liệu chặn bên trong và gọi lại khi kết thúc, nó cho phép gọi hàm, trả về ngay lập tức cho phép bạn tiếp tục với những thứ khác trong khi lệnh gọi cơ sở dữ liệu đang được xử lý. Vì vậy, bạn không "nhanh lên và chờ đợi" như bạn nghĩ. Bạn tiếp tục với những thứ khác và khi cuộc gọi cơ sở dữ liệu kết thúc, quá trình thực thi sẽ tiếp tục đến cuộc gọi lại được gọi sau khi cuộc gọi cơ sở dữ liệu trở lại. Vì vậy, bạn có được các khả năng cơ bản giống như môi trường đa luồng mà không phải trả thêm chi phí phát sinh do hoán đổi trạng thái luồng. Bởi vì bạn không bị "cắt thời gian", bạn phải cẩn thận để không có đoạn mã nào mất quá nhiều thời gian để chạy và nếu có, bạn chỉ cần chia nhỏ nó bằng cách sử dụng các gói như "async". Tôi đến từ nền tảng C, C++, Delphi, Java lâu năm, đã thành thạo mô hình đa luồng và tôi có thể khẳng định chắc chắn rằng mô hình không đồng bộ đơn luồng của Node cực kỳ tuyệt vời, nhanh chóng và có khả năng mở rộng cao. NẾU BẠN BIẾT MÌNH ĐANG LÀM GÌ. Nhưng điều đó cũng tương tự đối với bất kỳ công nghệ nào khác. Không có công nghệ nào trong số này dành cho tân sinh viên

Ken Kopelson

Trên thực tế, Javascript trong công cụ máy chủ V8 CỰC nhanh. Tuyên bố rằng Javascript không nhanh đã lỗi thời. Bạn kết hợp Node với Chrome và bạn sẽ có một môi trường rất nhanh. Nếu bạn hiểu cách Node hoạt động, nó có một vòng lặp sự kiện xử lý tất cả mã sẵn sàng chạy. Vì vậy, bạn gọi một hàm có lệnh gọi cơ sở dữ liệu chặn bên trong và gọi lại khi kết thúc, nó cho phép gọi hàm, trả về ngay lập tức cho phép bạn tiếp tục với những thứ khác trong khi lệnh gọi cơ sở dữ liệu đang được xử lý. Vì vậy, bạn không "nhanh lên và chờ đợi" như bạn nghĩ. Bạn tiếp tục với những thứ khác và khi cuộc gọi cơ sở dữ liệu kết thúc, quá trình thực thi sẽ tiếp tục đến cuộc gọi lại được gọi sau khi cuộc gọi cơ sở dữ liệu trở lại. Vì vậy, bạn có được các khả năng cơ bản giống như môi trường đa luồng mà không phải trả thêm chi phí phát sinh do hoán đổi trạng thái luồng. Bởi vì bạn không bị "cắt thời gian", bạn phải cẩn thận để không có đoạn mã nào mất quá nhiều thời gian để chạy và nếu có, bạn chỉ cần chia nhỏ nó bằng cách sử dụng các gói như "async". Tôi đến từ nền tảng C, C++, Delphi, Java lâu năm, đã thành thạo mô hình đa luồng và tôi có thể khẳng định chắc chắn rằng mô hình không đồng bộ đơn luồng của Node cực kỳ tuyệt vời, nhanh chóng và có khả năng mở rộng cao. NẾU BẠN BIẾT MÌNH ĐANG LÀM GÌ. Nhưng điều đó cũng tương tự đối với bất kỳ công nghệ nào khác. Không có công nghệ nào trong số này dành cho tân sinh viên

M

Một ứng dụng phức tạp chính xác là nơi các đối tượng Miền được điều chỉnh tốt và các hệ thống con được tách riêng phù hợp là cần thiết nhất. Nếu bạn đang dành toàn bộ thời gian để cố gắng làm cho ORM hoạt động, bạn nên tìm hiểu ORM đó tốt hơn hoặc kiếm một ORM khác. Tôi cho rằng cái trước không cần phải nói vì vậy nếu bạn vẫn đang chiến đấu với ORM của mình thì đã đến lúc chọn một cái vừa hoạt động

M

Một ứng dụng phức tạp chính xác là nơi các đối tượng Miền được điều chỉnh tốt và các hệ thống con được tách riêng phù hợp là cần thiết nhất. Nếu bạn đang dành toàn bộ thời gian để cố gắng làm cho ORM hoạt động, bạn nên tìm hiểu ORM đó tốt hơn hoặc kiếm một ORM khác. Tôi cho rằng cái trước không cần phải nói vì vậy nếu bạn vẫn đang chiến đấu với ORM của mình thì đã đến lúc chọn một cái vừa hoạt động

M

Ngoại trừ nhận xét cuối cùng của bạn rằng những công nghệ này không dành cho tân sinh viên, tôi nghĩ bạn đang bỏ qua hai đoạn cuối mà bạn đang phản hồi. Ngay cả người sáng lập nút. js nói để tránh các hoạt động chuyên sâu tính toán. Có, V8 tăng tốc javascript, nhưng điều đó không giải quyết được vấn đề về hoạt động tính toán chuyên sâu hoặc hoạt động phụ thuộc vào IO chặn một chuỗi. Sau đó, bạn trả lời nút đó. js không bị chặn và do đó có thể đợi. Tuyệt, tôi hiểu rồi, chắc chắn rồi, nhưng bạn còn chờ gì nữa? . js rõ ràng, (rất nhiều vì lợi ích được tuyên bố là "một ngôn ngữ thực sự để cai trị tất cả"), bởi vì nút luồng đơn của bạn. js vui vẻ chuyển sang một thứ khác cho đến khi gọi lại. Vì vậy, nút. js hoạt động tốt miễn là bạn có thể dựa vào các quy trình khác xử lý khối lượng công việc đang chặn (như chờ IO) hoặc một phiên bản khác của nút đơn luồng. js, điều đó chắc chắn sẽ (nếu được viết "chính xác") sẽ chuyển hướng sang một quy trình khác. Và đó là vấn đề. có một tập hợp con giới hạn nội dung được thực hiện trong các chương trình có thể được thực thi song song/không theo thứ tự và/hoặc không dựa vào các hoạt động chặn. Đa luồng phức tạp hơn và có một số chi phí hoạt động mỗi khi có chuyển đổi ngữ cảnh, nhưng điều đó có nghĩa là có thể ném nhiều lõi hơn vào các đơn vị công việc có thể song song hóa và thậm chí các hoạt động rời rạc có thể được xử lý bởi các luồng khác nhau. Trong một "nút. js giải quyết mọi thứ", bạn đang dựa vào thứ gì đó không được viết trong nút. js hoặc chờ nút đơn luồng của bạn. js để hoàn thành tất cả những thứ phải hoàn thành, bằng cách này hay cách khác

M

Ngoại trừ nhận xét cuối cùng của bạn rằng những công nghệ này không dành cho tân sinh viên, tôi nghĩ bạn đang bỏ qua hai đoạn cuối mà bạn đang phản hồi. Ngay cả người sáng lập nút. js nói để tránh các hoạt động chuyên sâu tính toán. Có, V8 tăng tốc javascript, nhưng điều đó không giải quyết được vấn đề về hoạt động tính toán chuyên sâu hoặc hoạt động phụ thuộc vào IO chặn một chuỗi. Sau đó, bạn trả lời nút đó. js không bị chặn và do đó có thể đợi. Tuyệt, tôi hiểu rồi, chắc chắn rồi, nhưng bạn còn chờ gì nữa? . js rõ ràng, (rất nhiều vì lợi ích được tuyên bố là "một ngôn ngữ thực sự để cai trị tất cả"), bởi vì nút luồng đơn của bạn. js vui vẻ chuyển sang một thứ khác cho đến khi gọi lại. Vì vậy, nút. js hoạt động tốt miễn là bạn có thể dựa vào các quy trình khác xử lý khối lượng công việc đang chặn (như chờ IO) hoặc một phiên bản khác của nút đơn luồng. js, điều đó chắc chắn sẽ (nếu được viết "chính xác") sẽ chuyển hướng sang một quy trình khác. Và đó là vấn đề. có một tập hợp con giới hạn nội dung được thực hiện trong các chương trình có thể được thực thi song song/không theo thứ tự và/hoặc không dựa vào các hoạt động chặn. Đa luồng phức tạp hơn và có một số chi phí hoạt động mỗi khi có chuyển đổi ngữ cảnh, nhưng điều đó có nghĩa là có thể ném nhiều lõi hơn vào các đơn vị công việc có thể song song hóa và thậm chí các hoạt động rời rạc có thể được xử lý bởi các luồng khác nhau. Trong một "nút. js giải quyết mọi thứ", bạn đang dựa vào thứ gì đó không được viết trong nút. js hoặc chờ nút đơn luồng của bạn. js để hoàn thành tất cả những thứ phải hoàn thành, bằng cách này hay cách khác

Ken Kopelson

Bạn biết gì? . Rõ ràng là bạn chưa bao giờ xây dựng bất cứ thứ gì nghiêm túc trong Node. js. Vâng, tôi có, và tôi có thể nói với bạn rằng nó hoạt động rất tốt nếu bạn thực sự lập trình nó một cách chính xác. Điều đó có nghĩa là bạn sử dụng những thứ như hàng đợi công việc, bạn sử dụng phân cụm mà Node cung cấp, bạn đảm bảo rằng bạn làm mọi thứ với lời gọi lại và lời hứa, bạn sử dụng "async" và "setImmediate" để chia sẻ bộ xử lý đúng cách giữa mã đang chờ và mã có thể . Ví dụ: tôi đã viết một thuật toán sắp xếp heap "không đồng bộ" hoạt động rất tốt, sắp xếp các danh sách lớn trong khi không chặn trong bất kỳ khoảng thời gian đáng kể nào. Tôi cũng có một thuật toán heuristic 5000 dòng khá phức tạp mà tôi đã chia ra để các vòng lặp chính được thực thi bằng cách sử dụng các cấu trúc không đồng bộ. Sau đó, tôi đã thực hiện các lệnh này từ hàng đợi công việc có tên là "Kue" cho phép sử dụng hiệu quả tất cả các lõi, không có luồng, thời gian phản hồi giao diện người dùng tuyệt vời và các công việc tính toán phức tạp được thực hiện trong nền bằng cách sử dụng tất cả sức mạnh bộ xử lý có sẵn. Điều này TẤT CẢ được thực hiện bằng javascript với hiệu suất tuyệt vời trong cả các tác vụ sử dụng nhiều CPU và phản hồi các yêu cầu dữ liệu từ giao diện người dùng. Nói cách khác, giao diện người dùng siêu nhạy và quá trình xử lý nền (tính toán heuristic phức tạp) được thực hiện nhanh chóng và rất nhạy. Tất cả điều này được thực hiện với một ngôn ngữ duy nhất cho cả phụ trợ và giao diện người dùng, đây là một vấn đề lớn khi nói đến kiến ​​trúc hệ thống

Ken Kopelson

Bạn biết gì? . Rõ ràng là bạn chưa bao giờ xây dựng bất cứ thứ gì nghiêm túc trong Node. js. Vâng, tôi có, và tôi có thể nói với bạn rằng nó hoạt động rất tốt nếu bạn thực sự lập trình nó một cách chính xác. Điều đó có nghĩa là bạn sử dụng những thứ như hàng đợi công việc, bạn sử dụng phân cụm mà Node cung cấp, bạn đảm bảo rằng bạn làm mọi thứ với lời gọi lại và lời hứa, bạn sử dụng "async" và "setImmediate" để chia sẻ bộ xử lý đúng cách giữa mã đang chờ và mã có thể . Ví dụ: tôi đã viết một thuật toán sắp xếp heap "không đồng bộ" hoạt động rất tốt, sắp xếp các danh sách lớn trong khi không chặn trong bất kỳ khoảng thời gian đáng kể nào. Tôi cũng có một thuật toán heuristic 5000 dòng khá phức tạp mà tôi đã chia ra để các vòng lặp chính được thực thi bằng cách sử dụng các cấu trúc không đồng bộ. Sau đó, tôi đã thực hiện các lệnh này từ hàng đợi công việc có tên là "Kue" cho phép sử dụng hiệu quả tất cả các lõi, không có luồng, thời gian phản hồi giao diện người dùng tuyệt vời và các công việc tính toán phức tạp được thực hiện trong nền bằng cách sử dụng tất cả sức mạnh bộ xử lý có sẵn. Điều này TẤT CẢ được thực hiện bằng javascript với hiệu suất tuyệt vời trong cả các tác vụ sử dụng nhiều CPU và phản hồi các yêu cầu dữ liệu từ giao diện người dùng. Nói cách khác, giao diện người dùng siêu nhạy và quá trình xử lý nền (tính toán heuristic phức tạp) được thực hiện nhanh chóng và rất nhạy. Tất cả điều này được thực hiện với một ngôn ngữ duy nhất cho cả phụ trợ và giao diện người dùng, đây là một vấn đề lớn khi nói đến kiến ​​trúc hệ thống

Jacob Ross

Tại sao chúng không dành cho "neophytes"?

Jacob Ross

Tại sao chúng không dành cho "neophytes"?

Jacob Ross

tôi đồng ý. Hầu hết những lần tôi nghĩ ORM không đủ cho các truy vấn phức tạp, tôi viết ra SQL thô, sau đó phát hiện ra ORM có một "ứng dụng cho điều đó". Tôi thích sử dụng ORM nhất có thể, nhưng tôi sẽ không dành quá nhiều thời gian để làm cho nó hoạt động với mình, nếu không, như M đã nói, tôi sẽ tìm một ORM khác

Jacob Ross

tôi đồng ý. Hầu hết những lần tôi nghĩ ORM không đủ cho các truy vấn phức tạp, tôi viết ra SQL thô, sau đó phát hiện ra ORM có một "ứng dụng cho điều đó". Tôi thích sử dụng ORM nhất có thể, nhưng tôi sẽ không dành quá nhiều thời gian để làm cho nó hoạt động với mình, nếu không, như M đã nói, tôi sẽ tìm một ORM khác

JF80

Nghe giống như những từ trong "Michael" mà tôi biết. ;) Tôi đồng ý với tuyên bố cuối cùng của bạn. "mỗi công nghệ có vị trí của nó". Nhưng tại sao bạn lại cho rằng tất cả các nhà phát triển Node đều là nhà phát triển front-end không có kiến ​​thức về back-end?

JF80

Nghe giống như những từ trong "Michael" mà tôi biết. ;) Tôi đồng ý với tuyên bố cuối cùng của bạn. "mỗi công nghệ có vị trí của nó". Nhưng tại sao bạn lại cho rằng tất cả các nhà phát triển Node đều là nhà phát triển front-end không có kiến ​​thức về back-end?

đấtT

Javascript là một lựa chọn ngôn ngữ kém để phát triển doanh nghiệp/phức hợp. Nó lộn xộn, khó đọc, khó tổ chức, không hỗ trợ toàn bộ các mô hình OO giúp tiết kiệm nhiều mã lặp lại và cung cấp sự trừu tượng có thể đọc được, chủ yếu gây ra lỗi thời gian chạy, không AOP, không theo quy ước, không phản ánh, . Chúng tôi bị mắc kẹt với nó trong trình duyệt và thành thật mà nói, đó chỉ là quán tính và hỗ trợ kế thừa có nghĩa là nó vẫn được sử dụng ở đó. Lẽ ra nó phải đi theo con đường của khủng long 10 năm trước. Động lực chính để tránh xa các ngôn ngữ kịch bản là chúng là cơn ác mộng bảo trì và dẫn đến các ứng dụng đầy bùn có lỗi liên tục không thể theo dõi được. Mới chỉ 10 năm ngắn ngủi kể từ khi chúng tôi thở phào nhẹ nhõm khi sự phát triển nghiêm túc không còn là ngôn ngữ kịch bản và ở đây chúng tôi đang làm lại điều đó mà không muốn học hỏi từ quá khứ, tin chắc rằng đây là "mới và tiên tiến", đúng hơn là . Nó sẽ kết thúc giống như lần trước, bị bàn tán với sự ghê tởm như asp cổ điển và perl cgi. Tôi chỉ có thể kết luận rằng các nhà phát triển ủng hộ nó bây giờ chỉ là không có mặt để chứng kiến ​​​​sự sụp đổ của lần cuối cùng này. Mọi thế hệ nhà phát triển mới đều tin chắc rằng họ đã khám phá ra "sự thật", những người trong chúng ta, những người đã chứng kiến ​​chu kỳ đau đớn này chỉ có thể ngồi lại và lắc đầu không thể tin được. Thật không may, bạn không thể dạy kinh nghiệm, đó là điều bạn phải học một cách khó khăn. Chắc chắn nếu bạn là một người nghiệp dư và không biết gì khác thì bằng mọi cách, nhưng bất kỳ ai đang cố gắng làm một công việc chuyên nghiệp cần phải để yên vấn đề này và ngừng đưa ra các lựa chọn công nghệ dân túy mà không xem xét kết quả. Nếu bạn không thể tự mình đánh giá những hạn chế lâu dài của một công nghệ thì bạn không nên làm việc trong lĩnh vực phát triển. Các nhà phát triển cần ngừng trẻ con như vậy, hành động như một lũ fan boy si mê, đây là một công việc nghiêm túc, không phải trò chơi

đấtT

Javascript là một lựa chọn ngôn ngữ kém để phát triển doanh nghiệp/phức hợp. Nó lộn xộn, khó đọc, khó tổ chức, không hỗ trợ toàn bộ các mô hình OO giúp tiết kiệm nhiều mã lặp lại và cung cấp sự trừu tượng có thể đọc được, chủ yếu gây ra lỗi thời gian chạy, không AOP, không theo quy ước, không phản ánh, . Chúng tôi bị mắc kẹt với nó trong trình duyệt và thành thật mà nói, đó chỉ là quán tính và hỗ trợ kế thừa có nghĩa là nó vẫn được sử dụng ở đó. Lẽ ra nó phải đi theo con đường của khủng long 10 năm trước. Động lực chính để tránh xa các ngôn ngữ kịch bản là chúng là cơn ác mộng bảo trì và dẫn đến các ứng dụng đầy bùn có lỗi liên tục không thể theo dõi được. Mới chỉ 10 năm ngắn ngủi kể từ khi chúng tôi thở phào nhẹ nhõm khi sự phát triển nghiêm túc không còn là ngôn ngữ kịch bản và ở đây chúng tôi đang làm lại điều đó mà không muốn học hỏi từ quá khứ, tin chắc rằng đây là "mới và tiên tiến", đúng hơn là . Nó sẽ kết thúc giống như lần trước, bị bàn tán với sự ghê tởm như asp cổ điển và perl cgi. Tôi chỉ có thể kết luận rằng các nhà phát triển ủng hộ nó bây giờ chỉ là không có mặt để chứng kiến ​​​​sự sụp đổ của lần cuối cùng này. Mọi thế hệ nhà phát triển mới đều tin chắc rằng họ đã khám phá ra "sự thật", những người trong chúng ta, những người đã chứng kiến ​​chu kỳ đau đớn này chỉ có thể ngồi lại và lắc đầu không thể tin được. Thật không may, bạn không thể dạy kinh nghiệm, đó là điều bạn phải học một cách khó khăn. Chắc chắn nếu bạn là một người nghiệp dư và không biết gì khác thì bằng mọi cách, nhưng bất kỳ ai đang cố gắng làm một công việc chuyên nghiệp cần phải để yên vấn đề này và ngừng đưa ra các lựa chọn công nghệ dân túy mà không xem xét kết quả. Nếu bạn không thể tự mình đánh giá những hạn chế lâu dài của một công nghệ thì bạn không nên làm việc trong lĩnh vực phát triển. Các nhà phát triển cần ngừng trẻ con như vậy, hành động như một lũ fan boy si mê, đây là một công việc nghiêm túc, không phải trò chơi

adroittech

Chúa ơi. Eric. Bạn có thật không? . NÓ Ở TRÊN PLAIN C/C++. http_parcer là thư viện C++. libuv là một thư viện C++ khác và quan trọng nhất trong xương sống của nodejs, làm cho nodejs không đồng bộ, hướng sự kiện và không chặn. Bản thân Javascript là một cơ thể không có linh hồn và sự sống. JAVASCRIPT chỉ là một kịch bản mà bạn sử dụng để viết kịch bản logic của mình. Một ngày nào đó nếu smeoene port lua với libs này, anh ấy sẽ không cần Javascript để viết mã. tương tự cho python, v.v. Nhưng thực tế cơ bản vẫn giữ nguyên. NÓ LÀ mã C++ tạo nên nodejs, không phải javascript quá nhanh. trên thực tế, javascript chậm nhất trong tất cả các ngôn ngữ kịch bản. Vì vậy, đừng tự tâng bốc bản thân khi tin rằng chỉ có java-script là tuyệt vời còn những thứ khác thì tệ hại. Và đừng xúc phạm C/C++ nếu bạn không có kiến ​​thức về nó. Vì vậy, một lần nữa, tôi mong bạn rút lại lời nói của mình. "Hệ thống kiểu Javascript tốt hơn C++". (Javascript không có hệ thống kiểu. và nếu bạn vẫn tin rằng nó có, thì bạn đang ở trong một lĩnh vực rất sai lầm, hãy xây dựng một số giàn giáo) Ngoài ra, các công ty này không chọn nodejs vì lý do bạn đã đề cập. Điều này có thể ở hầu hết các ngôn ngữ. Lý do tại sao các công ty chọn nodejs là vì họ có sẵn các lập trình viên javascript, hàng triệu và không thể làm mã c ++/java, để làm phía máy chủ vì nó rẻ hơn. Một lý do khác -> hệ sinh thái của nó. Một lý do khác -> Việc tiến hành kiểm tra tải trong nodejs dễ dàng hơn nhiều so với các tập lệnh khác. Liên kết bạn đã đề cập là công việc dự định sẽ được bắt đầu. Tại sao bạn không đề nghị họ viết trình biên dịch hợp ngữ web này trong nodejs chứ không phải c/C++/assembly vì theo bạn điều đó tốt hơn. Thôi nào anh bạn, làm sao bạn có thể so sánh Nodejs (Công nghệ) với C++ (ngôn ngữ), chúng không cùng đẳng cấp. C++ làm cho nút có thể, không phải ngược lại

adroittech

Chúa ơi. Eric. Bạn có thật không? . NÓ Ở TRÊN PLAIN C/C++. http_parcer là thư viện C++. libuv là một thư viện C++ khác và quan trọng nhất trong xương sống của nodejs, làm cho nodejs không đồng bộ, hướng sự kiện và không chặn. Bản thân Javascript là một cơ thể không có linh hồn và sự sống. JAVASCRIPT chỉ là một kịch bản mà bạn sử dụng để viết kịch bản logic của mình. Một ngày nào đó nếu smeoene port lua với libs này, anh ấy sẽ không cần Javascript để viết mã. tương tự cho python, v.v. Nhưng thực tế cơ bản vẫn giữ nguyên. NÓ LÀ mã C++ tạo nên nodejs, không phải javascript quá nhanh. trên thực tế, javascript chậm nhất trong tất cả các ngôn ngữ kịch bản. Vì vậy, đừng tự tâng bốc bản thân khi tin rằng chỉ có java-script là tuyệt vời còn những thứ khác thì tệ hại. Và đừng xúc phạm C/C++ nếu bạn không có kiến ​​thức về nó. Vì vậy, một lần nữa, tôi mong bạn rút lại lời nói của mình. "Hệ thống kiểu Javascript tốt hơn C++". (Javascript không có hệ thống kiểu. và nếu bạn vẫn tin rằng nó có, thì bạn đang ở trong một lĩnh vực rất sai lầm, hãy xây dựng một số giàn giáo) Ngoài ra, các công ty này không chọn nodejs vì lý do bạn đã đề cập. Điều này có thể ở hầu hết các ngôn ngữ. Lý do tại sao các công ty chọn nodejs là vì họ có sẵn các lập trình viên javascript, hàng triệu và không thể làm mã c ++/java, để làm phía máy chủ vì nó rẻ hơn. Một lý do khác -> hệ sinh thái của nó. Một lý do khác -> Việc tiến hành kiểm tra tải trong nodejs dễ dàng hơn nhiều so với các tập lệnh khác. Liên kết bạn đã đề cập là công việc dự định sẽ được bắt đầu. Tại sao bạn không đề nghị họ viết trình biên dịch hợp ngữ web này trong nodejs chứ không phải c/C++/assembly vì theo bạn điều đó tốt hơn. Thôi nào anh bạn, làm sao bạn có thể so sánh Nodejs (Công nghệ) với C++ (ngôn ngữ), chúng không cùng đẳng cấp. C++ làm cho nút có thể, không phải ngược lại

oberona

"Động lực chính để tránh xa các ngôn ngữ kịch bản là chúng là cơn ác mộng bảo trì và dẫn đến các ứng dụng đầy bùn" - bạn có thể làm rõ ý của mình bằng ngôn ngữ kịch bản không và "các nhà phát triển nghiêm túc" đã chuyển sang ngôn ngữ thay thế nào trong hơn mười năm qua . Ngược lại, Python là ngôn ngữ chính xác của tôi vì khả năng bảo trì của nó. Những lời chỉ trích của bạn về js là đúng, nhưng tôi không thể thấy cách chúng áp dụng trên toàn bộ vũ trụ ngôn ngữ kịch bản

oberona

"Động lực chính để tránh xa các ngôn ngữ kịch bản là chúng là cơn ác mộng bảo trì và dẫn đến các ứng dụng đầy bùn" - bạn có thể làm rõ ý của mình bằng ngôn ngữ kịch bản không và "các nhà phát triển nghiêm túc" đã chuyển sang ngôn ngữ thay thế nào trong hơn mười năm qua . Ngược lại, Python là ngôn ngữ chính xác của tôi vì khả năng bảo trì của nó. Những lời chỉ trích của bạn về js là đúng, nhưng tôi không thể thấy cách chúng áp dụng trên toàn bộ vũ trụ ngôn ngữ kịch bản

đấtT

Tôi định nghĩa ngôn ngữ kịch bản là ngôn ngữ biên dịch thời gian chạy, nhưng ngày nay có rất nhiều sự chồng chéo. Tôi thích sự đảm bảo về xác minh thời gian biên dịch ít nhất là độ chính xác của mã hóa nhưng đó không phải là yếu tố duy nhất. Mức độ xâm lấn sâu vào hoạt động bên trong của trình biên dịch mà ngày nay các ngôn ngữ được biên dịch có xu hướng phơi bày cho phép tạo ra một loạt các cấu trúc và mẫu thiết kế cho phép lập trình trở nên "thông minh" hơn, tôi chỉ không thấy mức độ này . Đó là một hạn chế nghiêm trọng cho sự phát triển doanh nghiệp nghiêm túc. ORM là một cách tiếp cận xấu để truy cập dữ liệu trên cơ sở dữ liệu quan hệ, nhưng bạn có thể phải là nhà phát triển cơ sở dữ liệu để nhận ra lý do tại sao. Thiết kế dữ liệu và thiết kế chương trình có các ràng buộc khác nhau, các ORM thực hiện một cách bất công hoặc phải sửa đổi quá nhiều đến mức chúng không mang lại năng suất. Có nhiều vấn đề chẳng hạn như bảo mật, cách ly, hoạt động nguyên tử mà ORM bị hỏng và hãy nhớ rằng cơ sở dữ liệu là một hệ thống sống và có thể yêu cầu thay đổi giữa các lần phát hành mã như một vấn đề tất nhiên. ORM là một công cụ cùn nếu bạn muốn hiệu suất thực sự từ cơ sở dữ liệu của mình và muốn tính đồng thời cao mà không bị khóa. Đó là một chủ đề chi tiết, tôi có thể viết một cuốn sách về nó, rất xin lỗi nếu điều này không đủ thuyết phục cho bạn. Không thể nói nhiều về Python ngoài việc tôi đã nghe những điều tốt nói chung. Tôi là đầu kia của thị trường trên. Net, tôi đóng đinh những người nguồn mở hàng xóm về năng suất và mức độ lỗi của tôi là khoảng 1% so với họ. Tôi nghĩ rằng bạn cần một hệ thống lớn trước khi nó tạo ra sự khác biệt đáng kể, vì bạn cần đầu tư vào khung và chất nền để nhận lại những lợi ích chính, "mã hóa hàng loạt" của nó là kẻ thù ở đây. Khi bạn có hơn 100.000 tệp mã, bạn cần mức độ bảo trì cao hơn vì đơn giản là vượt quá khả năng của con người để thực hiện từng tệp một (và chắc chắn là vượt quá ngân sách bảo trì). Bằng cách tạo các dịch vụ cốt lõi sử dụng mã dưới dạng nội dung, bạn có thể đạt được mức chất lượng cao trong khi vẫn giữ mọi thứ chi tiết và đảm bảo việc phát hành ở mức nhỏ và có mục tiêu thay vì giảm toàn bộ hệ thống. Mỗi cái đều có cái riêng của chúng, nhưng nếu bạn là một chuyên gia CNTT, bạn hẳn đã thấy hàng triệu hệ thống dựa trên tập lệnh đang hoạt động trong các doanh nghiệp vì không ai có thể tìm thấy bất cứ thứ gì hoặc hiểu cách thức hoạt động của nó. Đó là một lời phàn nàn phổ biến mà tôi nghĩ nó không cần phải biện minh

đấtT

Tôi định nghĩa ngôn ngữ kịch bản là ngôn ngữ biên dịch thời gian chạy, nhưng ngày nay có rất nhiều sự chồng chéo. Tôi thích sự đảm bảo về xác minh thời gian biên dịch ít nhất là độ chính xác của mã hóa nhưng đó không phải là yếu tố duy nhất. Mức độ xâm lấn sâu vào hoạt động bên trong của trình biên dịch mà ngày nay các ngôn ngữ được biên dịch có xu hướng phơi bày cho phép tạo ra một loạt các cấu trúc và mẫu thiết kế cho phép lập trình trở nên "thông minh" hơn, tôi chỉ không thấy mức độ này . Đó là một hạn chế nghiêm trọng cho sự phát triển doanh nghiệp nghiêm túc. ORM là một cách tiếp cận xấu để truy cập dữ liệu trên cơ sở dữ liệu quan hệ, nhưng bạn có thể phải là nhà phát triển cơ sở dữ liệu để nhận ra lý do tại sao. Thiết kế dữ liệu và thiết kế chương trình có các ràng buộc khác nhau, các ORM thực hiện một cách bất công hoặc phải sửa đổi quá nhiều đến mức chúng không mang lại năng suất. Có nhiều vấn đề chẳng hạn như bảo mật, cách ly, hoạt động nguyên tử mà ORM bị hỏng và hãy nhớ rằng cơ sở dữ liệu là một hệ thống sống và có thể yêu cầu thay đổi giữa các lần phát hành mã như một vấn đề tất nhiên. ORM là một công cụ cùn nếu bạn muốn hiệu suất thực sự từ cơ sở dữ liệu của mình và muốn tính đồng thời cao mà không bị khóa. Đó là một chủ đề chi tiết, tôi có thể viết một cuốn sách về nó, rất xin lỗi nếu điều này không đủ thuyết phục cho bạn. Không thể nói nhiều về Python ngoài việc tôi đã nghe những điều tốt nói chung. Tôi là đầu kia của thị trường trên. Net, tôi đóng đinh những người nguồn mở hàng xóm về năng suất và mức độ lỗi của tôi là khoảng 1% so với họ. Tôi nghĩ rằng bạn cần một hệ thống lớn trước khi nó tạo ra sự khác biệt đáng kể, vì bạn cần đầu tư vào khung và chất nền để nhận lại những lợi ích chính, "mã hóa hàng loạt" của nó là kẻ thù ở đây. Khi bạn có hơn 100.000 tệp mã, bạn cần mức độ bảo trì cao hơn vì đơn giản là vượt quá khả năng của con người để thực hiện từng tệp một (và chắc chắn là vượt quá ngân sách bảo trì). Bằng cách tạo các dịch vụ cốt lõi sử dụng mã dưới dạng nội dung, bạn có thể đạt được mức chất lượng cao trong khi vẫn giữ mọi thứ chi tiết và đảm bảo việc phát hành ở mức nhỏ và có mục tiêu thay vì giảm toàn bộ hệ thống. Mỗi cái đều có cái riêng của chúng, nhưng nếu bạn là một chuyên gia CNTT, bạn hẳn đã thấy hàng triệu hệ thống dựa trên tập lệnh đang hoạt động trong các doanh nghiệp vì không ai có thể tìm thấy bất cứ thứ gì hoặc hiểu cách thức hoạt động của nó. Đó là một lời phàn nàn phổ biến mà tôi nghĩ nó không cần phải biện minh

đấtT

P. S. Tôi nghĩ rằng "các nhà phát triển nghiêm túc" đã chuyển sang Java, C# hoặc quay lại C++ (cùng với các công nghệ web liên quan của họ, v.v.). Tôi thực sự không có ý định xúc phạm nhưng ba điều này có lẽ chiếm 90% tổng số atm phát triển thương mại. Đối với tôi, C# giành chiến thắng trên mặt trận thương mại chỉ dựa vào khoản đầu tư liên tục đáng kể của Microsoft và cách tiếp cận hiện đại mới được tìm thấy. C ++ không hiệu quả lắm và Java thực sự bắt đầu trông hơi lỗi thời. Tôi vẫn làm việc ở cả ba và họ hoàn thành công việc, mỗi người đều có vị trí của mình

đấtT

P. S. Tôi nghĩ rằng "các nhà phát triển nghiêm túc" đã chuyển sang Java, C# hoặc quay lại C++ (cùng với các công nghệ web liên quan của họ, v.v.). Tôi thực sự không có ý định xúc phạm nhưng ba điều này có lẽ chiếm 90% tổng số atm phát triển thương mại. Đối với tôi, C# giành chiến thắng trên mặt trận thương mại chỉ dựa vào khoản đầu tư liên tục đáng kể của Microsoft và cách tiếp cận hiện đại mới được tìm thấy. C ++ không hiệu quả lắm và Java thực sự bắt đầu trông hơi lỗi thời. Tôi vẫn làm việc ở cả ba và họ hoàn thành công việc, mỗi người đều có vị trí của mình

đấtT

P. P. S. "Python là ngôn ngữ chính xác của tôi vì khả năng bảo trì của nó". Bạn nghĩ gì về khả năng bảo trì? . Nó bao gồm chi phí thay đổi và đó là chi phí chính của doanh nghiệp cho một dự án sinh hoạt. Thí dụ. Tôi có một dịch vụ với 1000 phương thức công khai và doanh nghiệp yêu cầu tôi hủy ưu tiên tất cả các cuộc gọi kéo dài hơn 2 giây. Nếu tôi phải sửa đổi bất kỳ mã nào trong 1000 lệnh gọi đó thì mã của tôi có khả năng bảo trì kém nghiêm trọng. Những gì tôi nên làm là thay đổi một mã trong đường dẫn chất nền dịch vụ của mình. Tôi thậm chí không nên sửa đổi chất nền. Có lẽ tôi nên viết một mô-đun thống kê và một mô-đun hủy ưu tiên cho chất nền đó được tải trong một dll riêng biệt có thể được tải động. Bây giờ thử nghiệm của tôi chỉ được tách biệt với dll này (thử nghiệm khai thác ngược) và khi sẵn sàng phát hành, tôi có thể thêm dll này và có thể thực hiện một thay đổi cấu hình nhỏ, thế là xong, không có thử nghiệm hồi quy và không có rủi ro đối với mã hiện có, vì vậy không có lỗi sản xuất trong . Vì vậy, nhiều cơ sở mã điển hình sẽ yêu cầu thay đổi tất cả 1000 phương thức hoặc ít nhất là được đánh dấu cho hoạt động AOP. Thiết kế doanh nghiệp đòi hỏi phải dự đoán trước các yêu cầu kinh doanh "điên rồ" trong tương lai. Tôi thấy với hầu hết các ngôn ngữ kịch bản và thậm chí với Java, việc tìm kiếm các góc chèn sau này là gần như không thể. Ngay cả khi tôi có một con ngựa cái hoàn chỉnh trong C#, tôi có thể phát mã trực tiếp vào các phương thức bằng cách sử dụng sự phản chiếu, tôi chưa bao giờ thấy mức độ truy cập này trên ngôn ngữ kịch bản và ngay cả khi nó ở đó thì mã nguy hiểm sẽ được phát ra trong các hoạt động được biên dịch trong thời gian chạy . Đây chỉ là một ví dụ mà tôi có thể nghĩ ra khoảng 100. Tôi là một kiến ​​trúc sư kỹ thuật (khung và chất nền) vì vậy đây là nơi tôi "cứu" các nhà phát triển của mình khỏi việc dồn mình vào chân tường. Nếu tôi làm tốt, tôi có thể giảm công sức viết mã và thử nghiệm xuống 1% cho hệ thống "mã hóa hàng loạt". Có một cấp độ phát triển hoàn toàn khác mà hầu hết các nhà phát triển sẽ không bao giờ nhìn thấy hoặc đánh giá cao, điều này có nghĩa là họ không bao giờ được trang bị để đưa ra lựa chọn công nghệ phù hợp nhất

đấtT

P. P. S. "Python là ngôn ngữ chính xác của tôi vì khả năng bảo trì của nó". Bạn nghĩ gì về khả năng bảo trì? . Nó bao gồm chi phí thay đổi và đó là chi phí chính của doanh nghiệp cho một dự án sinh hoạt. Thí dụ. Tôi có một dịch vụ với 1000 phương thức công khai và doanh nghiệp yêu cầu tôi hủy ưu tiên tất cả các cuộc gọi kéo dài hơn 2 giây. Nếu tôi phải sửa đổi bất kỳ mã nào trong 1000 lệnh gọi đó thì mã của tôi có khả năng bảo trì kém nghiêm trọng. Những gì tôi nên làm là thay đổi một mã trong đường dẫn chất nền dịch vụ của mình. Tôi thậm chí không nên sửa đổi chất nền. Có lẽ tôi nên viết một mô-đun thống kê và một mô-đun hủy ưu tiên cho chất nền đó được tải trong một dll riêng biệt có thể được tải động. Bây giờ thử nghiệm của tôi chỉ được tách biệt với dll này (thử nghiệm khai thác ngược) và khi sẵn sàng phát hành, tôi có thể thêm dll này và có thể thực hiện một thay đổi cấu hình nhỏ, thế là xong, không có thử nghiệm hồi quy và không có rủi ro đối với mã hiện có, vì vậy không có lỗi sản xuất trong . Vì vậy, nhiều cơ sở mã điển hình sẽ yêu cầu thay đổi tất cả 1000 phương thức hoặc ít nhất là được đánh dấu cho hoạt động AOP. Thiết kế doanh nghiệp đòi hỏi phải dự đoán trước các yêu cầu kinh doanh "điên rồ" trong tương lai. Tôi thấy với hầu hết các ngôn ngữ kịch bản và thậm chí với Java, việc tìm kiếm các góc chèn sau này là gần như không thể. Ngay cả khi tôi có một con ngựa cái hoàn chỉnh trong C#, tôi có thể phát mã trực tiếp vào các phương thức bằng cách sử dụng sự phản chiếu, tôi chưa bao giờ thấy mức độ truy cập này trên ngôn ngữ kịch bản và ngay cả khi nó ở đó thì mã nguy hiểm sẽ được phát ra trong các hoạt động được biên dịch trong thời gian chạy . Đây chỉ là một ví dụ mà tôi có thể nghĩ ra khoảng 100. Tôi là một kiến ​​trúc sư kỹ thuật (khung và chất nền) vì vậy đây là nơi tôi "cứu" các nhà phát triển của mình khỏi việc dồn mình vào chân tường. Nếu tôi làm tốt, tôi có thể giảm công sức viết mã và thử nghiệm xuống 1% cho hệ thống "mã hóa hàng loạt". Có một cấp độ phát triển hoàn toàn khác mà hầu hết các nhà phát triển sẽ không bao giờ nhìn thấy hoặc đánh giá cao, điều này có nghĩa là họ không bao giờ được trang bị để đưa ra lựa chọn công nghệ phù hợp nhất

Josh Morgan

Bài viết thú vị, tôi đã có khá nhiều kinh nghiệm trong các lĩnh vực khác nhưng tôi hơi mới đối với Node. js. Có vài điều tôi muốn làm sáng tỏ. Flash cũng luôn không đồng bộ, nó chỉ mô phỏng các luồng giống như âm thanh giống như nút thực hiện bằng cách sử dụng hàng đợi sự kiện. Tuy nhiên, tôi tin rằng đó là sự thiếu hiểu biết về kỹ thuật khi tuyên bố rằng việc tin tưởng quản lý luồng vào ngôn ngữ thế hệ thứ 3 hoặc thứ 4 sẽ tốt hơn là tin tưởng vào JRE được điều chỉnh tốt hoặc hệ điều hành được tối ưu hóa cho chipset đa lõi của nó. Làm thế nào chính xác để bạn nghĩ rằng chủ đề làm việc ở cấp độ thấp hơn dù sao? . Cũng là một sai lầm khi nói rằng một "sự kiện" mới không thêm bộ nhớ hoặc chu kỳ đồng hồ được đưa vào ngăn xếp chỉ vì các sự kiện đã nói được quản lý bởi một ngôn ngữ kịch bản được diễn giải thay vì C++ được biên dịch, tối ưu hóa. Tôi dám cá với bữa trưa của mình rằng một ứng dụng web đa luồng được viết tốt bằng C hoặc C++ sẽ thổi bay bất kỳ nút nào. 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. Nếu bạn có máy chủ 4 nhân hoặc 8 nhân chạy một luồng nút đơn. bạn chỉ bắn vào một pít-tông (khá mỉa mai khi Google gọi động cơ của họ là "V8" khi xem xét thực tế như vậy). Một điều khác cần nhận ra là trong khi Flash (hoặc thậm chí cả Java applet) chạy trong thời gian chạy của riêng chúng, thì nút cũng vậy -- nó chỉ bị ẩn đối với người dùng. Đó chẳng qua là động thái kinh doanh "tốt" (có lẽ là thù địch?) từ phía Google. Hãy trung thực ở đây, nếu tất cả các trình duyệt đều được cài đặt tự động Flash trên chúng và Apple thực sự hỗ trợ Flash trên thiết bị di động của họ, thì nút có lẽ sẽ không tồn tại ngày nay. Tôi có những lo ngại khác về bảo mật. Nó có loại bảo vệ nào chống lại kịch bản chéo trang và các cuộc tấn công khác? . ). Không có cảnh báo nào về bảo mật hoặc loại kết nối mà cửa sổ trình duyệt của tôi đang mở ra, chỉ phù hợp với hoạt động kinh doanh P2P của nó. phe hacker của tôi có thể có một ngày thực sự hay với những loại "tính năng" đó. Tôi nghi ngờ những thứ đó đã được thử nghiệm nhiều, điều đó có nghĩa là có rất nhiều chỗ cho lỗi và ở đâu có nhiều chỗ cho lỗi thì cũng có rất nhiều chỗ cho lỗ hổng. Nhưng này, ít nhất toàn bộ ngăn xếp của bạn đều ở cùng một ngôn ngữ. Có nghĩa là bạn có thể thuê những nhà phát triển ít kinh nghiệm hơn với số tiền ít hơn, phải không?

Josh Morgan

Bài viết thú vị, tôi đã có khá nhiều kinh nghiệm trong các lĩnh vực khác nhưng tôi hơi mới đối với Node. js. Có vài điều tôi muốn làm sáng tỏ. Flash cũng luôn không đồng bộ, nó chỉ mô phỏng các luồng giống như âm thanh giống như nút thực hiện bằng cách sử dụng hàng đợi sự kiện. Tuy nhiên, tôi tin rằng đó là sự thiếu hiểu biết về kỹ thuật khi tuyên bố rằng việc tin tưởng quản lý luồng vào ngôn ngữ thế hệ thứ 3 hoặc thứ 4 sẽ tốt hơn là tin tưởng vào JRE được điều chỉnh tốt hoặc hệ điều hành được tối ưu hóa cho chipset đa lõi của nó. Làm thế nào chính xác để bạn nghĩ rằng chủ đề làm việc ở cấp độ thấp hơn dù sao? . Cũng là một sai lầm khi nói rằng một "sự kiện" mới không thêm bộ nhớ hoặc chu kỳ đồng hồ được đưa vào ngăn xếp chỉ vì các sự kiện đã nói được quản lý bởi một ngôn ngữ kịch bản được diễn giải thay vì C++ được biên dịch, tối ưu hóa. Tôi dám cá với bữa trưa của mình rằng một ứng dụng web đa luồng được viết tốt bằng C hoặc C++ sẽ thổi bay bất kỳ nút nào. 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. Nếu bạn có máy chủ 4 nhân hoặc 8 nhân chạy một luồng nút đơn. bạn chỉ bắn vào một pít-tông (khá mỉa mai khi Google gọi động cơ của họ là "V8" khi xem xét thực tế như vậy). Một điều khác cần nhận ra là trong khi Flash (hoặc thậm chí cả Java applet) chạy trong thời gian chạy của riêng chúng, thì nút cũng vậy -- nó chỉ bị ẩn đối với người dùng. Đó chẳng qua là động thái kinh doanh "tốt" (có lẽ là thù địch?) từ phía Google. Hãy trung thực ở đây, nếu tất cả các trình duyệt đều được cài đặt tự động Flash trên chúng và Apple thực sự hỗ trợ Flash trên thiết bị di động của họ, thì nút có lẽ sẽ không tồn tại ngày nay. Tôi có những lo ngại khác về bảo mật. Nó có loại bảo vệ nào chống lại kịch bản chéo trang và các cuộc tấn công khác? . ). Không có cảnh báo nào về bảo mật hoặc loại kết nối mà cửa sổ trình duyệt của tôi đang mở ra, chỉ phù hợp với hoạt động kinh doanh P2P của nó. phe hacker của tôi có thể có một ngày thực sự hay với những loại "tính năng" đó. Tôi nghi ngờ những thứ đó đã được thử nghiệm nhiều, điều đó có nghĩa là có rất nhiều chỗ cho lỗi và ở đâu có nhiều chỗ cho lỗi thì cũng có rất nhiều chỗ cho lỗ hổng. Nhưng này, ít nhất toàn bộ ngăn xếp của bạn đều ở cùng một ngôn ngữ. Có nghĩa là bạn có thể thuê những nhà phát triển ít kinh nghiệm hơn với số tiền ít hơn, phải không?

iwebworld

Bài viết hay về Node JS, bạn có thể học Node JS trực tuyến tại http. //iwebworld. thông tin hoặc gửi email iwebworldinfo@gmail. com

iwebworld

Bài viết hay về Node JS, bạn có thể học Node JS trực tuyến tại http. //iwebworld. thông tin hoặc gửi email iwebworldinfo@gmail. com

Avinash Shah

Bạn có thể loại bỏ tất cả các cạm bẫy của JS bằng cách sử dụng siêu bộ của nó hay còn gọi là TypeScript

Avinash Shah

Bạn có thể loại bỏ tất cả các cạm bẫy của JS bằng cách sử dụng siêu bộ của nó hay còn gọi là TypeScript

đi trốn

Tl;dr Sử dụng nút để xử lý nặng IO và ủy quyền xử lý chuyên sâu CPU cho một cụm nút công nhân chuyên dụng (cơ sở dữ liệu cũ, xử lý phương tiện, v.v.). Đây không hẳn là thông tin mới. Tôi đã đề cập lại chủ đề này vào năm '12. http. //lập trình viên. giao dịch cổ phiếu. com/a/179499/1256 Lý tưởng nhất là các máy chủ HTTP và API hầu như không trạng thái (không bao gồm quản lý phiên) và dùng một lần. Chúng chỉ là một đường dẫn chức năng chuyển dữ liệu thô thành các biểu diễn tiêu hao. Bằng cách đó, các máy chủ dễ dàng cung cấp/hủy một cách linh hoạt để đáp ứng tính chất đột biến của nhu cầu. Tôi không chắc tại sao rất nhiều người bình luận lại tranh cãi kịch liệt ủng hộ kiến ​​trúc máy chủ đa mục đích có thể mở rộng theo chiều dọc. Về bản chất, tỷ lệ dọc sẽ luôn có giới hạn trên được xác định bởi dung lượng phần cứng. Bất kể mã hiệu quả như thế nào. Viết lên tường. Bạn có thể chi một số tiền lớn cho phần cứng và mất ngủ khi đặt câu hỏi về tính hợp lệ của đánh giá rủi ro (hay còn gọi là WAG) của bạn. Vào cuối ngày, kim loại trần là một tài sản cố định. Trường hợp tốt nhất, nó đáp ứng nhu cầu dự kiến ​​và biện minh cho chi phí. Trường hợp xấu nhất, nó có giá cao hơn giá trị của nó hoặc thiếu khả năng đáp ứng nhu cầu. Ngoài ra, bạn có thể sử dụng điện toán phân tán và tự động hóa cơ sở hạ tầng để phát triển/thu hẹp tương ứng với nhu cầu. Đối với những người đang chiến đấu trong các cuộc chiến tôn giáo về ngôn ngữ nào là tốt nhất, nút. C#. java. Ai quan tâm. Cả 3 đều cho phép lập trình 'kiểu chức năng'. Cả 3, hỗ trợ xử lý không đồng bộ (nguyên bản hoặc thông qua tiện ích mở rộng). Tất cả 3 có thể được quản lý thông qua cung cấp. Cả 3 đều hoàn toàn hợp lệ để xây dựng cơ sở hạ tầng phân phối. Việc chọn sử dụng công cụ nào phụ thuộc vào chất lượng của các công cụ, liệu công cụ đó có được sử dụng để mở rộng cơ sở hạ tầng hiện có hay không và nhận thức của khách hàng. Xây dựng bất cứ thứ gì bạn giỏi xây dựng. Nếu bạn thực sự giỏi; . BTW, cảm ơn tác giả. Thật tuyệt khi thấy ai đó viết một bài viết toàn diện (và chủ yếu là khách quan) về chủ đề này

đi trốn

Tl;dr Sử dụng nút để xử lý nặng IO và ủy quyền xử lý chuyên sâu CPU cho một cụm nút công nhân chuyên dụng (cơ sở dữ liệu cũ, xử lý phương tiện, v.v.). Đây không hẳn là thông tin mới. Tôi đã đề cập lại chủ đề này vào năm '12. http. //lập trình viên. giao dịch cổ phiếu. com/a/179499/1256 Lý tưởng nhất là các máy chủ HTTP và API hầu như không trạng thái (không bao gồm quản lý phiên) và dùng một lần. Chúng chỉ là một đường dẫn chức năng chuyển dữ liệu thô thành các biểu diễn tiêu hao. Bằng cách đó, các máy chủ dễ dàng cung cấp/hủy một cách linh hoạt để đáp ứng tính chất đột biến của nhu cầu. Tôi không chắc tại sao rất nhiều người bình luận lại tranh cãi kịch liệt ủng hộ kiến ​​trúc máy chủ đa mục đích có thể mở rộng theo chiều dọc. Về bản chất, tỷ lệ dọc sẽ luôn có giới hạn trên được xác định bởi dung lượng phần cứng. Bất kể mã hiệu quả như thế nào. Viết lên tường. Bạn có thể chi một số tiền lớn cho phần cứng và mất ngủ khi đặt câu hỏi về tính hợp lệ của đánh giá rủi ro (hay còn gọi là WAG) của bạn. Vào cuối ngày, kim loại trần là một tài sản cố định. Trường hợp tốt nhất, nó đáp ứng nhu cầu dự kiến ​​và biện minh cho chi phí. Trường hợp xấu nhất, nó có giá cao hơn giá trị của nó hoặc thiếu khả năng đáp ứng nhu cầu. Ngoài ra, bạn có thể sử dụng điện toán phân tán và tự động hóa cơ sở hạ tầng để phát triển/thu hẹp tương ứng với nhu cầu. Đối với những người đang chiến đấu trong các cuộc chiến tôn giáo về ngôn ngữ nào là tốt nhất, nút. C#. java. Ai quan tâm. Cả 3 đều cho phép lập trình 'kiểu chức năng'. Cả 3, hỗ trợ xử lý không đồng bộ (nguyên bản hoặc thông qua tiện ích mở rộng). Tất cả 3 có thể được quản lý thông qua cung cấp. Cả 3 đều hoàn toàn hợp lệ để xây dựng cơ sở hạ tầng phân phối. Việc chọn sử dụng công cụ nào phụ thuộc vào chất lượng của các công cụ, liệu công cụ đó có được sử dụng để mở rộng cơ sở hạ tầng hiện có hay không và nhận thức của khách hàng. Xây dựng bất cứ thứ gì bạn giỏi xây dựng. Nếu bạn thực sự giỏi; . BTW, cảm ơn tác giả. Thật tuyệt khi thấy ai đó viết một bài viết toàn diện (và chủ yếu là khách quan) về chủ đề này

đi trốn

Có, cả hai ngôn ngữ đều hỗ trợ mở rộng theo chiều ngang với cơ sở hạ tầng quản lý tin nhắn không đồng bộ. CQRS không là gì ngoài một mẫu triển khai API. CRUD là trường hợp sử dụng điển hình (đúng như vậy) nhưng Node không tự động giàn giáo 1. 1 ánh xạ giữa DB và CRUD (xem Rails/laravel/Django để biết điều đó). Nút hoàn toàn không phải là một khung, nó chỉ là một máy chủ HTTP. Bạn có thể tận dụng các khung (ví dụ Express) để làm cho cuộc sống dễ dàng hơn bằng cách cung cấp các giá trị mặc định lành mạnh và cấu trúc tốt hơn nhưng bạn vẫn phải chỉ định các tuyến API của mình theo cách thủ công. . Tiện ích mở rộng phản ứng ròng đã được chuyển sang JS. https. //www. npmjs. com/package/rx Trên thực tế, ngay cả LINQ cũng đã được chuyển sang JS (vâng, nghiêm túc đấy). http. //linqjs. mật mã. com/ "Bất kỳ ứng dụng nào có thể được viết bằng Javascript, sẽ được viết bằng Javascript" - Định luật Atwood ORM chỉ là một vấn đề vì chúng yêu cầu thêm một lớp trừu tượng từ dữ liệu cơ bản. Nếu (đọc khi nào) các mô hình dữ liệu cần thay đổi để thích ứng với nhu cầu kinh doanh, cả ORM và lược đồ cơ sở dữ liệu sẽ cần được cập nhật và kiểm tra để phản ánh các thay đổi. Đó thực sự không phải là vấn đề lớn nếu có một chiến lược cập nhật tốt. Đối với phần còn lại của nhận xét của bạn, bạn sẽ làm tốt nếu thỉnh thoảng bước ra khỏi vùng an toàn của mình để xem cách phát triển JS thực sự hoạt động. 1. Các lớp JS hiện được hỗ trợ thông qua ES6 (đồng thời, phía máy khách có sẵn thông qua polyfill). Các nguyên mẫu thực sự không khác nhiều so với các lớp về mặt đóng gói (ngoại trừ chúng linh hoạt hơn rất nhiều). Kiểm tra kiểu tĩnh thời gian biên dịch thậm chí còn được hỗ trợ thông qua TypeScript/Dart nếu đó là thứ làm nổi thuyền của bạn, thì đó không phải là mặc định. 2. TDD/BDD không phải là một tính năng dành riêng cho các ngôn ngữ được gõ tĩnh. Có rất nhiều khung thử nghiệm tuyệt vời có sẵn trong JS (cả phía máy chủ/phía máy khách). Chọn sở thích của bạn, thử nghiệm đơn vị (Mocha), thử nghiệm đơn vị theo hành vi (Chai), thử nghiệm api (SuperTest) và thử nghiệm tích hợp liên tục (TravisCI và nhiều thử nghiệm khác) đều được sử dụng rộng rãi trong cộng đồng. JSUnit (JS tương đương với JUnit/NUnit) thậm chí có sẵn nếu bạn bỏ lỡ kiểm tra đơn vị trong Java/. MẠNG LƯỚI. Nếu bất cứ điều gì, thử nghiệm là một yêu cầu cơ bản của bất kỳ ứng dụng JS không tầm thường nào được đưa vào sản xuất vì bạn không có trình kiểm tra loại thời gian biên dịch để hỗ trợ bạn. 3. Quy trình làm việc phức tạp? . Thực thi kiểu, linting, tạo tài liệu, giàn giáo, triển khai bằng một cú nhấp chuột, dịch ngôn ngữ, gói, xây dựng phân phối, quản lý gói/phụ thuộc, quản lý phát hành, v.v. 4. . co rúm lại. nếu bạn chỉ dựa vào hệ thống kiểm tra kiểu tĩnh thời gian biên dịch để xác thực đầu vào của người dùng, thì bạn đang làm sai. Xây dựng một lớp dữ liệu bằng bất kỳ ngôn ngữ nào đều yêu cầu các ràng buộc ở trên và ngoài những gì mà các loại mặc định cung cấp. Vì vậy, dù bằng cách nào, bạn sẽ phải mở rộng các mô hình dữ liệu của mình bằng các kiểm tra xác thực tùy chỉnh. Phần thú vị về việc xử lý xác thực trong JS là bạn có thể sử dụng cùng một quy trình để kiểm tra đầu vào của người dùng trên cả phía máy khách/máy chủ. Ít trùng lặp nỗ lực hơn FTW. Trái ngược với những gì bạn nghĩ. Javascript thực sự là cách tiếp cận 'một kích thước phù hợp với tất cả' nếu bạn thích sử dụng nó như vậy. Nghiêm túc mà nói, bạn thậm chí có thể biên dịch C/C++ trực tiếp sang javascript bằng asm. js. Điều đó có nghĩa là bạn phải sử dụng nó? . Bất kỳ nhà phát triển nào có một chút ý thức sẽ không có lỗi với bạn khi chọn C #, đó là một ngôn ngữ tuyệt vời. Tôi có kinh nghiệm viết mã bằng nhiều ngôn ngữ, bao gồm xây dựng các ứng dụng máy tính để bàn không tầm thường bằng C#. Được lựa chọn, tôi muốn sử dụng Javascript hơn. Sự pha trộn của các ràng buộc lỏng lẻo hơn và các phong cách chức năng/mệnh lệnh/nguyên mẫu cho phép mức độ sáng tạo mà tôi chưa từng trải nghiệm trong bất kỳ ngôn ngữ nào khác. Các công cụ tuyệt vời, hệ thống mô-đun tuyệt vời và bản thân ngôn ngữ đang trở nên tốt hơn đáng kể với mỗi bản cập nhật

đi trốn

Có, cả hai ngôn ngữ đều hỗ trợ mở rộng theo chiều ngang với cơ sở hạ tầng quản lý tin nhắn không đồng bộ. CQRS không là gì ngoài một mẫu triển khai API. CRUD là trường hợp sử dụng điển hình (đúng như vậy) nhưng Node không tự động giàn giáo 1. 1 ánh xạ giữa DB và CRUD (xem Rails/laravel/Django để biết điều đó). Nút hoàn toàn không phải là một khung, nó chỉ là một máy chủ HTTP. Bạn có thể tận dụng các khung (ví dụ Express) để làm cho cuộc sống dễ dàng hơn bằng cách cung cấp các giá trị mặc định lành mạnh và cấu trúc tốt hơn nhưng bạn vẫn phải chỉ định các tuyến API của mình theo cách thủ công. . Tiện ích mở rộng phản ứng ròng đã được chuyển sang JS. https. //www. npmjs. com/package/rx Trên thực tế, ngay cả LINQ cũng đã được chuyển sang JS (vâng, nghiêm túc đấy). http. //linqjs. mật mã. com/ "Bất kỳ ứng dụng nào có thể được viết bằng Javascript, sẽ được viết bằng Javascript" - Định luật Atwood ORM chỉ là một vấn đề vì chúng yêu cầu thêm một lớp trừu tượng từ dữ liệu cơ bản. Nếu (đọc khi nào) các mô hình dữ liệu cần thay đổi để thích ứng với nhu cầu kinh doanh, cả ORM và lược đồ cơ sở dữ liệu sẽ cần được cập nhật và kiểm tra để phản ánh các thay đổi. Đó thực sự không phải là vấn đề lớn nếu có một chiến lược cập nhật tốt. Đối với phần còn lại của nhận xét của bạn, bạn sẽ làm tốt nếu thỉnh thoảng bước ra khỏi vùng an toàn của mình để xem cách phát triển JS thực sự hoạt động. 1. Các lớp JS hiện được hỗ trợ thông qua ES6 (đồng thời, phía máy khách có sẵn thông qua polyfill). Các nguyên mẫu thực sự không khác nhiều so với các lớp về mặt đóng gói (ngoại trừ chúng linh hoạt hơn rất nhiều). Kiểm tra kiểu tĩnh thời gian biên dịch thậm chí còn được hỗ trợ thông qua TypeScript/Dart nếu đó là thứ làm nổi thuyền của bạn, thì đó không phải là mặc định. 2. TDD/BDD không phải là một tính năng dành riêng cho các ngôn ngữ được gõ tĩnh. Có rất nhiều khung thử nghiệm tuyệt vời có sẵn trong JS (cả phía máy chủ/phía máy khách). Chọn sở thích của bạn, thử nghiệm đơn vị (Mocha), thử nghiệm đơn vị theo hành vi (Chai), thử nghiệm api (SuperTest) và thử nghiệm tích hợp liên tục (TravisCI và nhiều thử nghiệm khác) đều được sử dụng rộng rãi trong cộng đồng. JSUnit (JS tương đương với JUnit/NUnit) thậm chí có sẵn nếu bạn bỏ lỡ kiểm tra đơn vị trong Java/. MẠNG LƯỚI. Nếu bất cứ điều gì, thử nghiệm là một yêu cầu cơ bản của bất kỳ ứng dụng JS không tầm thường nào được đưa vào sản xuất vì bạn không có trình kiểm tra loại thời gian biên dịch để hỗ trợ bạn. 3. Quy trình làm việc phức tạp? . Thực thi kiểu, linting, tạo tài liệu, giàn giáo, triển khai bằng một cú nhấp chuột, dịch ngôn ngữ, gói, xây dựng phân phối, quản lý gói/phụ thuộc, quản lý phát hành, v.v. 4. . co rúm lại. nếu bạn chỉ dựa vào hệ thống kiểm tra kiểu tĩnh thời gian biên dịch để xác thực đầu vào của người dùng, thì bạn đang làm sai. Xây dựng một lớp dữ liệu bằng bất kỳ ngôn ngữ nào đều yêu cầu các ràng buộc ở trên và ngoài những gì mà các loại mặc định cung cấp. Vì vậy, dù bằng cách nào, bạn sẽ phải mở rộng các mô hình dữ liệu của mình bằng các kiểm tra xác thực tùy chỉnh. Phần thú vị về việc xử lý xác thực trong JS là bạn có thể sử dụng cùng một quy trình để kiểm tra đầu vào của người dùng trên cả phía máy khách/máy chủ. Ít trùng lặp nỗ lực hơn FTW. Trái ngược với những gì bạn nghĩ. Javascript thực sự là cách tiếp cận 'một kích thước phù hợp với tất cả' nếu bạn thích sử dụng nó như vậy. Nghiêm túc mà nói, bạn thậm chí có thể biên dịch C/C++ trực tiếp sang javascript bằng asm. js. Điều đó có nghĩa là bạn phải sử dụng nó? . Bất kỳ nhà phát triển nào có một chút ý thức sẽ không có lỗi với bạn khi chọn C #, đó là một ngôn ngữ tuyệt vời. Tôi có kinh nghiệm viết mã bằng nhiều ngôn ngữ, bao gồm xây dựng các ứng dụng máy tính để bàn không tầm thường bằng C#. Được lựa chọn, tôi muốn sử dụng Javascript hơn. Sự pha trộn của các ràng buộc lỏng lẻo hơn và các phong cách chức năng/mệnh lệnh/nguyên mẫu cho phép mức độ sáng tạo mà tôi chưa từng trải nghiệm trong bất kỳ ngôn ngữ nào khác. Các công cụ tuyệt vời, hệ thống mô-đun tuyệt vời và bản thân ngôn ngữ đang trở nên tốt hơn đáng kể với mỗi bản cập nhật

đi trốn

Tải tệp lên. http. //howtonode. org/really-simple-file-uploads "Tất cả các hoạt động I/O được xử lý bởi Node. js đang sử dụng nhiều luồng nội bộ; . " http. // stackoverflow. com/a/22981768/290340 Libuv sử dụng nhóm luồng để xử lý các hoạt động I/O (tệp, ổ cắm, v.v.) theo cách không đồng bộ. Trong đó hầu hết các ngôn ngữ bị chặn theo mặc định trong các hoạt động I/O nặng của CPU, thì Node không. Nó chỉ kích hoạt một sự kiện khi thao tác I/O hoàn thành trên worker thread. Thư mục hoạt động. https. //github. com/gheeres/node-activedirectory https. //github. com/auth0/hộ chiếu-windowsauth

đi trốn

Tải tệp lên. http. //howtonode. org/really-simple-file-uploads "Tất cả các hoạt động I/O được xử lý bởi Node. js đang sử dụng nhiều luồng nội bộ; . " http. // stackoverflow. com/a/22981768/290340 Libuv sử dụng nhóm luồng để xử lý các hoạt động I/O (tệp, ổ cắm, v.v.) theo cách không đồng bộ. Trong đó hầu hết các ngôn ngữ bị chặn theo mặc định trong các hoạt động I/O nặng của CPU, thì Node không. Nó chỉ kích hoạt một sự kiện khi thao tác I/O hoàn thành trên worker thread. Thư mục hoạt động. https. //github. com/gheeres/node-activedirectory https. //github. com/auth0/hộ chiếu-windowsauth

đi trốn

Điểm khác biệt là Node mặc định là không đồng bộ Vì vậy, số lượng nhà phát triển thực hiện lập trình không đồng bộ bằng các ngôn ngữ khác là thiểu số nên họ không được đại diện nhiều. "Tôi không thể đưa ra bất kỳ lý do chính đáng nào để sử dụng nó ở phía máy chủ có lợi cho các ngôn ngữ có sẵn khác. " Không nói dối đâu, lúc đầu sử dụng Node là. Thách thức để nói ít nhất. Làm quen với async-by-default không phải là một quá trình chuyển đổi dễ dàng. Phần hay của Node là, trọng tâm chính của nền tảng là xây dựng máy chủ/máy khách để hệ sinh thái có rất nhiều công cụ mạnh mẽ để làm bất cứ điều gì liên quan đến phát triển web. ". có thư viện, công cụ và tài nguyên tiêu chuẩn tốt hơn. "Tôi không chắc điều gì đã cho bạn ấn tượng đó. Nó không sử dụng cách tiếp cận thư viện lớp cơ sở nguyên khối-mọi thứ và nhà bếp. Bản thân lõi rất nhỏ nhưng đó là một lợi ích vì nó nhẹ hơn nhiều khi triển khai. Nó cũng bao gồm một trình quản lý gói rất mạnh mẽ, đầy đủ tính năng theo mặc định, do đó bạn sẽ phải thêm các phụ thuộc mà dự án của bạn cần. NPM (Trình quản lý gói nút) có hơn 200 nghìn gói và đang tiếp tục tăng. Vì phần lớn các mô-đun được phát triển độc lập với lõi, chúng lặp lại và cải thiện nhanh hơn nhiều so với các thư viện lõi tương đương trong các ngôn ngữ khác. Các phụ thuộc được quản lý cục bộ trên cơ sở từng dự án trong gói. tập tin json. Thông thường, việc tác giả mô-đun yêu cầu gói của họ phải được cài đặt trên toàn cầu là một hình thức tồi. Việc cài đặt các gói cục bộ sẽ ngăn xung đột phiên bản ở cấp độ toàn cầu và đảm bảo rằng -- khi bạn cài đặt một gói -- mọi thứ cần thiết để sử dụng mô-đun đều được bao gồm. Thoạt nhìn, nó có vẻ không hiệu quả vì nhiều phụ thuộc có thể có các bản sao của cùng một phụ thuộc phụ (hoặc phụ thuộc, v.v.) nhưng so với chi phí bao gồm một thư viện tiêu chuẩn đồ sộ, không gian lưu trữ là không đáng kể. Quy trình làm việc để thiết lập một dự án là. - sao chép nguồn - chạy 'npm install' NPM sẽ tự động tải xuống và cài đặt tất cả các phụ thuộc (bao gồm sub-deps, sub-sub-deps, v.v.). Vì các phụ thuộc (và các phiên bản cụ thể của chúng) được xác định rõ ràng trong cấu hình, nên bạn không cần kiểm tra chúng trong kiểm soát nguồn. Ngoài ra, với ES6 (bao gồm trình tải mô-đun ES6 mới) sắp được phát hành, một JSPM mới (Trình quản lý gói JavaScript) đã được tạo để quản lý các phụ thuộc javascript phía máy khách. Nhập mô-đun trong trình duyệt cuối cùng đã được chính thức hóa trong thông số ngôn ngữ, vì vậy Bower và nhiều tiêu chuẩn giả tải mô-đun (ví dụ: AMD, CommonJS, UMD) sẽ biến mất

đi trốn

Điểm khác biệt là Node mặc định là không đồng bộ Vì vậy, số lượng nhà phát triển thực hiện lập trình không đồng bộ bằng các ngôn ngữ khác là thiểu số nên họ không được đại diện nhiều. "Tôi không thể đưa ra bất kỳ lý do chính đáng nào để sử dụng nó ở phía máy chủ có lợi cho các ngôn ngữ có sẵn khác. " Không nói dối đâu, lúc đầu sử dụng Node là. Thách thức để nói ít nhất. Làm quen với async-by-default không phải là một quá trình chuyển đổi dễ dàng. Phần hay của Node là, trọng tâm chính của nền tảng là xây dựng máy chủ/máy khách để hệ sinh thái có rất nhiều công cụ mạnh mẽ để làm bất cứ điều gì liên quan đến phát triển web. ". có thư viện, công cụ và tài nguyên tiêu chuẩn tốt hơn. "Tôi không chắc điều gì đã cho bạn ấn tượng đó. Nó không sử dụng cách tiếp cận thư viện lớp cơ sở nguyên khối-mọi thứ và nhà bếp. Bản thân lõi rất nhỏ nhưng đó là một lợi ích vì nó nhẹ hơn nhiều khi triển khai. Nó cũng bao gồm một trình quản lý gói rất mạnh mẽ, đầy đủ tính năng theo mặc định, do đó bạn sẽ phải thêm các phụ thuộc mà dự án của bạn cần. NPM (Trình quản lý gói nút) có hơn 200 nghìn gói và đang tiếp tục tăng. Vì phần lớn các mô-đun được phát triển độc lập với lõi, chúng lặp lại và cải thiện nhanh hơn nhiều so với các thư viện lõi tương đương trong các ngôn ngữ khác. Các phụ thuộc được quản lý cục bộ trên cơ sở từng dự án trong gói. tập tin json. Thông thường, việc tác giả mô-đun yêu cầu gói của họ phải được cài đặt trên toàn cầu là một hình thức tồi. Việc cài đặt các gói cục bộ sẽ ngăn xung đột phiên bản ở cấp độ toàn cầu và đảm bảo rằng -- khi bạn cài đặt một gói -- mọi thứ cần thiết để sử dụng mô-đun đều được bao gồm. Thoạt nhìn, nó có vẻ không hiệu quả vì nhiều phụ thuộc có thể có các bản sao của cùng một phụ thuộc phụ (hoặc phụ thuộc, v.v.) nhưng so với chi phí bao gồm một thư viện tiêu chuẩn đồ sộ, không gian lưu trữ là không đáng kể. Quy trình làm việc để thiết lập một dự án là. - sao chép nguồn - chạy 'npm install' NPM sẽ tự động tải xuống và cài đặt tất cả các phụ thuộc (bao gồm sub-deps, sub-sub-deps, v.v.). Vì các phụ thuộc (và các phiên bản cụ thể của chúng) được xác định rõ ràng trong cấu hình, nên bạn không cần kiểm tra chúng trong kiểm soát nguồn. Ngoài ra, với ES6 (bao gồm trình tải mô-đun ES6 mới) sắp được phát hành, một JSPM mới (Trình quản lý gói JavaScript) đã được tạo để quản lý các phụ thuộc javascript phía máy khách. Nhập mô-đun trong trình duyệt cuối cùng đã được chính thức hóa trong thông số ngôn ngữ, vì vậy Bower và nhiều tiêu chuẩn giả tải mô-đun (ví dụ: AMD, CommonJS, UMD) sẽ biến mất

đấtT

Như đã nói ở trên, các ngôn ngữ OO hiện đại có rất nhiều tùy chọn để chính thức hóa và kiểm soát mã của bạn cũng như các giải pháp mà các ngôn ngữ kịch bản không có. Đó chỉ là sự thật đơn giản, không có sự kìm kẹp nào có thể thay đổi được điều đó. Quan điểm của tôi là có rất nhiều nhà phát triển chọn công nghệ theo mức độ phổ biến hơn là sự phù hợp, đó là điều khiến họ hâm mộ các chàng trai. 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. Nhưng đó có lẽ là do hầu hết các nhà phát triển không phải là "Người thợ" thực thụ, mà là "Người tự làm" được tôn vinh hơn. Ngành công nghiệp đầy những người nghiệp dư, những người thậm chí không biết đủ để biết rằng họ không biết gì. Họ nghĩ bởi vì họ có thể viết câu lệnh if và vòng lặp while nên họ giỏi. công nghệ

đấtT

Như đã nói ở trên, các ngôn ngữ OO hiện đại có rất nhiều tùy chọn để chính thức hóa và kiểm soát mã của bạn cũng như các giải pháp mà các ngôn ngữ kịch bản không có. Đó chỉ là sự thật đơn giản, không có sự kìm kẹp nào có thể thay đổi được điều đó. Quan điểm của tôi là có rất nhiều nhà phát triển chọn công nghệ theo mức độ phổ biến hơn là sự phù hợp, đó là điều khiến họ hâm mộ các chàng trai. 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. Nhưng đó có lẽ là do hầu hết các nhà phát triển không phải là "Người thợ" thực thụ, mà là "Người tự làm" được tôn vinh hơn. Ngành công nghiệp đầy những người nghiệp dư, những người thậm chí không biết đủ để biết rằng họ không biết gì. Họ nghĩ bởi vì họ có thể viết câu lệnh if và vòng lặp while nên họ giỏi. công nghệ

đi trốn

Các hoạt động I/O cấp hệ thống (chẳng hạn như tệp, ổ cắm) trong Nút được xử lý bởi libuv sử dụng nhóm luồng nền. Sự khác biệt là, luồng chính có thể kích hoạt và quên nhiệm vụ đối với luồng nền và luồng nền sẽ thông báo cho luồng chính (thông qua kích hoạt một sự kiện) khi thao tác hoàn tất. Ngay cả khi xử lý luồng nền, thực hiện nhiều thao tác I/O cũng không mở rộng tốt. Đối với các tác vụ sử dụng nhiều CPU trong thời gian dài (mã hóa hình ảnh/phim cũ), việc giảm tải các tác vụ cho các nút worker vẫn được ưu tiên hơn. Trong hầu hết các ngôn ngữ, các thao tác I/O được xử lý theo cách đồng bộ, vì vậy nếu chúng yêu cầu được thực hiện trên luồng chính, chúng sẽ chặn thực thi cho đến khi hoàn thành. Lý do bạn không thấy một khoảng dừng đáng chú ý trong giao diện người dùng khi điều này xảy ra là do giao diện người dùng không đồng bộ/dựa trên sự kiện và chạy trên một chuỗi tách biệt với ngữ cảnh chính

đi trốn

Các hoạt động I/O cấp hệ thống (chẳng hạn như tệp, ổ cắm) trong Nút được xử lý bởi libuv sử dụng nhóm luồng nền. Sự khác biệt là, luồng chính có thể kích hoạt và quên nhiệm vụ đối với luồng nền và luồng nền sẽ thông báo cho luồng chính (thông qua kích hoạt một sự kiện) khi thao tác hoàn tất. Ngay cả khi xử lý luồng nền, thực hiện nhiều thao tác I/O cũng không mở rộng tốt. Đối với các tác vụ sử dụng nhiều CPU trong thời gian dài (mã hóa hình ảnh/phim cũ), việc giảm tải các tác vụ cho các nút worker vẫn được ưu tiên hơn. Trong hầu hết các ngôn ngữ, các thao tác I/O được xử lý theo cách đồng bộ, vì vậy nếu chúng yêu cầu được thực hiện trên luồng chính, chúng sẽ chặn thực thi cho đến khi hoàn thành. Lý do bạn không thấy một khoảng dừng đáng chú ý trong giao diện người dùng khi điều này xảy ra là do giao diện người dùng không đồng bộ/dựa trên sự kiện và chạy trên một chuỗi tách biệt với ngữ cảnh chính

đi trốn

Không có gì ngăn cản bạn hiển thị API dưới dạng microservice. WebKit chỉ cho phép bạn chạy ứng dụng khách JS gốc. Tôi có thể sai nhưng theo những gì tôi hiểu, không giống như trình duyệt, ứng dụng khách webkit không được hộp cát nghiêm ngặt để bạn có thể thực hiện các cuộc gọi hệ thống (ví dụ: mở/lưu tệp mà không cần người dùng nhập)

đi trốn

Không có gì ngăn cản bạn hiển thị API dưới dạng microservice. WebKit chỉ cho phép bạn chạy ứng dụng khách JS gốc. Tôi có thể sai nhưng theo những gì tôi hiểu, không giống như trình duyệt, ứng dụng khách webkit không được hộp cát nghiêm ngặt để bạn có thể thực hiện các cuộc gọi hệ thống (ví dụ: mở/lưu tệp mà không cần người dùng nhập)

đấtT

Tôi nghĩ rằng bạn đã đưa ra quan điểm của mình cho tôi, nói ra những điều vô nghĩa thiếu suy nghĩ, vô nghĩa về cảm xúc, với rất ít sự thật, từ một tâm trí quá cuồng tín về một thứ mà nó thậm chí không thể nhìn thấy những thất bại của nó. Có vẻ như bạn đã đưa ra một vài giả định hợp lý về những gì tôi làm và không biết, tôi đã làm Javascript được 20 năm, tôi biết những hạn chế của nó, tôi có thể làm việc hiệu quả với hơn 30 ngôn ngữ, tôi sử dụng những gì phù hợp, . Bạn cần trưởng thành hoặc tìm một ngành mới để làm việc. Những người như bạn là vấn đề với Phát triển phần mềm, không biết gì về những người thậm chí không thể tạo ra một trường hợp cho một công nghệ, chứ đừng nói đến việc sử dụng một công nghệ. Vui lòng tránh xa bàn phím và giúp đỡ phần còn lại của chúng tôi

đấtT

Tôi nghĩ rằng bạn đã đưa ra quan điểm của mình cho tôi, nói ra những điều vô nghĩa thiếu suy nghĩ, vô nghĩa về cảm xúc, với rất ít sự thật, từ một tâm trí quá cuồng tín về một thứ mà nó thậm chí không thể nhìn thấy những thất bại của nó. Có vẻ như bạn đã đưa ra một vài giả định hợp lý về những gì tôi làm và không biết, tôi đã làm Javascript được 20 năm, tôi biết những hạn chế của nó, tôi có thể làm việc hiệu quả với hơn 30 ngôn ngữ, tôi sử dụng những gì phù hợp, . Bạn cần trưởng thành hoặc tìm một ngành mới để làm việc. Những người như bạn là vấn đề với Phát triển phần mềm, không biết gì về những người thậm chí không thể tạo ra một trường hợp cho một công nghệ, chứ đừng nói đến việc sử dụng một công nghệ. Vui lòng tránh xa bàn phím và giúp đỡ phần còn lại của chúng tôi

đi trốn

Bạn có sử dụng kiểm soát phiên bản với quy trình làm việc tiêu chuẩn (quy trình làm việc Gitflow cũ) nơi các nhà phát triển thực hiện thay đổi trên các nhánh tính năng và mã được đánh giá ngang hàng trước khi được hợp nhất không? . Tất cả các ví dụ có sẵn trực tuyến đều bị hỏng khá nhiều nên tôi đã theo dõi quá trình phát triển dự án trên Github. Tỷ lệ mà các nhà phát triển cốt lõi đang đạt được trên cơ sở mã thực sự đáng chú ý. Điều tuyệt vời hơn nữa là mọi PR đều được kiểm tra đơn vị và kiểm tra tích hợp liên tục đủ tốt để mọi bản phát hành được đảm bảo hoạt động đầy đủ (theo như họ đã triển khai cho đến nay)

đi trốn

Bạn có sử dụng kiểm soát phiên bản với quy trình làm việc tiêu chuẩn (quy trình làm việc Gitflow cũ) nơi các nhà phát triển thực hiện thay đổi trên các nhánh tính năng và mã được đánh giá ngang hàng trước khi được hợp nhất không? . Tất cả các ví dụ có sẵn trực tuyến đều bị hỏng khá nhiều nên tôi đã theo dõi quá trình phát triển dự án trên Github. Tỷ lệ mà các nhà phát triển cốt lõi đang đạt được trên cơ sở mã thực sự đáng chú ý. Điều tuyệt vời hơn nữa là mọi PR đều được kiểm tra đơn vị và kiểm tra tích hợp liên tục đủ tốt để mọi bản phát hành được đảm bảo hoạt động đầy đủ (theo như họ đã triển khai cho đến nay)

đi trốn

Làm theo những gì Tracker1 đang nói. Linting tương đương với việc kiểm tra thời gian biên dịch trong JS. Tôi thậm chí còn sử dụng tiện ích mở rộng Sublime hiển thị lỗi kẻ nói dối trực tiếp trong trình soạn thảo khi tôi đang viết mã. Nếu bạn muốn kiểm tra chặt chẽ hơn, bạn có thể thêm trình kiểm tra kiểu, chẳng hạn như 'bán tiêu chuẩn', đảm bảo kiểu mã trên cơ sở toàn dự án. Điều đó có nghĩa là dấu cách không phải tab, thụt lề 2 dấu cách, hàm nhất quán, dấu ngoặc nhọn, v.v. Kiểm tra kiểu tốt cho các lỗi bề ngoài (biến chưa khởi tạo cũ, nhánh chết, giá trị không hợp lệ) nhưng cuối cùng bạn sẽ phải xác minh mã không có lỗi logic thông qua kiểm tra đơn vị, kiểm tra tích hợp liên tục, kiểm tra api

đi trốn

Làm theo những gì Tracker1 đang nói. Linting tương đương với việc kiểm tra thời gian biên dịch trong JS. Tôi thậm chí còn sử dụng tiện ích mở rộng Sublime hiển thị lỗi kẻ nói dối trực tiếp trong trình soạn thảo khi tôi đang viết mã. Nếu bạn muốn kiểm tra chặt chẽ hơn, bạn có thể thêm trình kiểm tra kiểu, chẳng hạn như 'bán tiêu chuẩn', đảm bảo kiểu mã trên cơ sở toàn dự án. Điều đó có nghĩa là dấu cách không phải tab, thụt lề 2 dấu cách, hàm nhất quán, dấu ngoặc nhọn, v.v. Kiểm tra kiểu tốt cho các lỗi bề ngoài (biến chưa khởi tạo cũ, nhánh chết, giá trị không hợp lệ) nhưng cuối cùng bạn sẽ phải xác minh mã không có lỗi logic thông qua kiểm tra đơn vị, kiểm tra tích hợp liên tục, kiểm tra api

đi trốn

Nút sử dụng I/O dựa trên sự kiện không đồng bộ thông qua libuv (bao gồm một nhóm luồng dành riêng cho các yêu cầu I/O). Luồng chính hoàn toàn không bị chặn trong quá trình hoạt động I/O. Nó hoạt động giống như cách cụm ngoại trừ nó được tích hợp vào Node. Kiểm tra một trong những bài thuyết trình trên libuv để biết thêm chi tiết

đi trốn

Nút sử dụng I/O dựa trên sự kiện không đồng bộ thông qua libuv (bao gồm một nhóm luồng dành riêng cho các yêu cầu I/O). Luồng chính hoàn toàn không bị chặn trong quá trình hoạt động I/O. Nó hoạt động giống như cách cụm ngoại trừ nó được tích hợp vào Node. Kiểm tra một trong những bài thuyết trình trên libuv để biết thêm chi tiết

đi trốn

Hiệu suất khôn ngoan, PayPal dường như nghĩ những điều tốt về Node http. //đồng ghi chú. blogspot. com/2013/12/paypals-node js-vs-java-benchmark. html Để bảo mật, mô-đun 'cors' có thể cắm vào Express và có thể được sử dụng cho tất cả các nội dung kiểm soát CORS thông thường. Mô-đun 'mũ bảo hiểm' -- cũng có thể cắm vào Express -- hiển thị một bộ tính năng nhỏ để bảo vệ chống lại những người dùng độc hại bao gồm bảo vệ tập lệnh chéo trang bổ sung. Tôi không chắc mình có gọi một nhà phát triển Fullstack JS là 'thiếu kinh nghiệm' hay không. Có một sự hiểu biết vững chắc về nhiều lĩnh vực trong một hệ sinh thái phát triển không ngừng phát triển thật khó chịu. bạn biết đấy, "10 năm kinh nghiệm so với 1 năm kinh nghiệm 10 lần"

đi trốn

Hiệu suất khôn ngoan, PayPal dường như nghĩ những điều tốt về Node http. //đồng ghi chú. blogspot. com/2013/12/paypals-node js-vs-java-benchmark. html Để bảo mật, mô-đun 'cors' có thể cắm vào Express và có thể được sử dụng cho tất cả các nội dung kiểm soát CORS thông thường. Mô-đun 'mũ bảo hiểm' -- cũng có thể cắm vào Express -- hiển thị một bộ tính năng nhỏ để bảo vệ chống lại những người dùng độc hại bao gồm bảo vệ tập lệnh chéo trang bổ sung. Tôi không chắc mình có gọi một nhà phát triển Fullstack JS là 'thiếu kinh nghiệm' hay không. Có một sự hiểu biết vững chắc về nhiều lĩnh vực trong một hệ sinh thái phát triển không ngừng phát triển thật khó chịu. bạn biết đấy, "10 năm kinh nghiệm so với 1 năm kinh nghiệm 10 lần"

Josh Morgan

Nút. js thậm chí đã không tồn tại được 10 năm (thật buồn cười khi tôi đã thấy các bài đăng công việc thực sự yêu cầu 10 năm kinh nghiệm với nó). Tôi hiểu rằng việc theo kịp sự phát triển của công nghệ là một thách thức và sau 20 năm nữa, tôi có thể nói với bạn rằng vào thời điểm bạn hoàn toàn cảm thấy thoải mái với bất kỳ "full stack" nào thì nó sẽ ít liên quan hơn vì công nghệ luôn phát triển. Sẽ không có gì thay đổi được điều đó, đó chỉ là cách mọi thứ vận hành. Tuy nhiên, bạn không thể thực sự có bánh của bạn và ăn nó ở đó. Công nghệ mới ít được thử nghiệm hơn và do đó kém an toàn hơn, nhưng công nghệ cũ hơn không có nhiều tính năng. Luôn luôn có một sự đánh đổi ở đó. Bất cứ ai tuyên bố khác đang bán cho bạn thứ gì đó

Josh Morgan

Nút. js thậm chí đã không tồn tại được 10 năm (thật buồn cười khi tôi đã thấy các bài đăng công việc thực sự yêu cầu 10 năm kinh nghiệm với nó). Tôi hiểu rằng việc theo kịp sự phát triển của công nghệ là một thách thức và sau 20 năm nữa, tôi có thể nói với bạn rằng vào thời điểm bạn hoàn toàn cảm thấy thoải mái với bất kỳ "full stack" nào thì nó sẽ ít liên quan hơn vì công nghệ luôn phát triển. Sẽ không có gì thay đổi được điều đó, đó chỉ là cách mọi thứ vận hành. Tuy nhiên, bạn không thể thực sự có bánh của bạn và ăn nó ở đó. Công nghệ mới ít được thử nghiệm hơn và do đó kém an toàn hơn, nhưng công nghệ cũ hơn không có nhiều tính năng. Luôn luôn có một sự đánh đổi ở đó. Bất cứ ai tuyên bố khác đang bán cho bạn thứ gì đó

Anil Verma

Tôi được bán trên Node. JS (nếu ứng dụng của bạn đang xây dựng các ứng dụng mạng có khả năng mở rộng cao), Node. JS là con đường để đi vào năm 2015. Không có thắc mắc tại sao rất nhiều công ty mới thành lập và các tập đoàn lớn đang áp dụng nó. C ++, Java, Ruby và Python có vị trí của chúng trong các lĩnh vực tương ứng. Các công ty và sản phẩm mới sẽ được xây dựng trên nhiều ngôn ngữ. Tôi dự đoán việc áp dụng ROR sẽ vẫn cao trong những năm tới để xây dựng các ứng dụng web (đơn giản vì các nhà phát triển ROR dễ dàng có sẵn và thời gian đưa ra thị trường quá ngắn). Bài báo xuất sắc mặc dù Tomislav

Anil Verma

Tôi được bán trên Node. JS (nếu ứng dụng của bạn đang xây dựng các ứng dụng mạng có khả năng mở rộng cao), Node. JS là con đường để đi vào năm 2015. Không có thắc mắc tại sao rất nhiều công ty mới thành lập và các tập đoàn lớn đang áp dụng nó. C ++, Java, Ruby và Python có vị trí của chúng trong các lĩnh vực tương ứng. Các công ty và sản phẩm mới sẽ được xây dựng trên nhiều ngôn ngữ. Tôi dự đoán việc áp dụng ROR sẽ vẫn cao trong những năm tới để xây dựng các ứng dụng web (đơn giản vì các nhà phát triển ROR dễ dàng có sẵn và thời gian đưa ra thị trường quá ngắn). Bài báo xuất sắc mặc dù Tomislav

Daniel Jawna

rất đúng. Công việc của tôi là bảo trì các ứng dụng cũ, thường là truy cập SQL Server dB's + ms hoặc giao diện người dùng php. Những thứ này thường được làm bởi "cháu trai giỏi máy tính". Không có khóa ngoại, nhưng chức năng ngày + giờ tùy chỉnh. bài viết của bạn là tâm trạng của tôi chính xác

Daniel Jawna

rất đúng. Công việc của tôi là bảo trì các ứng dụng cũ, thường là truy cập SQL Server dB's + ms hoặc giao diện người dùng php. Những thứ này thường được làm bởi "cháu trai giỏi máy tính". Không có khóa ngoại, nhưng chức năng ngày + giờ tùy chỉnh. bài viết của bạn là tâm trạng của tôi chính xác

JPoet

Tôi thấy Java rất kém hiệu quả và rất tốn kém đối với nhiều công việc tẻ nhạt ở mức độ thấp. C ++ dành cho các lập trình viên có thể xử lý truy cập/con trỏ bộ nhớ. Hầu hết các lập trình viên của công ty không thể. Ngày trước, bạn có PL/1 và C cho kỹ sư phần mềm và COBOL cho lập trình viên công nghệ thông tin

JPoet

Tôi thấy Java rất kém hiệu quả và rất tốn kém đối với nhiều công việc tẻ nhạt ở mức độ thấp. C ++ dành cho các lập trình viên có thể xử lý truy cập/con trỏ bộ nhớ. Hầu hết các lập trình viên của công ty không thể. Ngày trước, bạn có PL/1 và C cho kỹ sư phần mềm và COBOL cho lập trình viên công nghệ thông tin

joselie castañeda

cảm ơn. điều này rất hữu ích vì tôi sẽ tạo một ứng dụng doanh nghiệp tính toán nặng. tôi nghĩ tôi sẽ thử nút. js trên ứng dụng khác. bây giờ, tôi sẽ sử dụng ruby ​​​​trên đường ray

joselie castañeda

cảm ơn. điều này rất hữu ích vì tôi sẽ tạo một ứng dụng doanh nghiệp tính toán nặng. tôi nghĩ tôi sẽ thử nút. js trên ứng dụng khác. bây giờ, tôi sẽ sử dụng ruby ​​​​trên đường ray

Túlio Spuri

Khi bài báo này được viết?

Túlio Spuri

Khi bài báo này được viết?

vũ khí

Bài báo tuyệt vời

vũ khí

Bài báo tuyệt vời

Olivier

Cảm ơn vì bài viết này, tôi nghĩ rằng lập luận về cùng một ngôn ngữ cho front và dev là điều tồi tệ nhất mà tôi có thể nghe hoặc đọc. Có tổ chức và mã hóa tốt với js là những điều khủng khiếp hơn xuất hiện trong một nhóm. Tôi làm việc từ năm ngoái trong dự án phụ trợ và đôi khi điều này sẽ được mã hóa với khung trưởng thành như django, mất quá nhiều thời gian để hiểu hàng trăm lỗi. Nơi mongodb cảm thấy mát mẻ? . Tôi thực sự nghĩ rằng nút js là một trò đùa lớn và không hay lắm. Trình quản lý gói cung cấp cho chúng tôi một số gói thú vị để vá và ẩn mặt xấu của nút nhưng không có gì để làm về địa ngục gọi lại. Cuối cùng, mã trông giống như một hộp cát lớn hơn tôi không muốn mở tệp để gỡ lỗi hoặc thêm một số dòng mã. Vì vậy, kết luận của tôi là dành cho ứng dụng nhỏ tại sao không nhưng đối với dự án lớn và phát triển không sử dụng cũng như nodejs và mongodb. Trân trọng

Olivier

Cảm ơn vì bài viết này, tôi nghĩ rằng lập luận về cùng một ngôn ngữ cho front và dev là điều tồi tệ nhất mà tôi có thể nghe hoặc đọc. Có tổ chức và mã hóa tốt với js là những điều khủng khiếp hơn xuất hiện trong một nhóm. Tôi làm việc từ năm ngoái trong dự án phụ trợ và đôi khi điều này sẽ được mã hóa với khung trưởng thành như django, mất quá nhiều thời gian để hiểu hàng trăm lỗi. Nơi mongodb cảm thấy mát mẻ? . Tôi thực sự nghĩ rằng nút js là một trò đùa lớn và không hay lắm. Trình quản lý gói cung cấp cho chúng tôi một số gói thú vị để vá và ẩn mặt xấu của nút nhưng không có gì để làm về địa ngục gọi lại. Cuối cùng, mã trông giống như một hộp cát lớn hơn tôi không muốn mở tệp để gỡ lỗi hoặc thêm một số dòng mã. Vì vậy, kết luận của tôi là dành cho ứng dụng nhỏ tại sao không nhưng đối với dự án lớn và phát triển không sử dụng cũng như nodejs và mongodb. Trân trọng

kinh tế trâu bò

Đây là một nhận xét khá thiếu thông tin vì ES6 vẫn hoạt động tốt như một năm trước. Bên cạnh OO từ ES6, còn có TypeScript bổ sung thêm OO cấp doanh nghiệp hơn và có thể thực thi kiểu gõ tĩnh cho JavaScript. Giống. NET được biên dịch thành clr thô, TypeScript cũng có thể được "phiên mã" thành Javascript thô. Hiện tại, NodeJS cho phép thực hiện gần như tất cả những điều này với việc sử dụng tài nguyên máy chủ thậm chí còn tốt hơn và không bị khóa hệ điều hành. Hãy nghĩ đến việc cắt giảm chi phí cơ sở hạ tầng của bạn hơn 2000% vì bạn thực sự không cần phải mở rộng quy mô theo chiều dọc hoặc trả tiền cho những chi phí đó. NET trên mỗi nút quy mô. Ngay cả khi bạn đang đi theo con đường Mono, lol. Tôi sẽ để bạn tự nghiên cứu cách so sánh đó. Các công ty công nghệ tài chính như Paypal biết một hoặc hai điều về tải cũng đang vui vẻ làm những điều tuyệt vời với nút, vì vậy tôi thực sự nghi ngờ nhận xét này của bạn xuất phát từ kiến ​​thức về những gì hệ sinh thái NodeJS thực sự cung cấp cho sản phẩm táo bạo được xây dựng . Ngoài ra, bất kể bạn có thể có ý kiến ​​cá nhân nào về ORM, thực tế hợp lý của tất cả là ORMS sử dụng nhiều tài nguyên bộ nhớ hơn mức cần thiết để chạy phụ trợ. 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. Bạn cũng đã nói điều gì đó liên quan đến bộ nhớ đệm và ORM mà tôi đoán bạn đang đề cập đến bộ nhớ đệm cấp ORM (e. g. Bộ đệm L1/2 trong chế độ Ngủ đông). Tôi hy vọng bạn hiểu rằng bạn KHÔNG THỰC SỰ CẦN ORM để thực hiện bộ nhớ đệm cho bạn. Bạn có thể làm điều này bằng cách sử dụng các công cụ tách rời hiệu quả và đẹp mắt. và tại đó linh hoạt hơn. Điều quan trọng cần ghi nhớ là ngay cả bây giờ, vẫn có người bảo vệ Fortran là công cụ thực sự duy nhất để xây dựng phần mềm. Mọi thứ di chuyển khá nhanh trong ngành này. Niềm tự hào là điều dễ hiểu, nhưng lời khuyên của tôi dành cho bạn là hãy tham gia vào ít nhất 1 thế giới công nghệ mới nhiều nhất là vài năm một lần. Bạn sẽ ở lại có liên quan và cảm ơn tôi sau

kinh tế trâu bò

Đây là một nhận xét khá thiếu thông tin vì ES6 vẫn hoạt động tốt như một năm trước. Bên cạnh OO từ ES6, còn có TypeScript bổ sung thêm OO cấp doanh nghiệp hơn và có thể thực thi kiểu gõ tĩnh cho JavaScript. Giống. NET được biên dịch thành clr thô, TypeScript cũng có thể được "phiên mã" thành Javascript thô. Hiện tại, NodeJS cho phép thực hiện gần như tất cả những điều này với việc sử dụng tài nguyên máy chủ thậm chí còn tốt hơn và không bị khóa hệ điều hành. Hãy nghĩ đến việc cắt giảm chi phí cơ sở hạ tầng của bạn hơn 2000% vì bạn thực sự không cần phải mở rộng quy mô theo chiều dọc hoặc trả tiền cho những chi phí đó. NET trên mỗi nút quy mô. Ngay cả khi bạn đang đi theo con đường Mono, lol. Tôi sẽ để bạn tự nghiên cứu cách so sánh đó. Các công ty công nghệ tài chính như Paypal biết một hoặc hai điều về tải cũng đang vui vẻ làm những điều tuyệt vời với nút, vì vậy tôi thực sự nghi ngờ nhận xét này của bạn xuất phát từ kiến ​​thức về những gì hệ sinh thái NodeJS thực sự cung cấp cho sản phẩm táo bạo được xây dựng . Ngoài ra, bất kể bạn có thể có ý kiến ​​cá nhân nào về ORM, thực tế hợp lý của tất cả là ORMS sử dụng nhiều tài nguyên bộ nhớ hơn mức cần thiết để chạy phụ trợ. 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. Bạn cũng đã nói điều gì đó liên quan đến bộ nhớ đệm và ORM mà tôi đoán bạn đang đề cập đến bộ nhớ đệm cấp ORM (e. g. Bộ đệm L1/2 trong chế độ Ngủ đông). Tôi hy vọng bạn hiểu rằng bạn KHÔNG THỰC SỰ CẦN ORM để thực hiện bộ nhớ đệm cho bạn. Bạn có thể làm điều này bằng cách sử dụng các công cụ tách rời hiệu quả và đẹp mắt. và tại đó linh hoạt hơn. Điều quan trọng cần ghi nhớ là ngay cả bây giờ, vẫn có người bảo vệ Fortran là công cụ thực sự duy nhất để xây dựng phần mềm. Mọi thứ di chuyển khá nhanh trong ngành này. Niềm tự hào là điều dễ hiểu, nhưng lời khuyên của tôi dành cho bạn là hãy tham gia vào ít nhất 1 thế giới công nghệ mới nhiều nhất là vài năm một lần. Bạn sẽ ở lại có liên quan và cảm ơn tôi sau

biên tập

Tôi thực sự muốn có thể dùng thử Node. js nhưng thật khó để có được một cái gì đó đang chạy. Cài đặt một ứng dụng "đơn giản" luôn dẫn đến một danh sách những việc bạn cần làm, cài đặt toàn cầu (không phải lúc nào cũng có thể), chỉnh sửa tệp, cố gắng tìm hiểu ý nghĩa của các nhà phát triển chết tiệt trong các hướng dẫn ít ỏi của họ. Nó sẽ nhanh chóng trở nên tồi tệ nếu bạn làm sai một điều nhỏ nhất. Nếu nó tuyệt vời như vậy, tại sao không ai tìm ra cách tạo các trình cài đặt đơn giản với thứ này?

biên tập

Tôi thực sự muốn có thể dùng thử Node. js nhưng thật khó để có được một cái gì đó đang chạy. Cài đặt một ứng dụng "đơn giản" luôn dẫn đến một danh sách những việc bạn cần làm, cài đặt toàn cầu (không phải lúc nào cũng có thể), chỉnh sửa tệp, cố gắng tìm hiểu ý nghĩa của các nhà phát triển chết tiệt trong các hướng dẫn ít ỏi của họ. Nó sẽ nhanh chóng trở nên tồi tệ nếu bạn làm sai một điều nhỏ nhất. Nếu nó tuyệt vời như vậy, tại sao không ai tìm ra cách tạo các trình cài đặt đơn giản với thứ này?

Alexis Menest

Nền tảng blog ma https. //github. com/TryGhost/Ghost/blob/master/gói. json

Alexis Menest

Nền tảng blog ma https. //github. com/TryGhost/Ghost/blob/master/gói. 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

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

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

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?

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

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ư

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

Đó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

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 nút 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 nút 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

cảm ơn vì bài viết tuyệt vời thực sự rất hữu ích để hiểu nút. js subkuchsell. com

subkuchsell. com

cảm ơn vì bài viết tuyệt vời thực sự rất hữu ích để hiểu nút. js subkuchsell. com

Tomislav Capan

Vâng, đây là sự thật, bài viết được tác giả và xuất bản vào tháng 8 năm 2013. (xin lỗi vì đã xác nhận muộn như vậy, chưa thấy điều này sớm hơn)

Tomislav Capan

Vâng, đây là sự thật, bài viết được tác giả và xuất bản vào tháng 8 năm 2013. (xin lỗi vì đã xác nhận muộn như vậy, chưa thấy điều này sớm hơn)

người chơi gôn484

Trong vũ trụ nào Mongodb có thể được gọi là DB đối tượng? . Đó là DB hướng tài liệu không phải DB hướng đối tượng. Tôi chỉ không muốn bất kỳ đứa trẻ nào bị nhầm lẫn

người chơi gôn484

Trong vũ trụ nào Mongodb có thể được gọi là DB đối tượng? . Đó là DB hướng tài liệu không phải DB hướng đối tượng. Tôi chỉ không muốn bất kỳ đứa trẻ nào bị nhầm lẫn

người chơi gôn484

Chúng tôi đã chuyển sang một ngôn ngữ cho phần phụ trợ và giao diện người dùng nhưng chúng tôi quyết định giữ lại ngôn ngữ chạy nhanh như chớp trong thời gian chạy và có loại an toàn cũng như hỗ trợ các ORM tiêu chuẩn với tải chậm, v.v. , Chúng tôi không muốn vứt bỏ tất cả những thứ đó, đó là điều bạn phải làm khi sử dụng giải pháp JS trên phần phụ trợ của mình. Java trên phần phụ trợ là điều không cần bàn cãi (miễn là bạn không quá kỹ sư và làm phức tạp quá mức ứng dụng của mình với bộ nhớ và CPU đang làm cạn kiệt Spring). Chìa khóa để sử dụng Java cho giao diện người dùng là sử dụng một khung công tác Java thực hiện tất cả JS cho bạn - vì vậy bạn có thể sống trong một thế giới không phải xử lý JS và gắn bó với mã được biên dịch, an toàn về kiểu chữ, phù hợp với doanh nghiệp. Giải pháp này cũng có thể mở rộng - J2SE đã hỗ trợ phân cụm trong gần hai thập kỷ nay. Một khung giao diện người dùng Java như vậy đáp ứng tất cả các nhu cầu JS của chúng tôi và cung cấp cho chúng tôi tất cả tính năng 'cập nhật một phần' với mô hình điều khiển sự kiện AJAX với tùy chọn websockets là Wicket

người chơi gôn484

Chúng tôi đã chuyển sang một ngôn ngữ cho phần phụ trợ và giao diện người dùng nhưng chúng tôi quyết định giữ lại ngôn ngữ chạy nhanh như chớp trong thời gian chạy và có loại an toàn cũng như hỗ trợ các ORM tiêu chuẩn với tải chậm, v.v. , Chúng tôi không muốn vứt bỏ tất cả những thứ đó, đó là điều bạn phải làm khi sử dụng giải pháp JS trên phần phụ trợ của mình. Java trên phần phụ trợ là điều không cần bàn cãi (miễn là bạn không quá kỹ sư và làm phức tạp quá mức ứng dụng của mình với bộ nhớ và CPU đang làm cạn kiệt Spring). Chìa khóa để sử dụng Java cho giao diện người dùng là sử dụng một khung công tác Java thực hiện tất cả JS cho bạn - vì vậy bạn có thể sống trong một thế giới không phải xử lý JS và gắn bó với mã được biên dịch, an toàn về kiểu chữ, phù hợp với doanh nghiệp. Giải pháp này cũng có thể mở rộng - J2SE đã hỗ trợ phân cụm trong gần hai thập kỷ nay. Một khung giao diện người dùng Java như vậy đáp ứng tất cả các nhu cầu JS của chúng tôi và cung cấp cho chúng tôi tất cả tính năng 'cập nhật một phần' với mô hình điều khiển sự kiện AJAX với tùy chọn websockets là Wicket

Rumana Amin

Xin chào Tomislav, bài viết của bạn rất hay và nhiều thông tin. Nó đã giúp tôi rất nhiều để hiểu về Node. js và nó sử dụng

Rumana Amin

Xin chào Tomislav, bài viết của bạn rất hay và nhiều thông tin. Nó đã giúp tôi rất nhiều để hiểu về Node. js và nó sử dụng

đại bàng chiến tranh

Câu trả lời đơn giản là không sử dụng Node. js cho điều đó. Bạn đang thiếu phần nào trong đó? . dễ. Thực hiện một câu lệnh THAM GIA lớn trên một triệu hàng trên RDBS? . Bác sĩ phẫu thuật không làm việc với cưa máy. Các lập trình viên cũng không nên

đại bàng chiến tranh

Câu trả lời đơn giản là không sử dụng Node. js cho điều đó. Bạn đang thiếu phần nào trong đó? . dễ. Thực hiện một câu lệnh THAM GIA lớn trên một triệu hàng trên RDBS? . Bác sĩ phẫu thuật không làm việc với cưa máy. Các lập trình viên cũng không nên

người chơi gôn484

Bạn đánh giá thấp ORM vì hầu hết những người chưa bao giờ xây dựng hệ thống OO với ORM hiệu suất cao tốt mà đá làm được (và bởi ORM 'tốt', tôi KHÔNG đề cập đến ORM mà hầu hết mọi người nghĩ đến khi sử dụng, Hibernate. )

người chơi gôn484

Bạn đánh giá thấp ORM vì hầu hết những người chưa bao giờ xây dựng hệ thống OO với ORM hiệu suất cao tốt mà đá làm được (và bởi ORM 'tốt', tôi KHÔNG đề cập đến ORM mà hầu hết mọi người nghĩ đến khi sử dụng, Hibernate. )

người chơi gôn484

Tôi đồng ý - bài viết này và các nhận xét liên quan của các chàng trai hâm mộ JS xác nhận nỗi sợ hãi của tôi rằng hầu hết các ứng dụng JavaScript phải có các mô hình miền thiếu máu (https. //martinfowler. com/bliki/AnemiaDomainModel. html) khá tầm thường và hầu như ít biểu thức hơn - tất cả công việc sẽ được thực hiện trong logic nghiệp vụ tách rời (không được đóng gói và chắc chắn không đa hình)

người chơi gôn484

Tôi đồng ý - bài viết này và các nhận xét liên quan của các chàng trai hâm mộ JS xác nhận nỗi sợ hãi của tôi rằng hầu hết các ứng dụng JavaScript phải có các mô hình miền thiếu máu (https. //martinfowler. com/bliki/AnemiaDomainModel. html) khá tầm thường và hầu như ít biểu thức hơn - tất cả công việc sẽ được thực hiện trong logic nghiệp vụ tách rời (không được đóng gói và chắc chắn không đa hình)

người chơi gôn484

Tôi đoán trải nghiệm của bạn với 'ORM' chỉ giới hạn ở Hibernate. Tôi đã có một trải nghiệm tương tự cho đến khi tôi nghĩ rằng phải có những ORM tốt hơn ngoài kia - hãy nhìn xung quanh - những ORM khác tồn tại

người chơi gôn484

Tôi đoán trải nghiệm của bạn với 'ORM' chỉ giới hạn ở Hibernate. Tôi đã có một trải nghiệm tương tự cho đến khi tôi nghĩ rằng phải có những ORM tốt hơn ngoài kia - hãy nhìn xung quanh - những ORM khác tồn tại

người chơi gôn484

Điểm hay Adin - Tôi sắp làm những cái giống nhau. Liên quan đến tuyên bố của bài báo rằng các khung truyền thống "sinh ra một luồng mới cho mỗi kết nối (yêu cầu)". Vì vậy, rất sai. Chắc hẳn đã khiến nhiều người tức giận khi thấy một lỗi như vậy mà a) tác giả biết rõ ràng là sai và kiên trì với quan điểm hoặc b) chưa bao giờ sử dụng bất kỳ khung phụ trợ nào khác và vì vậy không nhận ra rằng mình đã sai. Sự kết hợp của kết nối với yêu cầu cũng rất thú vị. Kiến thức của anh ấy không mở rộng để hiểu khái niệm kết nối "keep lives". Một kết nối không có mối quan hệ 1-1 với các yêu cầu như anh ấy đề xuất. Loại quan điểm sai lệch, méo mó này về mức độ thông minh, trưởng thành, phát triển cao của các khuôn khổ (ví dụ:. , Java/Tomcat và tôi chắc chắn. net/ASP) khiến tôi cảm thấy như bài viết này bị vấy bẩn và không đại diện cho sự thật về các lựa chọn thay thế. Liên quan đến việc loại bỏ tâm lý Yêu cầu/Phản hồi - nhiều khung hiện tại cũng đã thực hiện điều này và tạo ra một kiến ​​trúc hướng thành phần hỗ trợ các bản cập nhật dựa trên mô hình không đồng bộ. ví dụ. , Java Wicket hoặc Angular JS. Nó gần giống như chạy JS (một loại ngôn ngữ không an toàn, không phải OO - nếu bạn là người tin tưởng rằng tính kế thừa 'nguyên mẫu' thủ công, tự lắp ráp theo tinh thần OO thực sự) trên máy chủ không phải là một khái niệm có đủ giá trị mà không cần vặn vẹo . Nó là như vậy hoặc có thể nó là như vậy

người chơi gôn484

Điểm hay Adin - Tôi sắp làm những cái giống nhau. Liên quan đến tuyên bố của bài báo rằng các khung truyền thống "sinh ra một luồng mới cho mỗi kết nối (yêu cầu)". Vì vậy, rất sai. Chắc hẳn đã khiến nhiều người tức giận khi thấy một lỗi như vậy mà a) tác giả biết rõ ràng là sai và kiên trì với quan điểm hoặc b) chưa bao giờ sử dụng bất kỳ khung phụ trợ nào khác và vì vậy không nhận ra rằng mình đã sai. Sự kết hợp của kết nối với yêu cầu cũng rất thú vị. Kiến thức của anh ấy không mở rộng để hiểu khái niệm kết nối "keep lives". Một kết nối không có mối quan hệ 1-1 với các yêu cầu như anh ấy đề xuất. Loại quan điểm sai lệch, méo mó này về mức độ thông minh, trưởng thành, phát triển cao của các khuôn khổ (ví dụ:. , Java/Tomcat và tôi chắc chắn. net/ASP) khiến tôi cảm thấy như bài viết này bị vấy bẩn và không đại diện cho sự thật về các lựa chọn thay thế. Liên quan đến việc loại bỏ tâm lý Yêu cầu/Phản hồi - nhiều khung hiện tại cũng đã thực hiện điều này và tạo ra một kiến ​​trúc hướng thành phần hỗ trợ các bản cập nhật dựa trên mô hình không đồng bộ. ví dụ. , Java Wicket hoặc Angular JS. Nó gần giống như chạy JS (một loại ngôn ngữ không an toàn, không phải OO - nếu bạn là người tin tưởng rằng tính kế thừa 'nguyên mẫu' thủ công, tự lắp ráp theo tinh thần OO thực sự) trên máy chủ không phải là một khái niệm có đủ giá trị mà không cần vặn vẹo . Nó là như vậy hoặc có thể nó là như vậy

người chơi gôn484

Không phải mọi khách hàng có phiên hoạt động đều cần được phân bổ chuỗi riêng của họ - các chuỗi được chia sẻ và mỗi người dùng chỉ cần một chuỗi cho các yêu cầu dịch vụ. Các yêu cầu đến trong các đợt ngắn và không cần phải kết nối một luồng quá lâu nếu mã phía sau đang thực thi bằng ngôn ngữ được biên dịch, tối ưu hóa cao và cơ sở dữ liệu nhanh. Vì lý do này, bạn không thể nói "Hệ thống A có thể hỗ trợ 10.000 luồng do đó hệ thống chỉ có thể hỗ trợ 10.000 máy khách". Số lượng khách hàng được hỗ trợ là các đơn đặt hàng lớn hơn số lượng luồng có sẵn do tính đa dạng. 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"

người chơi gôn484

Không phải mọi khách hàng có phiên hoạt động đều cần được phân bổ chuỗi riêng của họ - các chuỗi được chia sẻ và mỗi người dùng chỉ cần một chuỗi cho các yêu cầu dịch vụ. Các yêu cầu đến trong các đợt ngắn và không cần phải kết nối một luồng quá lâu nếu mã phía sau đang thực thi bằng ngôn ngữ được biên dịch, tối ưu hóa cao và cơ sở dữ liệu nhanh. Vì lý do này, bạn không thể nói "Hệ thống A có thể hỗ trợ 10.000 luồng do đó hệ thống chỉ có thể hỗ trợ 10.000 máy khách". Số lượng khách hàng được hỗ trợ là các đơn đặt hàng lớn hơn số lượng luồng có sẵn do tính đa dạng. 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"

người chơi gôn484

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ể

người chơi gôn484

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ể

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

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ù

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 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

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 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)

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 ý. Chúng tôi đã cố gắng mô tả một số trong bài viết 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

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 ý. Chúng tôi đã cố gắng mô tả một số trong bài viết 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

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

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.

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

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

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

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

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 thứ 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ữ. Một khi tôi nắm bắt được thực tế rằng bầu trời là giới hạn khi nói đến 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 . Tôi tin rằng một khi mọi người tham gia với sự hiểu biết về cách Node. js hoạt động, cách bạn có thể triển khai hiệu quả các tiêu chuẩn thường được thực thi bằng ngôn ngữ đánh máy và thực tế là 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. Cuối cùng, tôi sẽ nói thêm rằng khả năng sử dụng 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

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 thứ 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ữ. Một khi tôi nắm bắt được thực tế rằng bầu trời là giới hạn khi nói đến 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 . Tôi tin rằng một khi mọi người tham gia với sự hiểu biết về cách Node. js hoạt động, cách bạn có thể triển khai hiệu quả các tiêu chuẩn thường được thực thi bằng ngôn ngữ đánh máy và thực tế là 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. Cuối cùng, tôi sẽ nói thêm rằng khả năng sử dụng 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

Gage Poon

Phát triển nhanh, nhẹ, mượt mà hơn 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. Khung JavaScript này rất phổ biến trong số các phần khởi động. Tuy nhiên, những tên tuổi lớn như Netflix, Paypal, eBay, Microsoft, Uber, DivBox. trong vv. cũng đang sử dụng khung phát triển web giàu tính năng này

Gage Poon

Phát triển nhanh, nhẹ, mượt mà hơn 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. Khung JavaScript này rất phổ biến trong số các phần khởi động. Tuy nhiên, những tên tuổi lớn như Netflix, Paypal, eBay, Microsoft, Uber, DivBox. trong vv. cũng đang sử dụng khung phát triển web giàu tính năng này

rajivkumar bonam

node js là gì cách viết mã trong node js

rajivkumar bonam

node js là gì cách viết mã trong 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, đây là một bài viết rất chi tiết và sâu sắc dựa trên các trường hợp. 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. 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

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? . Tôi đã đọc hàng trăm bài báo trên web về lý do tại sao ai đó nên sử dụng nút nhưng tất cả chúng đều đề cập đến điều gì đó có thể được thực hiện với công nghệ mà chúng tôi đã có từ những năm 90. 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. Vì vậy, nếu nó đủ nhanh để thực hiện điều tương tự qua kết nối quay số thì nút đã làm gì để cải thiện hệ sinh thái của internet