Trăn bóng 10.000 gram

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

Nội dung chính Show

nút là gì. js?
Why Use Node. js?
How Does Node. js Work?
npm. Trình quản lý gói nút
Where to Use Node. js
API on Top of an Object DB
Queued Inputs
Data Streaming
Brokerage/Stock Trader’s Dashboard
Application Monitoring Dashboard
Bảng điều khiển giám sát hệ thống
Where to Use Node. js, but Cautiously
Server-side Web Applications
Nơi không sử dụng nút. js
Server-side Web Application With a Relational Database Application
Heavy Server-side Computation and/or Processing
Why Choose Node. js?
Further Reading on the Toptal Engineering Blog
Understanding the basics
What is Node. js?
What is Node. js used for?
What is a web framework?
Is Node. js là một khuôn khổ?
là nút. js một ngôn ngữ lập trình?
Tại sao là nút. js phổ biến?
What is the difference between Node. js và Góc/AngularJS?
Why is Node. js xấu?
Bình luận

Qua

Tomislav Capan

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

CHIA SẺ

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

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

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

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

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

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

nút là gì. js?

Node. js is composed of Google’s V8 JavaScript engine, the libUV platform abstraction layer, and a core library that is written in JavaScript. Additionally, Node. js is based on the open web stack (HTML, CSS, and JS), and operates over the standard port 80

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

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

Why Use Node. js?

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

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

How Does Node. js Work?

Node really shines in building fast, scalable network applications. This is due to its capability of handling a huge number of simultaneous connections with high throughput

Node. js uses non-blocking, event-driven I/O to remain lightweight and efficient in the face of data-intensive real-time applications that run across distributed devices

Node. js is a platform that fills a particular need, and understanding this is absolutely essential. For example, you wouldn’t use Node. js to perform CPU-intensive operations. Nearly all of Node’s advantages are annulled if it’s used for heavy computation

Node. js is a platform that fills a particular need. It is not a silver bullet, or a platform that will dominate the web development world

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

Per Michael Abernethy’s 2011 article “Just what is Node. js?”, take a thread with an accompanying 2 MB of memory, running on a system with 8 GB of RAM, and providing a theoretical maximum of 4,000 concurrent connections. Add to this the cost of context-switching between threads, and you get a common scenario in traditional web-serving techniques. Node. js avoids all this, achieving high scalability levels

There is, of course, the question of sharing a single thread among all client requests, a potential pitfall of writing Node. js applications

First, heavy computation could choke up Node’s single thread and cause problems for all clients, as incoming requests are blocked until said computation is completed

Second, developers need to be vigilant and prevent exceptions from bubbling up to the core (top) Node. js event loop, as this would cause the 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ư 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ụ CLI npm 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ụ

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 (formerly Jade)

A templating engine inspired by HAML, a default in Express. js

mongodb and mongojs

MongoDB wrappers to provide the API for MongoDB object databases in Node. js

redis

The Redis client library

lodash, underscore, lazy. js

The JavaScript utility belt. Underscore initiated the game but got overthrown by one of its two counterparts, mainly due to lazy. js' better performance and modular implementation

forever

A utility for ensuring that a given node script runs continuously; keeps your Node. js process up in production in the face of any unexpected failures

bluebird

A full-featured Promises/A+ implementation with exceptionally good performance

moment. js

A JavaScript date library for parsing, validating, manipulating, and formatting dates

Where to Use Node. js

Chat

Chat is a typical real-time, multi-user application—from IRC (back in the day)—to modern implementations in Node. js with WebSocket

The chat application is lightweight, high traffic, and data intensive (but low processing /computation). 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

Simple, yet covering most of the paradigms you’ll ever use in a typical Node. js application, chat is a great use case for learning

Let’s depict how chat works. Say we have a single chat room where users can exchange messages in one-to-many (actually all) fashion. Let’s also say there are three users connected to our message board

On the server side, a simple Express. js application implements

A GET / request handler which serves the webpage containing a message board and a ‘Send’ button to initialize new message input, and
A WebSocket server that listens for new messages emitted by WebSocket clients

On the client side, we have an HTML page with a couple of handlers set up

A handler for the ‘Send’ button click event, which picks up the input message and sends it down the WebSocket
A handler that listens for new incoming messages on the WebSocket client (i. e. , user-originated messages that the server wants the client to display)

When a client posts a message, here’s what happens

The browser catches the ‘Send’ button click through a JavaScript handler. It picks up the value from the input field (i. e. , the message text), and emits a WebSocket message using the WebSocket client connected to our server (initialized on web page initialization)
The server-side component of the WebSocket connection receives the message and forwards it to all other connected clients, using the broadcast method
All clients receive the new message as a push message, via a WebSocket client-side component running within the web page. The clients then pick up the message content and update the web page in place, by appending the new message to the board

