Những điều nên tránh khi build NodeJS

Bài viết này sẽ nói cho bạn biết về những điều không nên làm khi chạy một ứng dụng NodeJS trong thực tế. Cùng lướt qua ngay nào.


1043

Không sử dụng NodeJS Cluster

NodeJS là một luồng duy nhất trong tự nhiên và giới hạn bộ nhớ 1.5GB. Vì thế, nó không thể tự động tận dụng nhiều lõi CPU. Nhưng Cluster cho phép tạo nhiều tiến trình con (fork) sử dụng IPC để giao tiếp với tiến trình mẹ. Quy trình tổng thể kiểm soát các nhân viên (hay còn gọi là tiến trình con) và tất cả các kết nối được phân phối theo kiểu luân chuyển vòng robin (round-robin).

NodeJS

Clustering nâng cao hiệu suất ứng dụng cho phép giảm thời gian dừng khi triển khai xuống 0 dễ dàng. Bên cạnh đó, số lượng tiến trình con có thể được tạo ra mà không bị giới hạn bởi số lõi CPU của máy.

Xử lý các tác vụ nặng trên Web Server

NodeJS

Node/Express server không phù hợp để xử lý các tác vụ nặng và yêu cầu tính toán nhiều. Ví dụ, một ứng dụng web đơn giản cần gửi một loạt email cho người dùng. Mặc dù bạn thực hiện công việc này trong NodeJS web server nhưng nó sẽ ảnh hưởng đáng kể tới hiệu suất. Nên tách các tác vụ nặng thành những kiến trúc microservices và triển khai thành các ứng dụng riêng biệt. Bạn có thể sử dụng message queue như RabbitMQ để giao tiếp giữa các kiến trúc micro services.

Vì vậy, điều quan trọng chúng ta nên nhớ là NodeJS phù hợp khi xử lý các sự kiện và non-blocking I/O. Bất cứ tác vụ nào cũng có thể gây tốn thời gian hoàn thành nên được xử lý bởi một tiến trình riêng biệt.

Không sử dụng công cụ quản lý tiến trình

Rõ ràng công cụ quản lý tiến trình mang lại nhiều lợi ích nhưng đa phần các lập trình viên lần đầu triển khai ứng dụng của họ trên thực tế không sử dụng nó. Ở Hashnode, chúng tôi sử dụng pm2, một công cụ quản lý mạnh cho ứng dụng NodeJS.

Hơn nữa, nếu sử dụng pm2 bạn có thể dễ dàng bắt đầu chạy ứng dụng của mình trong chế độ cluster.

pm2 start app.js -i 2

Trong câu lệnh ở ví dụ trên, i là số lượng tiến trình con mà ta muốn tạo trong chế độ cluster. Điều tuyệt vời nhất chính là bạn có thể chạy lại lần lượt từng tiến trình con mà không làm ảnh hưởng đến nhau. Vì thế, ứng dụng không phải lãng phí khoảng thời gian chết khi triển khai. Lệnh dưới đây sẽ chạy lại ứng dụng:

pm2 reload app

Nếu bạn sử dụng pm2, hãy tham khảo Keymetrics, một dịch vụ giám sát ứng dụng NodeJS (dựa trên pm2).

Không sử dụng reverse proxy

NodeJS

Tôi đã thấy các lập trình viên chạy ứng dụng Node trên cổng 80 và cung cấp tài nguyên tĩnh thẳng qua cổng này. Bạn nên nhớ rằng chạy ứng dụng Node trên cổng 80 không phải là ý tưởng hay và thực tế nó nguy hiểm trong phần lớn các trường hợp. Thay vào đó, bạn nên chạy trên một cổng khác như cổng 3000 và sử dụng nginx (hay cái gì đó như HAProxy?) như một reverse proxy đứng trước ứng dụng NodeJS.

Cấu hình trên bảo vệ ứng dụng của bạn không tiếp xúc trực tiếp với lưu lượng truy cập Internet, mở rộng server và cân bằng tải yêu cầu dễ dàng hơn.

Thiếu sự giám sát

