- Có quan niệm khá phổ biến rằng nền tảng web hoạt động thống nhất trên các API được tiêu chuẩn hóa, nhưng trên thực tế lại tồn tại rất nhiều API phụ thuộc vào hạ tầng riêng của từng nhà cung cấp trình duyệt
- Geolocation, Speech, Push, Payments, Passkeys... bề ngoài là tiêu chuẩn web, nhưng bên trong lại gọi tới các dịch vụ của Google, Apple và Microsoft
- Ngay cả với cùng một lời gọi API, độ chính xác, khả dụng, mức độ tương thích theo khu vực và chính sách quyền riêng tư có thể khác nhau rất lớn giữa các trình duyệt, và lập trình viên thường phụ thuộc vào chúng mà không nhận ra
- Cấu trúc tiêu chuẩn hóa xoay quanh các nhà cung cấp lớn làm tăng rào cản gia nhập với các trình duyệt nhỏ và hệ sinh thái mã nguồn mở, đồng thời củng cố hiệu ứng khóa chặt (lock-in) trên thực tế
- Lập trình viên cần nhìn nhận các API này như một lớp trừu tượng hóa dịch vụ của vendor, chứ không phải ‘tiêu chuẩn web’ thuần túy, và cần song song thực hiện thông báo quyền riêng tư, thiết kế thay thế và kiểm thử theo từng trình duyệt
Nhận thức phổ biến về nền tảng web và cấu trúc thực tế
- Nền tảng web thường được xem là một hệ thống thống nhất dựa trên đặc tả tiêu chuẩn, và người ta kỳ vọng các trình duyệt cùng dùng một engine sẽ có hành vi giống nhau
- Nhưng trên thực tế, nhiều API lại phụ thuộc vào các triển khai riêng theo từng trình duyệt cùng với dịch vụ bên thứ ba, hạ tầng độc quyền và hệ thống nội bộ của vendor
- Khác với giao diện đã được tiêu chuẩn hóa, chi tiết triển khai có thể thay đổi rất lớn tùy theo lựa chọn của nhà cung cấp trình duyệt
Geolocation API và nguồn gốc thực sự của dữ liệu vị trí
- Geolocation API cung cấp một giao diện tiêu chuẩn hóa, nhưng dữ liệu vị trí thực tế được thu thập qua nhiều con đường khác nhau
- Sử dụng dịch vụ định vị của hệ điều hành và GPS
- Ước tính vị trí dựa trên thông tin điểm truy cập Wi‑Fi
- Tra cứu cơ sở dữ liệu vị trí dựa trên địa chỉ IP
- Chrome dùng Google Location Services, Safari dùng máy chủ của Apple, còn Firefox từ năm 2024 trở đi dùng dịch vụ của Google
- Khi dùng dữ liệu vị trí, dữ liệu người dùng có thể bị gửi tới máy chủ của một vendor cụ thể, nhưng giao diện trình duyệt thường không thể hiện rõ điều này
- Nếu quyền truy cập vào dịch vụ của vendor bị chặn ở một số khu vực, có khả năng tính năng sẽ không hoạt động bình thường
Speech Synthesis và hạ tầng xử lý giọng nói
- Tính năng tổng hợp giọng nói của Web Speech API dùng các engine khác nhau tùy theo trình duyệt, hệ điều hành và môi trường thiết bị
- Speech Synthesis API là giao diện đã được tiêu chuẩn hóa, nhưng dữ liệu giọng nói được xử lý bởi engine TTS của hệ điều hành hoặc máy chủ đám mây
- Chrome kết hợp xử lý cục bộ và đám mây, còn Safari dùng engine giọng nói của hệ điều hành
- Một số giọng nói chất lượng cao cần xử lý dựa trên đám mây, nên phải truyền dữ liệu lên mạng và dữ liệu người dùng sẽ được gửi tới máy chủ
- Có nguy cơ các tin nhắn cá nhân hoặc thông tin nhạy cảm vô tình bị gửi tới máy chủ bên ngoài
- Ngoài ra, giọng nói được chọn trong môi trường kiểm thử có thể không tồn tại trong môi trường của người dùng
Speech Recognition và truyền giọng nói theo thời gian thực
- Speech Recognition API phần lớn phụ thuộc vào các dịch vụ nhận dạng trên đám mây
- Chrome dùng Google, Safari dùng Apple, còn Edge sử dụng các dịch vụ thuộc hệ Azure
- Từ Chrome 139, có thể xử lý cục bộ bằng tùy chọn
processLocally, nhưng đây không phải mặc định, và cũng chỉ là tính năng dành riêng cho Chrome
- Độ chính xác và hỗ trợ ngôn ngữ khác nhau tùy chất lượng mô hình của từng vendor
Passkeys và nền tảng thực tế của WebAuthn: phụ thuộc vào hệ sinh thái trình duyệt
- WebAuthn API hướng tới xác thực không mật khẩu, nhưng trên thực tế lại phụ thuộc vào hạ tầng trình quản lý mật khẩu của trình duyệt
- Chrome dùng Google Password Manager, Safari dùng iCloud Keychain, Edge dùng Microsoft Account
- Polypane và một số trình duyệt khác không hỗ trợ Passkey do giới hạn của Electron, nên cần dùng tiện ích mở rộng như 1Password
- Cách lưu trữ, đồng bộ hóa và khôi phục thông tin xác thực hoàn toàn do triển khai của từng vendor quyết định
Payment Request API và sự phụ thuộc vào vendor thanh toán
- Payment Request API trông giống một tiêu chuẩn, nhưng trên thực tế việc thanh toán có hoạt động hay không lại phụ thuộc vào đối tác của từng vendor
- Chrome dùng Google Pay, Safari dùng Apple Pay, Edge dùng tích hợp của Microsoft, còn Firefox không hỗ trợ
- Mức độ hỗ trợ theo khu vực, UX và yêu cầu thiết lập bổ sung từ người dùng khác nhau giữa các trình duyệt
- Kết quả là cần có hợp đồng riêng và logic xử lý riêng cho từng phương thức thanh toán
Push API và mạng lưới thông báo theo từng vendor
- Push API là tiêu chuẩn, nhưng hạ tầng máy chủ thực sự dùng để chuyển thông báo lại khác nhau theo từng trình duyệt
- Chrome/Edge dùng FCM, Safari dùng APNs, Firefox dùng Mozilla Push Service
- Giới hạn truyền tải, kích thước thông điệp, xử lý ngoại tuyến và chính sách quyền riêng tư khác nhau giữa các dịch vụ
- Nếu hạ tầng của vendor gặp sự cố, toàn bộ chức năng push của trình duyệt đó đều có thể bị ảnh hưởng
API media, codec và vấn đề DRM
- Media Source Extensions (MSE) và Encrypted Media Extensions (EME) là tiêu chuẩn, nhưng mức hỗ trợ lại khác nhau tùy theo codec và giấy phép DRM
- Chrome, Edge và Firefox dùng Widevine, trong khi Safari dùng FairPlay, cho thấy sự phụ thuộc vào các công nghệ độc quyền hoàn toàn
- Mỗi vendor trình duyệt có codec ưu tiên và chiến lược riêng
- Do chi phí giấy phép DRM và các ràng buộc kỹ thuật, các trình duyệt nhỏ khó có thể hỗ trợ
Sự xuất hiện của API AI trong trình duyệt: một cấu trúc độc quyền mới
- Chrome đang thử nghiệm AI API dựa trên Gemini Nano (tóm tắt, dịch, hiệu đính...)
- Dữ liệu không bị gửi đi nhờ chạy cục bộ, nhưng kích thước mô hình (khoảng 4GB) và yêu cầu GPU đều cao, đồng thời đây là mô hình độc quyền của Google
- Các trình duyệt khác phải tự phát triển mô hình riêng, và các trình duyệt nhỏ hoặc dự án mã nguồn mở không thể sở hữu hay duy trì mô hình tương đương nên khó cạnh tranh
- Đây là một cấu trúc phụ thuộc vendor mới dựa trên AI
Vì sao điều này quan trọng
- Vấn đề tính di động: ngay cả cùng một đoạn mã, chất lượng hoạt động vẫn có thể khác nhau tùy trình duyệt, khu vực và môi trường
- Rủi ro quyền riêng tư: dữ liệu giọng nói, vị trí và push có thể vô tình bị gửi tới máy chủ của vendor
- Sự mất cân bằng trong tiêu chuẩn hóa: các công ty lớn dẫn dắt việc viết đặc tả và triển khai, đồng thời biến hạ tầng của họ thành điều kiện gần như bắt buộc, khiến các trình duyệt nhỏ bị loại khỏi cuộc chơi
- Tác động tới lập trình viên: các tính năng này hữu ích, nhưng cần nhận thức rằng đó là sự phụ thuộc vào dịch vụ chứ không phải tiêu chuẩn thuần túy
Cách tiếp cận mà lập trình viên nên áp dụng
- Xem API như một lớp trừu tượng hóa dịch vụ của vendor, đồng thời chuẩn bị kiểm thử, tài liệu hóa và lộ trình thay thế
- Thiết kế graceful degradation để đối phó với sự không đồng nhất về tính năng
- Đảm bảo tính minh bạch về quyền riêng tư: nêu rõ khả năng dữ liệu có thể được gửi tới máy chủ bên thứ ba
- Quản lý sự phụ thuộc vào vendor: cần có phương án ứng phó khi dịch vụ ngừng hoạt động hoặc chính sách thay đổi
- Kiểm thử theo trình duyệt và khu vực để xác nhận chênh lệch về chất lượng
- Lựa chọn mang tính chiến lược nhằm giảm tối đa sự phụ thuộc vào vendor
Web mà chúng ta nghĩ tới vs web trong thực tế
- Lời gọi API tiêu chuẩn hóa có thể giống nhau, nhưng luồng dữ liệu, độ chính xác, hỗ trợ theo khu vực, quyền riêng tư và cấu trúc chi phí lại khác giữa các trình duyệt
- Việc gọi
navigator.geolocation.getCurrentPosition() trên thực tế gần như là gọi tới dịch vụ định vị của Google hoặc Apple
- Đặc tả tiêu chuẩn chỉ định nghĩa giao diện, còn hành vi thực tế lại phụ thuộc vào hạ tầng và chính sách của vendor
- Gọi API đồng nghĩa với việc sử dụng máy chủ, chính sách và mô hình kinh doanh của một vendor cụ thể
- Nền tảng web rất mạnh, nhưng trên thực tế lại phân mảnh hơn và xoay quanh vendor nhiều hơn
- Lập trình viên cần hiểu rõ ranh giới giữa tiêu chuẩn và triển khai để thiết kế phù hợp
Chưa có bình luận nào.