Client and Server WebSockets in a Node.js Application

Here is a simple example of real-time chat with NodeJS, Socket. io and ExpressJS

For a more powerful solution, you might use a simple cache based on the Redis store. Or in an even more advanced solution, use a message queue to handle the routing of messages to clients, and a more robust delivery mechanism. The queue may cover for temporary connection losses or store messages for registered clients while they’re offline

Regardless of the solution you choose, Node. js operates under the same basic principles. reacting to events, handling many concurrent connections, and maintaining fluidity in the user experience

API on Top of an Object DB

Node. js is a natural fit for exposing the data from object DBs (e. g. , MongoDB). JSON-stored data allows Node. js to function without impedance mismatch and data conversion

For instance, if you’re using Rails, you would convert from JSON to binary models, then expose them back as JSON over the HTTP when the data is consumed by Backbone. js, Angular. js, etc. —or even plain jQuery AJAX calls. With Node. js, you can expose JSON objects with a REST API for the client to consume

If you are using MongoDB, you needn’t worry about converting between JSON and whatever else when reading or writing from the database. Thus, you can avoid the need for multiple conversions by using a uniform data serialization format across the client, server, and database

Queued Inputs

Node allows you the flexibility to push database write-offs to the side. But there are even more reasons to use Node. js

If you’re receiving a large amount of concurrent data, your database can become a bottleneck. Node. js can easily handle the concurrent connections. Because—in this case—database access is a blocking operation, we run into trouble. 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

This approach enables the system to maintain responsiveness under a heavy load. It is particularly useful when the client doesn’t require firm confirmation of a successful data write, when logging or writing user-tracking data, processed in batches, to be used at a later time, or for operations that don’t need to be reflected instantly, like updating a Facebook “likes” count

Data is queued through some kind of caching or message queuing infrastructure like RabbitMQ or ZeroMQ. It is then digested by a separate database batch-write process or computation-intensive processing backend service, written in a better-performing platform for such a task

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

In short. With Node you can push the database writes off to the side to deal with later

Data Streaming

Why not use Node. js in data streaming? In more traditional web platforms, HTTP requests and responses are treated like isolated events—although they’re actually streams. We can use this observation to build some cool Node. js features

For example, we can process files while they’re still being uploaded. As data comes in through a stream, we can process it in parallel during that upload process. This is true for real-time audio or video encoding and proxying between various data sources

Proxy

Node. js is easily employed as a server-side proxy, where it can handle a large amount of simultaneous connections in a nonblocking manner. It’s useful for proxying different services with varying response times, or collecting data from multiple source points

As an example, let’s consider a server-side application communicating with third-party resources, pulling in data from different sources, or storing assets (like images and videos) to third-party cloud services

Using Node in place of a dedicated proxy server might be helpful if your proxying infrastructure is non-existent, or if you need a solution for local development. By this, I mean that you could build a client-side app with a Node. js development server for assets and proxying/stubbing API requests. In production, you’d handle such interactions with a dedicated proxy service (like nginx or HAProxy)

Brokerage/Stock Trader’s Dashboard

At the application level, brokers’ trading software is another example where desktop software dominates, but could be easily replaced with a real-time web solution. Brokers’ trading software tracks stock prices, performs calculations and technical analysis, and renders graphs and charts

Why not use Node. js to write a real-time web-based solution for brokers? Then, brokers could easily switch workstations or work locations. 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

Application Monitoring Dashboard

Imagine how you could grow your business if you could see what your visitors were doing in real time. With Node’s real-time, two-way sockets, you can gain this ability

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 productizes this idea

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

Now, let’s visit the infrastructure side of things. 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. With Node. 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

Both internal (intracompany) and public services’ statuses can be reported live and in real time using this technology. Đẩ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. The applications would run on the open web stack backed by Node. js và WebSocket

