Mọi ứng dụng bạn dùng thực ra chỉ là một cuộc hội thoại

Mỗi ngày bạn dùng hàng chục ứng dụng khác nhau. Mỗi ứng dụng đều đang có một cuộc trò chuyện mà bạn không nghe thấy.

Điện thoại bạn hỏi server về bảng tin. Server kiểm tra cơ sở dữ liệu, gom dữ liệu lại, rồi gửi về. Điện thoại hiển thị lên màn hình. Tất cả diễn ra trong tích tắc, và bạn chẳng bao giờ nghĩ về nó — giống như bạn không nghĩ về hệ thống điện mỗi lần bật công tắc đèn.

Khi bạn hiểu được hình dạng của cuộc hội thoại đó, phần lớn công nghệ hiện đại bỗng dưng không còn bí ẩn nữa.

Đó là điều mình mới nhận ra gần đây. Không phải công cụ hay ngôn ngữ cụ thể nào, mà là các mô hình. Cùng một vài mô hình xuất hiện đi xuất hiện lại — trong web app, mobile app, thiết bị thông minh, trợ lý giọng nói. Và điều giúp mình thật sự hiểu chúng là nhận ra rằng những mô hình này cũng tồn tại trong nhà hàng, nhà bếp, chung cư, và quán cà phê.

Nhà hàng chính là hệ thống client-server

Khi bạn bước vào nhà hàng, bạn ngồi xuống. Xem menu. Gọi món cho người phục vụ. Người phục vụ đi vào bếp, chuyển đơn, bếp nấu xong, rồi người phục vụ mang ra cho bạn.

Đó chính là client-server.

Bạn là client. Nhà bếp là server. Người phục vụ là mạng lưới. Menu là giao diện.

Mọi ứng dụng trên điện thoại bạn đều theo đúng mô hình này. Bạn chạm vào gì đó (request). Một thứ gì đó xử lý (server logic). Dữ liệu quay về (response). Netflix, Grab, ứng dụng ngân hàng — tất cả đều vậy.

Web không phát minh ra mô hình này đâu. Nhà hàng, thư viện, bưu điện — họ đã làm request/response từ hàng trăm năm rồi. Phần mềm hiện đại chỉ khiến nó chạy nhanh như ánh sáng thôi.

Và đây là phần khiến mình thay đổi góc nhìn: server có thể trả về hai thứ rất khác nhau. Nó có thể đưa cho bạn một món ăn hoàn chỉnh — trang web đầy đủ với mọi thành phần trực quan. Hoặc nó có thể đưa nguyên liệu thô — chỉ dữ liệu, để client tự quyết định cách trình bày.

Cái thứ hai — dữ liệu thô — chính là thứ tạo nên mobile app, thiết bị thông minh, và trợ lý giọng nói. Alexa không cần trang web. Nó cần dữ liệu để đọc thành tiếng. Đồng hồ thông minh không cần HTML. Nó cần con số để hiển thị trên màn hình bé tí.

Cùng một nhà bếp. Khác nhau ở cách bày đĩa.

Bốn hành động vận hành gần như mọi thứ

Ở nhà hàng, bạn thực ra chỉ làm mấy việc với đơn gọi món. Gọi món mới, hỏi có gì, đổi món, hoặc hủy.

Giao thức chạy web cũng y hệt. Nó có bốn hành động chính:

Nghĩ về bất động sản:

• GET: lướt xem tin đăng trên Batdongsan.com — bạn đang hỏi thông tin có sẵn
• POST: gửi đề nghị mua nhà — bạn đang tạo một bản ghi mới
• PUT: cập nhật giá đề nghị vì có người trả cao hơn — bạn đang sửa thứ đã có
• DELETE: rút đề nghị hoàn toàn — bạn đang xóa nó đi

Hoặc nghĩ về danh bạ điện thoại. Bạn tìm ai đó (GET). Thêm liên hệ mới (POST). Cập nhật số điện thoại khi họ đổi mạng (PUT). Hết học kỳ, bạn xóa cái bạn cùng nhóm mà chẳng bao giờ nói chuyện lại (DELETE).

