Node.js và ES6 đã thay thế Java ở mobile.de như thế nào?

Tác giả Patrick Hund, bài viết nguyên gốc: Node.js and ES6 Instead of Java – A War Story 

Chúng tôi đã tạo ứng dụng web Node.js từ đầu trong vòng 9 tuần và giờ nó phục vụ 10.81 triệu lượt khách hàng tháng.  Chúng tôi sử dụng chuẩn JavaScript mới nhất là ECMAScript 6 cho cả back end và front end. Trải qua nhiều đêm mất ngủ giải quyết không biết bao nhiêu vấn đề phát sinh, lúc phấn khích, khi thì chán nản WTF (What The F*ck, cái con tiều gì thế này?), đạt đến độ cao chóng mặt của lập trình bất đồng bộ (Asynchronicity). Và đây là câu chuyện tôi muốn chia sẻ cho các bạn:

Tôi là Patric, kỹ sư phần mềm tại Mobile.de, công ty con của Ebay. Mobile.de là một trang bán xe ô tô, xe máy, xe tải... trực tuyến lớn nhất Đức. Theo thống kê từ SimilarWeb, số lượng truy cập mobile.de khoảng 35 triệu, so với vnexpress.net là 93 triệu.

Vào tháng 6/2015, chúng tôi nhận được nhiệm vụ mà lập trình viên nào cũng mơ ước đó là vứt bỏ toàn bộ web site cũ, viết lại toàn bộ từ đầu. Site cũ ở đây là trang web mobile.de, cổng chính kết nối xuống toàn bộ hệ thống dịch vụ của công ty.

Mobile.de trước đây...

...và sau khi viết lại

Tại sao là Node.js?

Hệ thống cũ được viết bằng Java sau khi chuyển đổi từ Perl từ năm 2007. Kỹ sư ở mobile.de được khuyến khích tìm hiểu công nghệ mới, chọn lựa công cụ tốt nhất, phù hợp nhất với công việc và đội ngũ hiện thời.

Kiến trúc hệ thống tiến hóa từ một khối đơn nhất (monolithic) đến mô hình hướng dịch vụ vào năm ngoái. Trang chủ trở thành một ứng dụng web ít nặng nề hơn, căn bản nó chỉ là một lớp mỏng (thin layer) đứng giữa các API dịch vụ và mã nguồn front end (HTML, CSS, JavaScript).

Node.js rất tuyệt trong việc tích hợp dịch vụ, truyền dữ liệu từ back end đến tầng giao diện.

Hạn giao sản phẩm hết sức ngặt nghèo. Bộ mặt mới của mobile.de cần phải ra mắt ngày 1 tháng 9 2015. Vỏn vẹn 9 tuần để thực hiện.

Học "Xây dựng web site tốc độ cao bằng Node.js" được học miễn phí khóa "HTML5, CSS3, JavaScript"

Tại lúc bắt đầu, đội có 4 chuyên gia JavaScript trong đó có tôi và 2 chuyên gia Java, một người đang trong kỳ nghỉ đến giữa dự án. Sau khi thử nghiệm với framework Paypal là Kraken.js, tôi đã tự tin rằng có thể tận dụng nó để đạt tiến độ hơn là dùng lại công nghệ Spring/Java hiện có. (Tôi sẽ nói ở sau hóa ra dùng Kraken không phải là ý tưởng tốt).

Điều khiến ban giám đốc lo lắng nhất đó là độ ổn định của hệ thống, khả năng mở rộng và giám sát. Chúng tôi đã thử mọi cách để đạt được các yêu cầu này. Đồng đội Jonathan Krause sẽ chia sẻ thêm ở những bài sau. Tại sao JavaScript là lựa chọn tốt với back end và front end, các bạn có thể đọc thêm bài viết này của Eric Elliot, How to Build a High Velocity Development Team , phần "Why Language Matters".

Cấu hình hệ thống xây dựng

Hệ thống còn cơ chế khởi động lại (hot reload) khi mã nguồn thay đổi. Mọi thứ đều sẵn có, quá tuyệt để bắt đầu.

Tiếc là tôi chọn Kraken với niềm tin khá ngây thơ. Framework này đã không được cập nhật từ tháng 4/2015(v2.0.0-rc1). Phiên bản mới 2.x vẫn chưa ra mắt tại thời điểm tôi viết bài này, tháng 10, 2015.