Don’t try to build hard real-time systems in Node (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 đó

Where to Use Node. js, but Cautiously

Server-side Web Applications

với nút. js with 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 would carry rendered HTML is not an ideal use case. 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. Here are some facts to consider

Pros

You can significantly ease the development of an application that does not require CPU-intensive computation, by using Javascript to build it top to bottom, even down to the database level—if you use JSON storage Object DB (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

Cons

Mọi tính toán sử dụng nhiều CPU sẽ chặn Node. js responsiveness, so a threaded platform is a better approach. Alternatively, you could try scaling out the computation
Sử dụng nút. js with a relational database can be painful. Nếu bạn đang cố gắng thực hiện các thao tác quan hệ, hãy cân nhắc sử dụng một môi trường như Rails, Django hoặc ASP. mạng MVC

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

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

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

Server-side Web Application With a Relational Database Application

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

It’s possible and not uncommon to use Node solely on the front end, while keeping your Rails back end with its easy access to a relational DB

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

Heavy Server-side Computation and/or Processing

Nút. js is not the best platform to handle heavy computation. No, you definitely don’t want to build a Fibonacci computation server in 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 tính toán 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. Alternatively, you can run several Node. js server instances pretty easily behind a reverse proxy via 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. Ensure that you use an appropriate environment for the background processes, and that they communicate via a message queue server like RabbitMQ

While you may run background processes on the main server, this approach may not scale well once the load increases. 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

With Node. js—as opposed to most other platforms—you enjoy that high reqs/sec throughput we talked about, as each request is a small task that Node handles quickly and efficiently

Why Choose Node. js?

We discussed Node. js from theory to practice, beginning with its purpose, and ending with its sweet spots and pitfalls

Problems with Node almost always originate from the fact that blocking operations are the root of all evil—and 99% of Node misuses are a direct consequence

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

If your use case does not contain CPU-intensive operations, nor accesses blocking resources, you can exploit the benefits of Node. js and enjoy fast and scalable network applications. Welcome to the real-time web

Understanding the basics

What is Node. js?

Node. js is a server-side, open-source, JavaScript runtime environment. Node uses Google's V8 engine---libUV---to deliver cross-platform compatibility and a core library. Notably, Node. js does not expose a global window object, since it does not run within a browser

What is Node. js used for?

Because Node. js is single-threaded, we use it primarily for non-blocking, event-driven servers. We can also use Node. 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

What is a web framework?

Web frameworks like Angular and React are libraries that help organize and generate the front-end code that runs in a web browser. Web frameworks reuse code for common operations, thereby reducing development time. Some web frameworks are full stack

Is Node. 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 for WebSocket servers

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

Node. js is not a programming language. The ". 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ó. Anything that can transpile to JavaScript---like TypeScript, Haxe, or CoffeeScript---can also be used with 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ó

What is the difference between Node. js và Góc/AngularJS?

nút. js runtime environment executes JavaScript code on the server, whereas Angular is a JavaScript framework that is executed on the client (i. e. , trong trình duyệt web)

Why is Node. js xấu?

Node. js isn't bad. 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ủ

Bình luận

Anony Mouse

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

Anony Mouse

Đố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. However, I do want to comment on something that is a bit of a pet peeve of mine -- I wish you wouldn't contrast it with a non-existent straw-man "traditional" system in "how it works". 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) Similarly, userspace threads (I. e. frames or closures if you don't want to talk threads) take memory resources in the same way kernel threads do. 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) The BIG problem with single-thread concurrency is the lack of parallelism. Sure, you can handle thousands of requests per second, but only one CPU on your 40 core server is going to doing ANY work. Dù sao đi nữa, tất cả những điều trên liên quan đến một đoạn khá nhỏ trong bài đăng xuất sắc của bạn. Nút không thực sự có lỗi về điều này, chỉ là có rất nhiều FUD xung quanh các luồng và quy trình mà mọi người thường sử dụng để biện minh cho các thiết kế điên rồ (và tránh các luồng khi chúng hoàn toàn là cách tiếp cận phù hợp cho phần lớn các tình huống)

Adin Scannell

Eric Elliott

Tất cả lời khuyên của bạn về các ứng dụng nặng tính toán không thể sai hơn. Chắc chắn rằng việc cố gắng tính toán nội tuyến nặng nề với chu kỳ phản hồi yêu cầu là một ý tưởng tồi, nhưng điều tương tự cũng có thể xảy ra với các môi trường luồng. If you have CPU bound operations, it's a good idea to handle them with worker processes. JavaScript, and Node in particular are actually very well suited to handle distributed computation - especially with the good support for functional style programming. Nếu bạn viết thuật toán của mình bằng cách sử dụng các hàm thuần túy và phân phối khối lượng công việc cho nhân viên, bạn có thể dễ dàng phân phối khối lượng công việc của mình trên các cụm được nối mạng. Sự hỗ trợ tuyệt vời của Node cho kết nối mạng làm cho nó trở thành một môi trường lý tưởng cho cả các tác vụ điện toán và điều phối, đồng thời nó có tốc độ nhanh hơn Ruby ở cả hai khía cạnh

Eric Elliott

jim thomas

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

jim thomas

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

roland

You certainly don't want to block any Node. js process that is handling server requests, but that doesn't mean you shouldn't do heavy computations behind a Node. js server. So long as the process doing the heavy computations is spawned asynchronously from your server process. 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

Danny Machal

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

Danny Machal

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

irneb

Bất kỳ hệ thống hybrid như vậy? . Sử dụng nút. js to process a request by simply placing it onto a to-process queue, return a message to the client stating something like "calculating. ". Sau đó nút. js được tự do tiếp tục với yêu cầu tiếp theo. Sau đó, hàng đợi xử lý có thể được chạy qua bằng cách sử dụng một luồng khác biệt (hoặc thậm chí nhiều luồng). As and when these complete, they send their results to 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

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, thanks for this very well written and concise article. 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. So it boils down to just one programming language (JS), one data format (JSON) and one programming paradigma (Async), wow