Phần lớn phần mềm hiện đại chỉ là bốn thao tác này áp dụng lên các loại dữ liệu khác nhau. Giống như khi bạn biết mọi câu đều có chủ ngữ và vị ngữ — hiểu cấu trúc rồi thì mọi thứ phức tạp trở nên dễ tiếp cận hơn nhiều.

Routing là quầy lễ tân tòa nhà

Tưởng tượng bạn bước vào một tòa nhà văn phòng lớn. Bạn nói với lễ tân: "Tôi đến gặp bác sĩ Kim ở khoa tim mạch, tầng 4."

Lễ tân không khám tim cho bạn. Họ kiểm tra danh mục rồi chỉ bạn đến đúng nơi.

Đó là routing. Khi một request đến server, cần có thứ gì đó nhìn vào yêu cầu và quyết định: đoạn code nào sẽ xử lý cái này?

Giống tổng đài điện thoại ngày xưa. Cuộc gọi đến, người trực nhìn số, rồi nối đúng đường dây. Họ không tham gia cuộc trò chuyện. Họ chỉ kết nối người gọi đến đúng đích.

Còn nếu bạn hỏi thứ không tồn tại? Bạn nhận được câu "xin lỗi, ở đây không có ai tên đó." Trong web, đó là lỗi 404 — server nói "tôi tìm khắp nơi rồi, không có thứ bạn yêu cầu."

Mã 404 thực ra chỉ là con số ai đó chọn cách đây mấy chục năm.

• 200 nghĩa là "mọi thứ ổn."
• 404 nghĩa là "không tìm thấy."
• 500 nghĩa là "phía tôi bị lỗi, xin lỗi."

Có cả một bảng mã phản hồi như vậy, hoạt động giống như cập nhật trạng thái chuẩn hóa. Server không cần giải thích dài dòng. Gửi một con số, ai cũng hiểu nó nghĩa là gì.

Port là số căn hộ

Khi bạn gửi thư, địa chỉ đường phố đưa bạn đến tòa nhà. Nhưng số căn hộ mới đưa bạn đến đúng cửa.

Trong mạng máy tính, địa chỉ IP là địa chỉ đường phố. Port là số căn hộ.

Máy tính bạn có hàng ngàn port. Mỗi dịch vụ lắng nghe ở port khác nhau. Khi trình duyệt vào google.com, thực ra nó đang nói chuyện với port 443 — chuẩn cho web bảo mật. Bạn chỉ không thấy vì trình duyệt tự thêm, giống như bạn không ghi "Hành tinh Trái Đất" cuối mỗi địa chỉ gửi thư.

Khi lập trình viên đang xây dựng gì đó trên máy, họ thường thấy port 8000 hay 3000. Đó là số căn hộ của server phát triển. Và nếu bạn cố chạy hai server trên cùng một port? Giống hai người thuê cùng muốn dọn vào một căn hộ. Ai đó sẽ nhận thông báo lỗi xung đột.

Còn có một địa chỉ đặc biệt khiến nhiều người bối rối lúc đầu: 127.0.0.1, hay còn gọi là localhost. Nó giống như nói chuyện với chính mình. Máy tính gửi request, rồi chính lớp mạng của nó bắt lại và chuyển ngược về. Không cần internet.

Đây là cách lập trình viên test mọi thứ trước khi triển khai ra thế giới thực. Trình duyệt (client) và server đều chạy trên cùng một máy, nói chuyện với nhau qua localhost. Lúc đầu thấy kỳ kỳ — như vừa là nhà hàng vừa là khách — nhưng hoàn toàn hợp lý khi bạn nghĩ "client" và "server" là vai trò, không phải máy vật lý.

JSON là tờ phiếu gọi món chuẩn hóa

Khi nhà bếp nhận đơn, sẽ dễ hơn nhiều nếu phiếu theo đúng format. Không phải một đoạn văn dài về mối quan hệ của bạn với món bò bít tết, mà là form có cấu trúc: món, số lượng, yêu cầu đặc biệt, số bàn.

JSON (JavaScript Object Notation) chính là tờ phiếu gọi món của thế giới số. Nó là cách cấu trúc dữ liệu sao cho cả người lẫn máy đều đọc được.