Do đó phải chọn trong các lựa chọn:
1- Sử dụng bản cũ 1.x, nhưng ổn định
2- Sử dụng Kraken 2 mới nhưng chưa ổn định
3- Không sử dụng toàn bộ Kraken framework mà chỉ từng module, chủ động xây dựng hệ thống theo nhu cầu của nhóm

Anh em trong đội muốn dùng bản mới nhất, tốt nhất, thử nghiệm những tính năng cool nhất, không nề hà lo ngại hạn chót cận kề. Do đó tôi quyết giải pháp cuối.

Lý do cho quyết định này:
1- Tôi không muốn rủi ro khi dùng module cũ có khiêm khuyết cho dù framework Kraken được viết bởi đồng nghiệp Paypal đáng nể.
2- Tôi muốn dùng bản mới nhất của JavaScript ES6 ở cả back end lẫn front end. Điều này buộc phải sửa đổi code hiện thời của Kraken rất nhiều.
3- Tôi muốn dùng webpack để tối ưu và gom các tài nguyên CSS, JavaScript, ảnh. Web pack chứng minh hiệu quả tuyệt vời của nó từ dự án trước đó.

webpack, tốt cho front end, bổ cho cả back end?

Trong lúc tìm hiểu, tôi có tìm được một số bài viết của lập trình viên Mozilla James Long, Backend Apps với webpack.

James thử nghiệm khả năng sử dụng webpack không chỉ gom, tối ưu JavaScript, CSS ở phía client mà cả JavaScript code ở back end chạy trên Node.js

Tôi cấu hình hệ thống build theo bài viết của James: npm run-script sẽ chạy tác vụ Gulp gọi webpack để gom, tối ưu code JavaScript back end rồi chạy.

Tuy nhiên webpack cho back end vẫn ở giai đoạn thử nghiệm và nó chưa khả thi khi vận hành hệ thống lâu dài. Quản lý một hệ thống build phức tạp, gom, tối ưu mã đôi khi phải trả giá đắt cho lợi thế về tốc độ so với lợi thế đơn giản, dễ bảo trì. Do đó tôi quay lại chỉ dùng webpack cho front end.  Tưởng gì thế mà cũng phải khoe !@

Tự động hóa việc build hệ thống với Gulp
Trước đó chúng tôi đã dùng Grunt làm công cụ để build front end cho tất cả các dự án. Glup là lựa chọn rất hay, bởi nó dùng API streaming của Node.js cho phép nối chuỗi các tác vụ với nhau kiểu như nối ống nước vậy (pipe, chú thích người dịch).

Theo suy luận kỹ thuật, tôi thích Gulp hơn Grunt, nhưng kinh nghiệm với hạn chót phát hành sản phẩm khiến tôi vẫn phải dùng Grunt bởi chúng tôi đã quen với Grunt. Glup streaming API không dễ học.

Ngoài ra một số plugin của Glup đã không chạy hoàn hảo 100% trong hệ thống Jenkins Continuous Integration, dẫn đến treo khi build sản phẩm cuối. Chúng tôi đã phải mày mò chỉnh lại tác vụ Glup chạy tuần tự. Đây là điểm trừ cho Glup bởi Grunt có thể chạy song song các tác vụ.

Demo: lập trình trong môi trường nội bộ
Video dưới ghi lại lập trình Node.js với hệ thống build tiện lợi như thế nào.

Tôi thực sự thích khả năng tải lại tức của web pack dev server cho phép tôi thay đổi Less style sheet và JavaScript client-side mà không phải ấn nút reload của trình duyệt.

Nhờ có sourcemaps, tôi có thể soi CSS, JavaScript code trên trình duyệt để thấy được ánh xạ về mã ES6 và Less gốc ban đầu.

Khi tôi code ở backend, tôi sử dụng tool là nodemon để phát hiện thay đổi mã JavaScript, tự động khởi động lại ứng dụng trong vòng 200-400 mili giây. So sánh với ứng dụng Java, khi biên dịch và khởi động lại cảm giác thời gian như ngừng trôi.... Tuyệt phải không?

Tiếp theo sẽ là...
- Phần 2: Ứng dụng thực tế của ES6, làm việc với Dust template, kiến trúc MVC với Express, unit test (kiểm thử tự động từng khối) bằng Mocha, Chai và Sinon

- Phần 3: Kinh nghiệm có được khi phát triển ứng dụng Node.js từ đầu trong 9 tuần. <Dev Đức code tởm thật !@>