Gerd Jungbluth

chad

Đó là lời giải thích tốt nhất hiện có về Node. js. I finally understood that it is very useful (in certain scenarios) and not just a hype. Cảm ơn rất nhiều điều này rất nhiều thông tin

chad

ellisgl

Nút hoạt động tốt với cơ sở dữ liệu quan hệ, chỉ cần không sử dụng ORM. SQL 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

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) Referenced presentation shows some measurements and numbers, you may be quite right on the internals but the common rough overview still stands as a general comparison of how things work between those two worlds. 4) parallelization options are also discussed within the article - as background worker processes, or several node processes behind a reverse proxy, or with Node clustering API (which is still in Experimental, but will be there eventually). Thanks for the great comments and the quality feedback on the article with that additional info, I appreciate it

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

Any calculation that keeps the CPU busy until the calculation is finished. 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. Hit that with 100 clients - you get a 200-sec delay. 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. As the system is distributed, those workers can use any language/platform, including Node

Tomislav Capan

Thanks for your feedback. I agree on that completely, for worker processes you could use JS when it fits, and that implies Node. js as that's what runs JS on the server, but you can also use other languages that do the particular work at hand fast

Tomislav Capan

ellisgl

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

Adin Scannell

Lời xin lỗi cho bức tường của văn bản. Excellent discussion. 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. Like the much beloved nginx . ) 2/3) Xin lỗi, có thể tôi chưa rõ. When I said FUD regarding threads and processes, I *meant the referenced presentation*. Nó chỉ là một loạt các tiêu chuẩn vi mô được thiết kế đặc biệt để 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. In fact, it's a great talk. But these synthetic micro-benchmarks are not the basis for a fair and through comparison. ) 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

Tomislav Capan

Everything always needs to be put in the right context. 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

Aaron Wang

When use node. 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 is right the queue

Aaron Wang

Ethan

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

Ethan

Eric Elliott

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

Eric Elliott

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

Vedran

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

Vedran

nene odonkor

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

nene odonkor

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

nene odonkor

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

nene odonkor

Moch Lutfi

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

Moch Lutfi

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

Anthony Hildoer

This article is great, except for the part where it says don't use NodeJS for computation because it doesn't have threads. 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. Last time I checked, any system large enough for this entire debate to be relevant anyway is going to span multiple servers anyway, their by nullifying any benefit of threads. Vì vậy, hãy quên đi rằng NodeJS không thể thực hiện công việc chuyên sâu về CPU. Và, nếu bạn không thể, hãy liên hệ với BlueRival. com và chúng tôi có thể sửa tất cả những thứ bạn đã tạo sai với NodeJS

Anthony Hildoer

RiggerTheGeek

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

RiggerTheGeek

hfuti

Xin chào, bài viết hay. Tuy nhiên tôi muốn chỉ ra một điều, NodeJS không chạy trong một luồng đơn lẻ. Lập trình viên không phải sinh ra các luồng mới, chúng được xử lý bởi chính nút trên cơ sở sự kiện. NodeJS được tạo sự kiện, mỗi lệnh gọi hàm cho mỗi sự kiện sẽ chạy trong một luồng riêng biệt. Cách tiếp cận đó khuyến khích viết các chức năng nhẹ hơn. If your function does a lot of computation, reactor it into smaller ones and they all will run in separate threads. Hãy nghĩ về ví dụ nơi bạn xử lý tệp trong khi phát trực tuyến. Điều đó là có thể nhờ chủ đề

hfuti

Matthew Keas

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

Matthew Keas

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

Matti Schneider

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

Matti Schneider

kyoukhana

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

kyoukhana

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

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

Matthew Keas

+1 cho điều đó

Matthew Keas

+1 cho điều đó

Matthew Keas

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

Matthew Keas

Juan G. nuño

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

Juan G. nuño

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

Juan G. nuño

thiên tài

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

thiên tài

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

Trình theo dõi1

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

Trình theo dõi1

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

Trình theo dõi1

Steve Naidamast

Tôi đang bắt đầu tìm Node. js khá thú vị. Tuy nhiên, mô hình mà nó dường như đang quảng bá hầu như không mới đối với CNTT. Trong thế giới truyền thông máy tính lớn, chúng tôi gọi những khả năng như vậy là "đăng nhập lại", trong đó một quy trình đơn lẻ có thể xử lý mức độ cao cá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

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

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

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

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

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

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

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. //codecondo. com/7-minimal-node-js-web-frameworks/ I'd love if you could add the above post to the list . )

Alex Viết

Này Tomislav, http. //codecondo. com/7-minimal-node-js-web-frameworks/ I'd love if you could add the above post to the list . )