Những thứ tệ hại như lỗi không mong muốn, các trường hợp ngoại lệ xảy ra thường xuyên. Bạn biết điều tệ hơn là gì không? Đó chính là không biết lỗi nào xảy ra trong hệ thống. Khi sử dụng công cụ quản lý tiến trình, mỗi lần tiến trình được khởi động lại sẽ xuất hiện một lỗi không được xử lý.

Vì thế, trừ khi bạn kiểm tra logs, bạn sẽ biết vấn đề nào đã xảy ra. Giải pháp là sử dụng service giám sát hoặc thông báo qua email khi tiến trình “ngưng”, khởi động lại.

Tham khảo : Logs NodeJS là gì ? Và tại sao nên dùng ?

Không xóa câu lệnh console.log

Không xóa câu lệnh console.log

Khi phát triển ứng dụng, chúng ta sử dụng console.log để kiểm tra mọi thứ. Đôi khi chúng ta lại quên xóa những câu lệnh này gây tốn thời gian CPU và tài nguyên. Cách tốt nhất để tránh chuyện này là sử dụng môđun debug (gỡ lỗi). Do đó, trừ khi bạn chạy ứng dụng trong môi trường DEBUG, các câu lệnh console.log sẽ được in ra.

Tham khảo : Từng bước debug NodeJs trong Docker không dùng console.log

Duy trì trạng thái Global bên trong các quy trình web NodeJS

Đôi khi, các lập trình viên lưu trữ giá trị session ids, socket connections,… trong bộ nhớ. Việc này hoàn toàn không nên và cần tránh bằng bất kỳ giá nào. Nếu bạn lưu session ids trong bộ nhớ, bạn sẽ thấy người dùng bị đăng xuất ngay mỗi lần server khởi động lại. Việc này cũng dẫn đến khó khăn và vấn đề khi mở rộng ứng dụng, làm tăng thêm servers. Webserver chỉ xử lý các request, truy cập qua lại trên web không lưu trữ bất cứ thông tin.

Không dùng SSL

SSL

Với một trang web dành cho người dùng, không có lý do gì để không mặc định dùng SSL. Đôi khi, dev đọc keySSL từ một file và sử dụng nó trong tiến trình Node. Bạn nên sử dụng reverse proxy trước ứng dụng NodeJS và cài đặt SSL ở reverse proxy.

Hãy thường xuyên kiểm tra những điểm yếu mới nhất của SSL. Và áp dụng biện pháp xử lý nhanh nhất có thể.

Thiếu các biện pháp bảo mật cơ bản NodeJS

Bảo mật luôn quan trọng và người dùng lo lắng đến vấn đề bảo mật là một điều tốt. Bên cạnh việc kiểm tra bảo mật cơ bản, nên sử dụng những thứ như NSP để phát hiện các điểm yếu trong dự án.

Đừng sử dụng bản quá cũ của NodeJS và Express. Loại bỏ ngay những bản không còn được bảo trì và nâng cấp về bảo mật.

Tham khảo thêm : 19 bí mật để trở thành dev NodeJS xịn xò 2020 – phần 1

Không sử dụng VPN

VPN

Luôn upload ứng dụng trên mạng lưới riêng tư để chỉ có những khách hàng đáng tin cậy mới có thể giao tiếp với máy chủ của bạn. Mọi người thường quên đi điều đơn giản này khi triển khai và gặp phải nhiều vấn đề sau đó. Trước khi tải ứng dụng lên mạng, bạn cần nghĩ đến kiến trúc và nền tảng cơ sở vật chất.

Ví dụ, nếu máy chủ NodeJS của bạn chạy trên cổng 8080 và đã thiết lập cấu hình nginx làm revers proxy, điều quan trọng bạn nên đảm bảo rằng chỉ có nginx có thể giao tiếp với server tại cổng này. Cổng này nên được cô lập hoàn toàn và không bị truy cập bởi những thứ khác trên mạng.

Kết luận

Trên đây là những lỗi thường gặp khi viết project, app NodeJS. Hãy tránh những lỗi này để có được project, app NodeJS nhanh, mạnh.

Tham khảo thêm về NodeJS: Sai lầm phổ biến khi học NodeJS hay mắc phải


Like it? Share with your friends!

1043