Chỉ là cặp key-value bọc trong ngoặc nhọn: {"name": "Anh", "order": "mi_y", "them_pho_mai": true}

Nếu bạn từng thấy dictionary trong Python, nó trông gần như giống hệt — vì Python mượn format này một cách có chủ đích. Hầu như mọi dịch vụ hiện đại đều nói JSON. Nó là ngôn ngữ chung giữa nhà bếp và phòng ăn, giữa server và client, giữa điện thoại bạn và đám mây.

JSON thắng các format khác vì nó đơn giản đến khó tin. Nhìn vào một JSON object là hiểu ngay nó nói gì. Không cần giải mã gì phức tạp cả.

Nấu nhiều món cùng lúc chính là lập trình bất đồng bộ

Đây là phần thật sự thú vị — và cũng là nơi trực giác của hầu hết mọi người bị đánh lừa.

Nếu bạn nấu bữa tối mà làm từng thứ một — luộc mì, chờ xong hẳn, rồi mới bắt đầu sốt, chờ tiếp, rồi mới cắt salad — bữa tối sẽ mất cả tiếng rưỡi. Đó là thực thi đồng bộ (synchronous). Từng việc một, theo đúng thứ tự.

Nhưng đầu bếp thực thụ không ai làm vậy. Bạn cho mì vào nồi và trong khi nó luộc, bạn bắt đầu làm sốt. Trong khi sốt đang sôi liu riu, bạn cắt salad. Nhiều thứ chạy song song, và bạn kiểm tra từng thứ khi nó xong.

Đó là lập trình bất đồng bộ (asynchronous). Bạn khởi động một tác vụ, và thay vì đứng nhìn nồi nước sôi, bạn đi làm việc khác có ích. Khi tác vụ hoàn thành, bạn quay lại xử lý kết quả.

Điều này cực kỳ quan trọng trong phần mềm vì request qua mạng rất chậm. Nếu app bạn đứng hình mỗi lần hỏi server dữ liệu — nếu nó cứ đứng nhìn nồi mì — trải nghiệm sẽ tệ không tưởng. Thay vào đó, app gửi request rồi tiếp tục chạy. Khi dữ liệu về, nó xử lý.

Cái bẫy mà ai cũng vấp

Cái khó — và điều này thật sự khiến ai lần đầu cũng bối rối — là bạn không thể giả định dữ liệu đã sẵn sàng chỉ vì dòng code tiếp theo đã chạy.

Trong code đồng bộ, dòng 2 chạy sau khi dòng 1 xong. Chắc chắn.

Trong code bất đồng bộ, dòng 2 có thể chạy trước khi dòng 1 trả về kết quả.

Giống như giả định mì đã chín chỉ vì bạn cắt salad xong rồi. Bạn cho mì luộc trước, đúng. Nhưng cắt salad nhanh hơn mà.

Khi biết trước điều này sẽ xảy ra, bạn có thể lập trình để xử lý nó. Nhưng nếu không ai cảnh báo, bạn sẽ tưởng máy tính bị hỏng. Nó không hỏng đâu. Nó chỉ đang nấu nhiều món cùng lúc, và bạn tưởng một món đã xong trước khi nó thật sự xong.

"Sẽ gọi tên bạn khi xong" — đó là promise

Một số quán cà phê nhận đơn rồi đưa cho bạn cái chuông rung. "Chuông kêu là đến lấy nha." Bạn không đứng chắn quầy cho mọi người phía sau chờ. Bạn đi ngồi xuống, lướt điện thoại, làm gì tùy thích. Khi chuông rung, bạn đến lấy đồ uống.

Trong lập trình, cái chuông rung đó gọi là Promise. Và từ khóa .then() là bạn nói: "khi xong rồi, thì làm cái này với nó."

Mô hình trông như thế này:

1. Yêu cầu thứ gì đó (gọi món)
2. Nhận promise về (nhận chuông rung)
3. Tiếp tục làm việc khác (ngồi xuống, lướt điện thoại)
4. Khi kết quả đến, thì xử lý (chuông rung, đi lấy đồ uống)