Victor Lava

Omg, this is amazing. I have always wanted to learn node. js

Victor Lava

Omg, this is amazing. I have always wanted to learn node. js

Thanks for providing examples, illustrations and use cases. The detailed explanation and steps in some cases with relevant resources makes it a great read. Where nodejs *should* be used is very useful

crueber

All Node code is thread-bound. It may not run on the same thread at all times (which has nothing to do with Node itself, and instead has to do with the operating system process scheduler), but it is thread bound. In order to take advantage of multiple threads, you need to use something like Cluster. http. //nodejs. org/api/cluster. html

crueber

Agreed. I use Postgres for all sorts of GIS operations in an application I've been working on for about a year, and it works great, and benefits from the same non-blocking I/O that any other database access does. It's just that you have to drop down directly to the SQL. There are a couple ORMs, but nothing that is real mature

crueber

elijahca

Awesome, thanks a lot for this

elijahca

Awesome, thanks a lot for this

Zmirc

Minor comment. don't confuse Object DBs with Mongo (Document DB). There are 2 completely different things

Zmirc

Minor comment. don't confuse Object DBs with Mongo (Document DB). There are 2 completely different things

Gianlucca

i agree, good post

Gianlucca

i agree, good post

Gianlucca

yes, i agree

Gianlucca

yes, i agree

Gianlucca

sure

Gianlucca

sure

Toulon

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

Toulon

Jesus Bejarano

ORM for real projects are useless hone

Jesus Bejarano

ORM for real projects are useless hone

Thomas

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

Thomas

Seb

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

Seb

Jarle Leopold Moe

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

Jarle Leopold Moe

Eric Elliott

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

Eric Elliott

jenit shah

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

jenit shah

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

CowsRule

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

CowsRule

robertcooke

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

robertcooke

Anonymous

This is an amazing overview . Thank you

Anonymous

This is an amazing overview . Thank you

Vishnu Tekale

Very well written. Thanks for sharing

Vishnu Tekale

Very well written. Thanks for sharing

Gleb Bahmutov

Why Node is different - using bar as analogy http. //bahmutov. calepin. co/why-node-is-different. html

Gleb Bahmutov

Why Node is different - using bar as analogy http. //bahmutov. calepin. co/why-node-is-different. html

FluckerSputter

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

FluckerSputter

piloh23

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

piloh23

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

Alifa Nurani Putri

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

Alifa Nurani Putri

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

SleightDifference

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. I really had hard time understanding it from their website as well as Wikipedia. Well written post. Keep it up

Clain Dsilva

Cảm ơn bạn đã dành thời gian giải thích về Node. js. I really had hard time understanding it from their website as well as Wikipedia. Well written post. Keep it up

Cezar Luiz

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

Cezar Luiz

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

Marcelo Lima

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

Marcelo Lima

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

Navid

Awesome Article

Navid

Awesome Article

Abdelhakim

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

Abdelhakim

rahul garg

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

rahul garg

siddesh

Super Article

siddesh

Super Article

Fanck

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

Fanck

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

Namo

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

Namo

Ian Kaplan

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

Ian Kaplan

Huge Web

Toptal designer did the design for them

Huge Web

Toptal designer did the design for them

Scott

Great article. Thank you for all the information

Scott

Great article. Thank you for all the information

daimmo

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

daimmo

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

Adnan King

nice

Adnan King

nice

Ethan Garofolo

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

Ethan Garofolo

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

Guest

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

Guest

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

Lambda Pool

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

Lambda Pool

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

Lambda Pool

well its true, ORM is a bad practice after all

Lambda Pool

well its true, ORM is a bad practice after all

Lambda Pool

yes but it does in a very non efficiently way

Lambda Pool

yes but it does in a very non efficiently way

Lambda Pool

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

Lambda Pool

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

John Bailo

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

John Bailo

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

Jayaraj Poroor

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

Jayaraj Poroor

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

Jayaraj Poroor

