PHẦN 1 — OVERVIEW
1. Giới thiệu
Khi xây dựng một ứng dụng Machine Learning, một câu hỏi quan trọng là làm sao để đưa mô hình ra thế giới thực. Một mô hình tốt không chỉ nằm ở file .pt hay .h5, mà cần có cách để người dùng hoặc hệ thống khác tương tác với nó. Thông thường, chúng ta sẽ biến mô hình thành một dịch vụ nhận dữ liệu đầu vào và trả về dự đoán. Điều đó dẫn tới sự xuất hiện của API – cầu nối giữa phần mềm và mô hình.
Mình muốn bắt đầu bằng hình dung quen thuộc: khi bạn gọi món trong nhà hàng, bạn không vào bếp mà đưa yêu cầu cho phục vụ, người này chuyển yêu cầu ấy xuống bếp rồi trả món về cho bạn. Backend chính là nhà bếp, còn API chính là người phục vụ. Từ ví dụ đó, chúng ta sẽ từng bước học các thành phần giúp triển khai mô hình: API là gì, server nào xử lý request, vì sao cần async, và FastAPI đứng ở đâu so với Flask hay Django.
Phần Overview này đóng vai trò nền tảng. Chúng ta cần hiểu thật rõ các khái niệm này để sau đó xây dựng CRUD đơn giản, rồi mở rộng thành một hệ thống phục vụ mô hình Fashion Detection như trong case study cuối bài.
2. API là gì?
Chúng ta hãy đặt câu hỏi: khi một ứng dụng muốn giao tiếp với một hệ thống khác, họ sử dụng cơ chế nào? Đó chính là API, hay Application Programming Interface. API không phải là một sản phẩm hữu hình, mà là một tập các quy tắc định nghĩa cách một hệ thống gửi yêu cầu và nhận câu trả lời. Từ góc nhìn kỹ thuật, API giúp chuẩn hóa giao tiếp, giúp mọi thành phần trong hệ thống hiểu được dữ liệu trao đổi mà không cần phụ thuộc vào cách bên trong mỗi hệ thống hoạt động.
Để hình dung rõ hơn, ta xem lại mô hình client–server: phía client gửi request, phía server xử lý và trả về response. Trong FastAPI hay bất kỳ framework backend nào, mọi thứ xoay quanh việc định nghĩa endpoint, format dữ liệu và xử lý logic. Khi triển khai mô hình ML, request thường chứa file ảnh, văn bản, hoặc JSON tham số; response chứa output của mô hình như class, label hoặc bounding box.
Điều quan trọng ở đây là API giúp biến mô hình thành dịch vụ. Thay vì chạy file Python trong máy cá nhân, ta có thể để hàng trăm người dùng cùng truy cập vào một endpoint duy nhất, server sẽ xử lý lần lượt hoặc song song tùy kiến trúc.
Các giao thức API
Dưới đây là các Giao thức API được xây dựng và phát triển theo trình tự thời gian
1. SOAP
SOAP là phong cách API lâu đời dựa trên định dạng XML. Giao thức này rất chặt chẽ và có quy tắc nghiêm ngặt về cách đóng gói request và response, nên thường xuất hiện trong các hệ thống doanh nghiệp cần bảo mật và tính nhất quán cao như ngân hàng hoặc viễn thông. Nhược điểm của SOAP là khá nặng và phức tạp, vì mỗi request mang nhiều metadata. Tuy vậy, chính sự chặt chẽ này giúp SOAP được dùng nơi yêu cầu tính ổn định tuyệt đối.
2. RESTful
RESTful API là phong cách phổ biến nhất hiện nay khi xây dựng web server. Thay vì dùng XML, REST dùng JSON nhẹ hơn và dễ thao tác hơn. REST dựa trên ý tưởng tài nguyên: mỗi URL đại diện cho một resource, và client thao tác resource bằng các HTTP method như GET, POST, PUT hoặc DELETE. REST dễ viết, dễ đọc, phù hợp với frontend, mobile app và backend ML như FastAPI. Chính sự đơn giản đã khiến REST trở thành tiêu chuẩn de-facto của API web.
3. GraphQL
GraphQL ra đời để giải quyết vấn đề over-fetching và under-fetching trong REST. Thay vì server quyết định trả về cấu trúc dữ liệu gì, GraphQL cho phép client đặt câu hỏi: “tôi muốn trường A, B, C của resource này”. Điều đó giảm tải mạng vì client chỉ nhận đúng dữ liệu cần thiết. Hình minh họa cho thấy một request có thể gom nhiều nguồn dữ liệu khác nhau vào cùng một kết quả. GraphQL phù hợp với ứng dụng lớn có dữ liệu phân tán hoặc giao diện thay đổi liên tục.
4. GRPC
gRPC là phong cách API tối ưu cho microservices. Dữ liệu không truyền dưới dạng JSON mà dưới dạng nhị phân (Protocol Buffers), giúp giảm kích thước và tăng tốc độ truyền đáng kể. Điều này rất quan trọng khi hàng trăm dịch vụ nhỏ phải gọi qua lại lẫn nhau với độ trễ thấp. Hình minh họa cho thấy dữ liệu được encode thành chuỗi bit, rồi decode ở đầu bên kia. Khi muốn xây dựng hệ thống lớn, yêu cầu hiệu năng cao, gRPC luôn là nền tảng tin cậy hơn REST.
5. WebSocket
WebSocket dành cho ứng dụng cần giao tiếp hai chiều liên tục như chat, livestream hoặc dashboard cập nhật thời gian thực. Khác với HTTP – vốn là cơ chế request/response một lần – WebSocket giữ kết nối mở, cho phép server chủ động đẩy dữ liệu về client bất cứ lúc nào. Điều này làm giảm độ trễ đáng kể vì không phải mở kết nối liên tục. Hình minh họa “push” thể hiện rằng server có thể gửi dữ liệu mà không chờ client gọi trước.
6. Webhook
Webhook là cơ chế gọi API nhưng chủ động từ phía server. Khi một sự kiện xảy ra, server A sẽ gửi request sang server B để thông báo, thay vì B phải liên tục hỏi A. Đây là mô hình bất đồng bộ theo sự kiện, rất phù hợp với thanh toán, sự kiện GitHub, hoặc xử lý nền trong hệ thống lớn. Webhook giống như người gửi tin nhắn ngay khi có chuyện mới, thay vì bạn phải hỏi mỗi vài giây xem có cập nhật hay không. Nhờ cơ chế này, ứng dụng tiết kiệm băng thông và phản ứng nhanh hơn.
3. Uvicorn và ASGI Server
Khi viết FastAPI, vì sao ta phải chạy lệnh như uvicorn main:app --reload? Lý do là bản thân FastAPI không tự xử lý kết nối mạng. Nó chỉ định nghĩa router và logic, còn phần giao tiếp TCP, HTTP, websocket được thực hiện bởi ASGI server như Uvicorn.
ASGI viết tắt từ Asynchronous Server Gateway Interface. Đây là chuẩn hiện đại hơn WSGI trong Flask hay Django bản cũ, vì ASGI hỗ trợ chạy bất đồng bộ. Nhờ đó, server có thể xử lý hàng nghìn kết nối mà không bị chặn bởi các tác vụ I/O như đọc file, chờ mạng, hoặc chờ mô hình inference.
FastAPI được xây dựng để tận dụng tối đa lợi thế này, từ đó đạt hiệu năng rất cao trong benchmark thực tế.
Như vậy, Uvicorn đóng vai trò lớp phiên dịch giữa request HTTP bên ngoài và hàm Python bên trong ứng dụng. Nó nhận request, biến đổi thành event theo chuẩn ASGI, truyền vào FastAPI, rồi đóng gói response trả về cho client. Khi deploy lên production, ta cũng có thể kết hợp Gunicorn và Uvicorn để tăng khả năng chịu tải.
Nếu coi API là người phục vụ, thì Uvicorn chính là hệ thống cửa ra vào: nhận khách, đưa yêu cầu vào trong, rồi đẩy kết quả ra ngoài.
4. Async và Await — Tại sao FastAPI lại nhanh?
Trong Python, chương trình thông thường chạy tuần tự: xong bước A rồi mới tới bước B. Nhưng trong một API server, nhiều thao tác không yêu cầu CPU liên tục, như chờ đọc file, chờ kết quả từ mô hình, hay chờ database trả dữ liệu. Nếu server phải “ngồi đợi”, nó sẽ lãng phí tài nguyên.
Async/await cho phép chương trình tạm dừng một tác vụ đang chờ I/O, chuyển sang xử lý tác vụ khác, rồi quay lại khi đã sẵn sàng. Điều này giống như việc bạn đặt nồi nước lên bếp và trong thời gian chờ sôi, bạn làm tiếp công việc khác thay vì đứng nhìn.