Cái hay của mô hình này là app không bao giờ đứng hình. Nó gọi món, tiếp tục công việc, và xử lý kết quả bất cứ khi nào nó đến. Đó là lý do app hiện đại vẫn mượt mà dù đang nói chuyện với server ở phía bên kia trái đất.

Và bạn có thể nối promise lại: thì làm cái này, thì làm cái kia. Như: khi cà phê xong, thì cho đường, thì nhấp một ngụm. Mỗi bước chờ bước trước, nhưng phần còn lại của thế giới vẫn tiếp tục chạy.

Thread là nhân viên bếp

Khi nhà hàng đông khách, một đầu bếp không thể lo hết mọi thứ. Nên bạn thêm đầu bếp. Mỗi người làm món riêng, chia sẻ cùng nhà bếp, cùng nguyên liệu, cùng dụng cụ.

Đó là sự khác biệt giữa process và thread trong máy tính.

Process giống cả một nhà hàng — có không gian riêng, nhân viên riêng, mọi thứ riêng. Nặng để khởi động, tốn tài nguyên. Khi bạn nhấp đúp mở app trên máy tính, bạn đang khởi tạo một process mới.

Thread giống một đầu bếp trong nhà hàng đó — nhẹ, chia sẻ tài nguyên với các đầu bếp khác, và có thể thêm nhanh khi bận rộn.

Trình duyệt, web server, database — tất cả đều dùng nhiều thread để xử lý nhiều request cùng lúc. Đó là lý do bạn mở 20 tab mà tất cả đều load đồng thời. Mỗi tab được phân một thread riêng (đại khái vậy), chia sẻ chung process của trình duyệt.

Nhưng chia sẻ tài nguyên cũng có mặt trái. Hai đầu bếp cùng với lấy một con dao thì sinh ra xung đột. Trong lập trình, cái này gọi là race condition — hai thread cùng cố đọc hoặc sửa một dữ liệu. Quản lý điều này là một trong những phần thật sự khó của lập trình đa luồng. Nhưng khái niệm thì sao? Hai đầu bếp, một con dao. Bạn đã hiểu rồi đấy.

Mọi thứ đều theo sự kiện — kể cả bưng bê

Thêm một quan sát từ nhà hàng mà ánh xạ hoàn hảo sang phần mềm.

Người phục vụ giỏi không liên tục đi đến từng bàn hỏi "bạn sẵn sàng gọi món chưa?" Như vậy vừa phiền vừa kém hiệu quả. Thay vào đó, họ quan sát tín hiệu. Khách đặt menu xuống — đó là sự kiện. Người phục vụ phản hồi.

Đó là lập trình hướng sự kiện (event-driven). Thay vì liên tục kiểm tra "có gì xảy ra chưa?", hệ thống ngồi chờ và phản ứng khi có gì đó xảy ra. Một cú click, một phím bấm, phản hồi từ mạng, bộ đếm thời gian kêu — tất cả đều là sự kiện.

Hệ điều hành bạn dùng hoạt động kiểu này. Nó không điên cuồng kiểm tra mỗi mili giây xem bạn có di chuột không. Nó chờ. Khi bạn di chuột, sự kiện được phát ra, và hệ điều hành phản hồi. Hiệu quả, nhanh nhạy, và mở rộng được.

Kết hợp lập trình bất đồng bộ với thiết kế hướng sự kiện, bạn được hệ thống xử lý hàng ngàn người dùng cùng lúc mà không đổ mồ hôi. Nhà bếp không nấu từng đơn một, và người phục vụ không đứng chết dí ở một bàn cho đến khi khách rời đi. Mọi thứ chảy mượt.

Sao điều này lại liên quan đến việc xây dựng sản phẩm

Tất cả có vẻ thuần kỹ thuật. Nhưng đây là lý do nó cứ kéo mình quay lại với tư duy sản phẩm.

Nếu bạn đang xây thứ gì đó cho người dùng thật, những mô hình này trực tiếp định hình trải nghiệm:

• Thời gian phản hồi là tốc độ phục vụ. Server chậm giống nhà hàng phục vụ chậm — khách sẽ bỏ đi. Nghiên cứu cho thấy chỉ cần chậm 100 mili giây cũng giảm tỷ lệ chuyển đổi.
• Routing tốt là menu rõ ràng. API sạch thì dễ sử dụng và khó dùng sai. API lộn xộn tạo ra nhầm lẫn và bug.
• Thiết kế async quyết định app bạn có cảm giác sống động hay đông cứng. Không ai muốn nhìn vòng xoay loading trong khi cả màn hình bị khóa.
• Thread và concurrency quyết định nhà hàng bạn phục vụ được bao nhiêu khách cùng lúc. Mở rộng không chỉ là bếp to hơn — mà là các đầu bếp phối hợp hiệu quả ra sao.

Kỹ sư nào hiểu cả giá trị sản phẩm lẫn kiến trúc kỹ thuật — người nghĩ về trải nghiệm khách hàng đồng thời với thiết kế hệ thống — đó mới là người xây được thứ thật sự chạy tốt. Không chỉ đúng về mặt kỹ thuật, mà thật sự dễ chịu khi sử dụng.

Hiểu cách nhà bếp hoạt động không biến bạn thành đầu bếp. Nhưng nó giúp bạn trở thành chủ nhà hàng giỏi hơn rất nhiều.

Một vài điều mình rút ra được

• Client-server không phải khái niệm chỉ dành cho web — nó là mô hình giao tiếp xuất hiện ở nhà hàng, thư viện, bưu điện, bất cứ đâu có người hỏi và người đáp
• Hầu như mọi thứ trong thế giới số đều gói gọn trong bốn thao tác: đọc, tạo, sửa, xóa — giống hệt thao tác bạn làm với danh bạ hay tin đăng bất động sản
• Routing chỉ là quầy lễ tân — nhận request đến, chuyển đúng nơi xử lý, rồi để nơi đó làm việc thật sự
• Port là số căn hộ trên máy tính — mỗi dịch vụ ở một port khác nhau, và hai dịch vụ không thể chia sẻ cùng một port
• Lập trình bất đồng bộ giống nấu nhiều món cùng lúc — cái khó không phải khái niệm, mà là nhớ rằng mì chưa chắc đã chín chỉ vì bạn cắt salad xong rồi
• Promise giống chuông rung ở quán cà phê — "cứ đi làm việc khác, khi nào xong sẽ báo"
• Thread cho phép hệ thống xử lý nhiều thứ cùng lúc, như nhiều đầu bếp chia sẻ một nhà bếp — mạnh mẽ nhưng tài nguyên chung tạo ra thách thức phối hợp thật sự
• Hệ thống hướng sự kiện không liên tục kiểm tra — chúng chờ tín hiệu, giống người phục vụ giỏi quan sát thay vì cứ 30 giây lại hỏi một lần
• Khi phát triển phần mềm, máy tính bạn đóng cả vai client lẫn server trên cùng một máy — lúc đầu hơi rối nhưng hoàn toàn hợp lý khi hiểu đây là vai trò, không phải vị trí vật lý
• Kỹ sư nào kết nối được tư duy sản phẩm với thiết kế hệ thống mới là người xây được thứ mà mọi người thật sự muốn dùng

Điều cuối cùng đó là nơi tất cả đổ về. Bạn có thể hiểu mọi giao thức, mọi mô hình, mọi khái niệm kiến trúc một cách riêng lẻ. Nhưng kỹ năng thật sự là kết nối nhà bếp với phòng ăn — hiểu hệ thống bạn đang xây sẽ chuyển thành trải nghiệm gì cho người dùng. Và thật lòng, đó là kiểu tư duy tích lũy theo thời gian, lâu dài hơn bất kỳ công cụ hay framework cụ thể nào.

Nguồn tham khảo

• HTTP Status Codes (MDN Web Docs) — bảng đầy đủ các mã trạng thái HTTP
• JSON specification (json.org) — đặc tả gốc cho JavaScript Object Notation
• Asynchronous Programming (MDN Web Docs) — hướng dẫn toàn diện về khái niệm async và promise
• Concurrency vs Parallelism (Rob Pike) — bài nói kinh điển phân biệt hai khái niệm