Regarding using Node. js với cơ sở dữ liệu quan hệ. Shelloid (http. //shelloid. org) is an open source application server for Node. js that we developed to simplify lot of programmer tasks. e. g. , You can declare named SQL queries as annotations and a function by that name automatically gets added to the DB object for you to use

Jayaraj Poroor

I think you do not understand the reason for or characteristics of ORM's very well. ORM's not only isolate data concerns, they provide testability and greater flexibility than traditional SQL clients. ORM's also provide in memory access in place of inefficient joins, so they can actually be far more efficient than SQL in real world scenarios. 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

Bạn không biết những gì bạn đang nói về. If you are writing a non-trivial applications and not using an ORM than I'm sure there will be many developers both today and in the future that will be cursing your name as they wade through ridiculous rafts of SQL. Testability? I guess that's just for trivial applications. When I see ridiculous comments like this coming from node. js fanboi's it makes me suspect that they'd be singing a different tune if node. js had decent RDBMS capabilities

Lambda Pool

you just overate ORM such as most OO fanboys does

Lambda Pool

you just overate ORM such as most OO fanboys does

Lambda Pool

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

Lambda Pool

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

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

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

Lambda Pool

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

Lambda Pool

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

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

Qalandr

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

Qalandr

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

Ty Turner

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

Ty Turner

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

Vob Bobily

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

Vob Bobily

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

cintalauraramarimari

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

cintalauraramarimari

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

Daniel

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

Daniel

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

Michael

Probably one of the main points of this article, that gives Node is supposed scalability, is the offloading to a Queue or Service Bus that leads to asynchronous processing. That is a well proven architectural pattern, available in many languages, is especially used in CQRS (Command Query Responsibility Segregation) with Event Sourcing, is very well suited to be used by technologies such . Net Reactive Extensions that provide considerably greater functionality and flexibility than Node. 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. As for the hate against ORMs. you guys crticising it seem to be moving from front-end development into an area where you have no knowledge or expertise in OO, BDD, TDD or any other proven Enterprise level methodology. Không có khái niệm tích hợp nào ngoài nguồn cấp dữ liệu Twitter. No experience of complex Workflow or scalable caching. This is one of the dangers - you know JavaScript, and a bit of SQL. So everything else is superfluous - until you need it, such as the attempts to bring an element of type checking to JavaScript. Seriously, each technology has its place, but there is no one size fits all approach. Appreciate the strengths of each technology, and use them where appropriate

Michael

Reo

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

Reo

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

Richard Bellantoni

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

Richard Bellantoni

sinta maharani

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

sinta maharani

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

naseya10

Great, informative article. Thanks for sharing this. Unlockpwd

naseya10

Great, informative article. Thanks for sharing this. Unlockpwd

Eric Elliott

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

Eric Elliott

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

Eric Elliott

This reply just strikes me as willful ignorance. 1. Really? Rather than investigate and learn the truth, you just want to ridicule the answer? I'm not taking the bait. Watch Brendan Eich's Fluent talks if you're interested in actually learning something. 2. I know what types and type inference are, and I know the benefits of static types. I've been in this game since before JavaScript was invented. TypeScript is a superset of JavaScript that compiles to JS & allows for sophisticated static analysis. It's structural type system is better than the type system Java had back when I was coding in Java, and it's much better (as in more reliable and flexible) than C and C++. 3. "encapsulation, specialization via inheritance (or prototyping), polymorphism, and externalizing dependencies via IoC" - these are all forms of modularity, and JavaScript modules provide viable alternatives to all of them - and in the case of class inheritance, it's far superior. See https. //medium. com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3 4. "your customers are waiting for the callback. " Fortunately, that's where the performance I talked about in point 1 shines. JS provides efficient utilization of I/O resources. In fact, dealing with I/O bottlenecks is the entire reason that Node was invented. I've ported several large production projects from PHP and Ruby to Node, and seen dramatic reductions in response times, both average response times and response time ranges - and since a typical Node app utilizes a small fraction of the memory required for C# applications, your customer I/O competes less with the RAM paging you might experience with a compiled C# application. 5. "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. Believe it or not, it's a fact, and being more able to adapt to changing needs and experiment more (particularly in the UI layer) delivers very real business value. Why do you think so many enterprise organizations are adopting Node? It's not because some dev prefers JS. Đó 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. Got a good article on that? 'Cause a quick Google search isn't turning up much. Check out this awesome result in the top 3 of the SERP. http. //www. quora. com/Why-isnt-C-with-Mono-popular-for-enterprise-applications-on-Linux-servers . but a quick Google search for Enterprise Node. js delivers quite a bit. Here are the top 3 search results I see. http. //blog. risingstack. com/node-js-is-enterprise-ready/ https. //www. joyent. com/nodejs-support https. //www. centurylinkcloud. com/blog/post/node-js-is-taking-over-the-enterprise-whether-you-like-it-or-not/ There's really no contest here

Eric Elliott

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

Eric Elliott

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

Eric Elliott

Kesava Velugubantla

especially with edge it is really handy

Kesava Velugubantla

especially with edge it is really handy

pawan kumar

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

pawan kumar

Jay

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

Jay

adroittech

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

adroittech

Eric Elliott

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

Eric Elliott

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

Ken Kopelson

Actually, Javascript in the V8 server engine is QUITE fast. 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. None of these technologies are for neophytes

Ken Kopelson

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

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

Ken Kopelson

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

Ken Kopelson

Jacob Ross

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

Jacob Ross

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

Jacob Ross

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

Jacob Ross

JF80

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

JF80

TerraT

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

TerraT

adroittech

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

adroittech

oberona

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

oberona

TerraT

Well I define scripting languages as runtime compilation languages, but there is a lot of overlap these days. 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. The depth of invasion into the inner workings of the compiler that tend to be exposed by compiled languages these days allow for a whole range of design constructs and patterns that allow programming to be more "intelligent", I just don't find this level of sophistication in the scripting languages I have used. It is a severe limitation for serious enterprise development. ORMs are an ugly approach to data access on relational databases, but you would probably have to be a database developer to realise why. Data design and Program design have different constraints, ORMs do either an injustice or have to be modified so much that they provide no productivity. 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. ORMs are a blunt tool if you want real performance from your database and want high concurrency without locking. Its a detailed subject I could probably write a book on it, so sorry if this isn't conclusive enough for you. Can't say much about Python other than I have heard good things in general. I'm the other end of the market on . Net, I crucify the open source guys next door in productivity and my defect level is about 1% of theirs. I think you need a large system before it makes significant differences, as you need to invest in framework and substrate to get the main benefits back, its "mass coding" that is the enemy here. When you have over a 100,000 code files you need a higher level of maintainability as it is simply beyond human capability to do it file by file (and certainly beyond maintenance budgets). By making core services that consume code as content you can achieve a high level of quality while keeping everything granular and ensuring release are small and targeted rather than entire system drops. Mỗi cái đều có của riêng 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ó. It's such a common complaint I should think it doesn't need justifying

TerraT

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

TerraT

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

TerraT

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 thật là 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ó. How exactly do you think threads work in the lower levels anyway? It isn't some "magic", the only way to get true simultaneous code execution is via multiple processors, something you simply can't accomplish with a single thread. It's also a mistake to say that a new "event" does not add memory or clock cycles taken to a stack just because said events are managed by an interpreted scripting language rather than optimized, compiled C++. 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

iwebworld

Good Article for Node JS, you can learn Node JS online in http. //iwebworld. thông tin hoặc gửi email iwebworldinfo@gmail. com

iwebworld

Good Article for Node JS, you can learn Node JS online in 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. By nature, vertical scaling will always have an upper limit predicated by hardware capacity. 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. Choosing which one to use depends on the quality of the tools, whether or not it will be used to extend existing infrastructure, and the perception of the client. 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/ "Any application that can be written in Javascript, will be written in Javascript" - Atwood's Law ORMs are only an issue because they require an additional layer of abstraction from the underlying data. 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/. NET. 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. . cringe. 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 "All the I/O operations is handled by 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. The nice part Node is, the primary focus of the platform is building servers/clients so the ecosystem has a lot of powerful tools to do anything dealing with web development. ". 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. Module imports in the browser have finally been formalized in the language spec, so Bower and the variety of module-loading pseudo-standards (ex AMD, CommonJS, UMD) will go away

đi trốn

TerraT

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ệ

TerraT

đ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 tác 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ả với 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 chạy 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

TerraT

Tôi nghĩ rằng bạn đã đưa ra quan điểm của tôi cho tôi, nói ra những điều vô nghĩa thiếu suy nghĩ, 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ó. You seem to have made a fair few assumptions about what I do and don't know, I have been doing Javascript for 20 years, I know its short comings, I can work effectively in probably 30+ languages, I use what is appropriate, I never indicated otherwise. 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

TerraT

đ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 các thay đổi trên các nhánh tính năng và mã được xem xét 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 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 được 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

Hiệu suất khôn ngoan, PayPal dường như nghĩ những điều tốt về Node http. //dongnotes. 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ộ nhỏ các tính năng để 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

Josh Morgan

Nút. js hasn't even been around for 10 years (which is funny considering I have seen job postings actually asking for 10 years experience with it). 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

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 is the way to go in 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

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

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

joselie castañeda

thanks. đ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

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

buffonomics

Đâ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ộ nhớ đệ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. It's important to keep in mind that, even now, someone out there is still defending Fortran as the one true tool to building software. 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

buffonomics

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

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

Samuel_Ogden

Nút sẽ là một ý tưởng tồi cho một cái gì đó như 9gag. com then? Would you need to do any image manipulation on a different server to prevent blocking?

Samuel_Ogden

Nút sẽ là một ý tưởng tồi cho một cái gì đó như 9gag. com then? Would you need to do any image manipulation on a different server to prevent blocking?

chaitanya

Này Tomislav, Bài báo tuyệt vời. I wanted to know that if suppose I want to get external hardware output in my app, e. g, máy quét hoặc chữ ký điện tử (nếu người dùng đang thực hiện chữ ký điện tử hoặc nhận bản sao được quét từ máy quét), thì tôi có thể truy cập trực tiếp vào ứng dụng của mình không?

chaitanya

Misha R

TypeScript là trình bao bọc cú pháp trên JavaScript tiêu chuẩn và biên dịch thành JavaScript tiêu chuẩn. It is invented to make the code maintainable and allows it to be used more like a real programming language. Given that you have to use JS where appropriate it makes writing it more familiar to real programmers and makes it maintainable. Đ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. Believing that one can not use the new magic Node for everything just because one guy can write front and back end is amateurish

Misha R

ellisgl

Đóng gói một ngôn ngữ bằng một ngôn ngữ khác mà bạn phải dịch sẽ thêm chi phí. Ngoài ra có những thứ không dịch được, chỉ là trong cuộc sống thực, dịch giữa các ngôn ngữ, bạn mất một cái gì đó. Trong trường hợp này, bạn mất tốc độ (phải dịch từ cái này sang cái khác) và tối ưu hóa, vì lý do một. ORM không làm tất cả. In the beginning, I was for ORMs, then I dove deep into it and you end up with "How do I do this?", "Oh you can't easily, you have to do 10 other queries", or you end up with stuff that just seems like it should work well, but you end up wrecking the performance. ORM đơn giản là "Chọn blah blah từ bảng trong đó x = y". The only small redeeming factor of some ORMs are that they will convert their language to which ever DB. But if you are paid to work on a enterprise level application, you are only dealing with 1 - 3 databases, which are for used for separate things. Nếu bạn có 500 nhân viên và 10.000 khách hàng, ORM có thể bị tắc nghẽn

ellisgl

quả cầu Nils

Hey, is there a library/tool you used to creste the graphics ?

quả cầu Nils

Hey, is there a library/tool you used to creste the graphics ?

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

Great article, thanks for the overview. http. //www. steshadoku. com

dohkoo

Great article, thanks for the overview. http. //www. steshadoku. com

subkuchsell. com

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

subkuchsell. com

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

Tomislav Capan

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. (sorry for such a late confirmation, haven't seen this earlier)

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. (sorry for such a late confirmation, haven't seen this earlier)

người chơi gôn484

Trong vũ trụ nào Mongodb có thể được gọi là Object DB? . Đó 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. This solution is also scalable - J2SE has supported clustering for nearly two decades now. 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

Rumana Amin

Hi Tomislav, your article is really nice and informative. Nó đã giúp tôi rất nhiều để hiểu về Node. js and it's uses

Rumana Amin

Hi Tomislav, your article is really nice and informative. Nó đã giúp tôi rất nhiều để hiểu về Node. js and it's uses

đại bàng chiến tranh

The simple answer is do not use Node. js cho điều đó. Bạn đang thiếu phần nào trong đó? . dễ dàng. 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

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 đ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ị. Does his knowledge not extend to understand the concept of connection "keep alives". 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 and I'm sure . 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 đúng 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 xoắn . 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

It sounds like the node. js people think that JS is the only language that supports concurrency (although they promote a single threaded web server solution -WTF?) and non blocking I/O - of course it's not that case but you seem so excited about such things that I can only assume you have just discovered concepts that have existed in other languages for 2 decades or more

người chơi gôn484

Tomislav Capan

Tất nhiên bạn hiểu đây là hình minh họa. In practice, it's a thread pool, which is limited by memory available, and is magnitudes of order less than what an event look can support. Cảm ơn vì nhận xét, mặc dù

Tomislav Capan

Dean 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. In light of these original intentions of node to do awesome things like queued db writes, and server-push, it's surprising how most node apps today are still built on the request/response model and synchronously (but non-blockingly) waiting on db writes

Dean Radcliffe

Ulyana

Nội thất tuyệt vời, cảm ơn vì bài viết. Nút. js do has plenty of advantages. 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 Your opinion would be appreciated a lot

Ulyana

Maq Said

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

Maq Said

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

Misha Kov

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

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

Jessica Barnes

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

Jessica Barnes

Janguk James Lee

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

Janguk James Lee

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

Magdalena Mbn

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

Magdalena Mbn

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

web đặt hàng

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

web đặt hàng

philippe

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

philippe

Cody Donelson

Sự kiện mặc dù bài viết đã được vài năm nhưng nó đưa ra một số điểm tuyệt vời về Node. js. Đọc qua các bình luận, tôi đã thấy một số bài đăng về cách Node. js là một điều tuyệt vời và những 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. I find it easier to use objects and I can use them more dynamically BECAUSE of 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

Gage Poon

Nhanh như chớp, nhẹ, phát triển mượt mà và hiệu suất tốt hơn, đây là một số thay đổi mang tính cách mạng do Node js mang lại trong lĩnh vực phát triển web. Node js mang đến sự tự do sáng tạo, nguồn tài nguyên phong phú như NPM (Trình quản lý gói nút), là thư viện chia sẻ các mô-đun và công cụ. Ngoài ra, các ứng dụng web được phát triển bằng khung phát triển web này có khả năng mở rộng hơn. 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

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. I was able to recover the majority of the funds, and we are still attempting to recover the rest. 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