Một ứng dụng headless tách biệt backend khỏi frontend. Logic nghiệp vụ, dữ liệu và chức năng cốt lõi nằm ở một bên. Giao diện người dùng nằm ở một bên khác. Hai phần này chỉ giao tiếp với nhau thông qua API.
Tên gọi này xuất phát từ một ý tưởng đơn giản. "Đầu" (head) là lớp trình bày, phần người dùng nhìn thấy. Loại bỏ giao diện người dùng tích hợp sẵn và bạn sẽ có một hệ thống "không đầu" (headless). Backend vẫn thực hiện công việc của nó. Nó phơi bày công việc đó thông qua một API thay vì tự mình hiển thị màn hình.
Hướng dẫn này giải thích ứng dụng headless là gì, tại sao các nhóm áp dụng mô hình này, những đánh đổi bạn phải chấp nhận và nó khác biệt như thế nào so với các thuật ngữ "headless" liên quan dễ bị nhầm lẫn. Nó cũng cho thấy lý do tại sao hợp đồng API trở thành tài sản quan trọng nhất khi ứng dụng của bạn chuyển sang headless.
“Headless” thực sự có nghĩa là gì
Trong một ứng dụng truyền thống, backend và frontend được triển khai như một thể thống nhất. Máy chủ chứa dữ liệu, chạy logic và cũng tạo ra HTML mà trình duyệt hiển thị. UI và logic được liên kết chặt chẽ với nhau.
Một ứng dụng headless phá vỡ liên kết đó. Backend trở thành một tập hợp các điểm cuối API. Nó trả về dữ liệu, chứ không phải trang. Bất kỳ client nào cũng có thể gọi các điểm cuối đó: một ứng dụng web, một ứng dụng di động, một TV thông minh, một thiết bị IoT hoặc một dịch vụ backend khác.
Kiến trúc này được định nghĩa là API-first. Mọi chức năng phải có thể truy cập được thông qua API, vì API là con đường duy nhất để vào. Không có màn hình tích hợp sẵn để dự phòng.
Quy tắc duy nhất đó định hình lại cách bạn xây dựng. Frontend giờ đây chỉ là một trong nhiều người tiêu dùng. Bạn có thể hoán đổi, xây dựng lại hoặc thêm các frontend mới mà không cần chạm vào lõi. Mỗi bên triển khai theo lịch trình riêng của mình.
Tại sao các nhóm chọn headless
Việc tách rời nghe có vẻ trừu tượng cho đến khi bạn thấy những gì nó mang lại. Dưới đây là những lý do thực tế mà các nhóm chọn mô hình này.
Phân phối đa kênh (Omnichannel delivery)
Một backend có thể phục vụ mọi kênh. Bạn viết logic một lần, sau đó xây dựng một frontend web, một ứng dụng di động và tích hợp đối tác dựa trên cùng một API. Mỗi client hiển thị phản hồi theo cách phù hợp với ngữ cảnh của nó.
Thêm một kênh mới có nghĩa là thêm một người tiêu dùng API mới, chứ không phải tái kiến trúc hệ thống. Một trợ lý giọng nói hoặc một ki-ốt trở thành một người gọi khác đến các điểm cuối đã tồn tại.
Các nhóm và triển khai độc lập
Khi frontend và backend chia sẻ một cơ sở mã, các nhóm chia sẻ một chu kỳ phát hành. Một bên phải chờ đợi bên kia. Headless loại bỏ sự gắn kết đó.
Một nhóm frontend có thể triển khai một thiết kế lại mà không cần triển khai backend. Một nhóm backend có thể tái cấu trúc nội bộ mà không làm hỏng UI, miễn là hợp đồng API được giữ nguyên. Cả hai bên đều di chuyển theo tốc độ riêng của mình.
Tái sử dụng và linh hoạt
Cùng một logic nghiệp vụ hỗ trợ nhiều sản phẩm. Một công cụ tính giá, một dịch vụ xác thực hoặc một kho nội dung được xây dựng một lần và tái sử dụng ở mọi nơi. Bạn cũng có được sự tự do ở phía frontend. Chọn bất kỳ framework nào bạn muốn, vì backend không quan tâm cách phản hồi được hiển thị.
Sự linh hoạt này là lý do tại sao headless đứng cạnh các ý tưởng như phát triển API-first và luận điểm rộng hơn rằng phần mềm đang chuyển sang headless và API là sản phẩm. Khi UI có thể tháo rời, API là thứ bạn thực sự bán và hỗ trợ.
Những đánh đổi
Headless không phải là miễn phí. Mô hình này di chuyển độ phức tạp hơn là loại bỏ nó. Hãy thành thật về chi phí trước khi bạn cam kết.
Bây giờ bạn phải quản lý nhiều thành phần chuyển động hơn. Hai hoặc nhiều thành phần có thể triển khai thay vì một. Nhiều hạ tầng hơn, nhiều pipeline CI hơn và nhiều dịch vụ để giám sát hơn. Một nhóm nhỏ xây dựng một trang web đơn giản, duy nhất có thể không cần bất kỳ điều này.
Bạn cũng hoàn toàn sở hữu frontend. Một CMS hoặc framework truyền thống cung cấp cho bạn các template và khả năng hiển thị sẵn có. Chuyển sang headless và bạn tự xây dựng lớp trình bày, cho mọi kênh.
Sau đó là vấn đề hợp đồng. Với một cơ sở mã, một thay đổi gây lỗi sẽ xuất hiện ngay lập tức tại thời điểm biên dịch. Với việc tách rời headless, một thay đổi ở backend có thể âm thầm làm hỏng một client gọi API. Không có gì ngăn chặn nó cho đến khi có lỗi xảy ra trong môi trường sản xuất.
Điểm cuối cùng đó là điểm lớn nhất. Hợp đồng API là mối nối giữ toàn bộ hệ thống lại với nhau, và nó cũng là thứ dễ bị phá vỡ nhất do tai nạn.
Ứng dụng Headless so với các thuật ngữ liên quan
“Headless” gắn liền với một số thứ khác nhau. Chúng chia sẻ cùng một ý tưởng, không có UI tích hợp sẵn, nhưng chúng mô tả các lớp khác nhau. Việc trộn lẫn chúng gây ra sự nhầm lẫn thực sự trong các cuộc trò chuyện lập kế hoạch. Dưới đây là phân tích rõ ràng.
Ứng dụng headless (Headless application)
Thuật ngữ rộng nhất. Một mô hình kiến trúc cho bất kỳ phần mềm nào tách logic backend khỏi trình bày frontend và phơi bày chức năng thông qua API. Toàn bộ hệ thống của bạn là headless. Một ứng dụng web, một ứng dụng di động và một dịch vụ đều có thể tiêu thụ nó.
API headless (Headless API)
Một API được phơi bày mà không có UI tích hợp sẵn. Điều này gần hơn với mô tả một thành phần hơn là một kiến trúc tổng thể. Một API headless là giao diện mà một ứng dụng headless cung cấp cho người tiêu dùng của nó. Trong thực tế, hai thuật ngữ này trùng lặp rất nhiều, ứng dụng headless là hệ thống, API headless là cánh cửa dẫn vào nó.
CMS headless (Headless CMS)
Một trường hợp hẹp hơn, cụ thể về nội dung. Một CMS headless quản lý nội dung trong backend và phân phối nó thông qua API, thay vì tự mình hiển thị các trang web. Các công cụ như Contentful, Sanity và Strapi thuộc loại này. Nó là một ứng dụng headless mà miền của nó là nội dung. "Đầu" mà bạn đã loại bỏ là công cụ tạo template của một CMS truyền thống.
Trình duyệt headless (Headless browser)
Trường hợp ngoại lệ. Trình duyệt headless là một trình duyệt web thực sự chạy mà không có cửa sổ hiển thị. Nó hiển thị các trang, chạy JavaScript và hoạt động giống như một trình duyệt bình thường, nhưng bạn điều khiển nó từ dòng lệnh hoặc một tập lệnh. Các nhóm sử dụng nó để kiểm thử tự động, chụp màn hình và thu thập dữ liệu. Playwright và Puppeteer là các trình điều khiển phổ biến. Điều này không liên quan gì đến kiến trúc backend, mặc dù có chung từ khóa.
Điểm chung: cả bốn đều loại bỏ giao diện đồ họa và hoạt động thông qua mã. Nhưng ứng dụng headless là một kiến trúc, API headless là một giao diện, CMS headless là một backend nội dung và trình duyệt headless là một công cụ tự động hóa. Hãy sử dụng thuật ngữ chính xác cho thứ chính xác.
Nơi Headless gặp gỡ Composable và MACH
Bạn sẽ thường thấy headless được nhắc đến cùng với “composable” và “MACH”. Chúng có liên quan nhưng không giống hệt nhau.
Kiến trúc composable có nghĩa là xây dựng một hệ thống từ các dịch vụ độc lập, có thể hoán đổi. Mỗi phần thực hiện một công việc và kết nối thông qua API. Headless là một điều kiện tiên quyết, bạn không thể hoán đổi frontend một cách tự do nếu nó được hàn gắn vào backend.
MACH là viết tắt của Microservices, API-first, Cloud-native và Headless. Đây là một tập hợp các nguyên tắc kết hợp headless với ba ý tưởng khác để mô tả các kiến trúc hiện đại, theo mô-đun. Headless là một chữ cái trong từ viết tắt, phần nói rằng frontend được tách rời.
Bạn không cần toàn bộ stack MACH để xây dựng một ứng dụng headless. Nhưng nếu bạn đã chuyển sang headless, thì các mô hình liền kề này là những câu hỏi tự nhiên tiếp theo.
Tại sao hợp đồng API trở thành sản phẩm
Đây là sự thay đổi quan trọng nhất. Trong một ứng dụng headless, API không còn là một cánh cửa phụ. Nó là cánh cửa duy nhất. Mọi client đều phụ thuộc vào nó. Nếu hợp đồng không rõ ràng, không ổn định hoặc không được ghi lại, mọi người tiêu dùng đều chịu ảnh hưởng ngay lập tức.
Đây là trọng tâm của việc coi API của bạn như một sản phẩm. Người tiêu dùng của bạn, dù là nhóm di động của riêng bạn hay đối tác bên ngoài, đều là người dùng. Hình dạng, độ tin cậy và tài liệu của API là trải nghiệm sản phẩm. Một hợp đồng API rõ ràng, ổn định là điều cho phép các nhóm độc lập tin tưởng lẫn nhau giữa các mối nối.
Đó là lý do tại sao thực hành design-first mang lại hiệu quả ở đây. Bạn định nghĩa hợp đồng trước khi bạn viết phần triển khai, thống nhất về nó giữa các nhóm và xây dựng dựa trên một nguồn sự thật chung. So sánh các cách tiếp cận trong API-first vs API design-first vs code-first để xem điều này phù hợp với quy trình làm việc của bạn ở đâu. Các nguyên tắc thiết kế API mạnh mẽ giữ cho hợp đồng nhất quán khi hệ thống phát triển.
Chi phí cho việc làm sai điều này tăng theo số lượng người tiêu dùng. Một client có thể chấp nhận một API cẩu thả. Năm client trên web, di động và đối tác thì không thể. Sự kỷ luật mà bạn đặt vào hợp đồng là sự kỷ luật giúp toàn bộ hệ thống headless ổn định.
Một công cụ như Apidog phù hợp ở đâu
Khi API là sản phẩm, bạn cần thiết kế, kiểm thử, mô phỏng và tài liệu hóa nó thật tốt. Đó là lớp chất lượng API, và nó là một lát cắt hẹp của bức tranh headless. Apidog hoạt động trong lát cắt đó.
Để làm rõ phạm vi: Apidog không phải là CMS, nền tảng thương mại điện tử, API gateway hay công cụ tạo tải. Nó không xây dựng kiến trúc headless cho bạn. Điều nó làm là giúp bạn giữ cho hợp đồng gắn kết kiến trúc lại với nhau một cách trung thực.
Trong thực tế, điều đó trông giống như một vài thứ. Bạn thiết kế hợp đồng trong một trình soạn thảo OpenAPI trực quan, để mọi nhóm đều thấy cùng một nguồn sự thật trước khi code tồn tại. Bạn mô phỏng các điểm cuối bằng dữ liệu động để các nhóm frontend có thể xây dựng dựa trên hợp đồng trước khi backend sẵn sàng. Bạn viết các kịch bản kiểm thử tự động với các xác nhận để bắt lỗi thay đổi gây lỗi trước khi nó đến tay client, và chạy chúng trong CI với Apidog CLI. Bạn xuất bản tài liệu tương tác được tạo tự động để mọi người tiêu dùng API headless của bạn biết chính xác cần gọi gì.
Apidog hỗ trợ REST, GraphQL, gRPC, WebSocket, SOAP và Socket.IO, và chạy dưới dạng ứng dụng desktop, ứng dụng web và CLI. Đây là một trong số các lựa chọn cho công việc chất lượng API. Vấn đề không phải là công cụ. Vấn đề là việc chuyển sang headless khiến chất lượng hợp đồng trở thành mối quan tâm hàng đầu, và công việc đó phải được thực hiện ở đâu đó.
FAQ (Câu hỏi thường gặp)
Một ứng dụng headless có giống với một ứng dụng trang đơn (single-page application) không?
Không. Một ứng dụng trang đơn là một mô hình frontend, một UI web cập nhật mà không cần tải lại toàn bộ trang. Một ứng dụng headless là một mô hình backend về việc tách rời logic khỏi trình bày. Một SPA thường tiêu thụ một backend headless, nhưng chúng mô tả các lớp khác nhau.
Tôi có cần microservices để xây dựng một ứng dụng headless không?
Không. Headless là về việc tách frontend khỏi backend, không phải về cách bạn cấu trúc backend nội bộ. Bạn có thể xây dựng một ứng dụng headless với một backend nguyên khối duy nhất phơi bày các API. Microservices là một lựa chọn riêng biệt.
Headless luôn tốt hơn một ứng dụng truyền thống được liên kết chặt chẽ (coupled app) không?
Không. Headless thêm độ phức tạp trong vận hành và chuyển công việc frontend sang nhóm của bạn. Đối với một trang web đơn giản với một kênh, một stack truyền thống được liên kết chặt chẽ thường nhanh hơn để xây dựng và rẻ hơn để chạy. Headless mang lại lợi ích khi bạn có nhiều kênh, các nhóm độc lập hoặc nhu cầu tái sử dụng mạnh mẽ.
Sự khác biệt giữa API headless và ứng dụng headless là gì?
Một ứng dụng headless là toàn bộ hệ thống, logic backend được tách rời khỏi trình bày. Một API headless là giao diện mà hệ thống đó phơi bày. Trong cách sử dụng thông thường, các thuật ngữ này trùng lặp, nhưng ứng dụng là kiến trúc và API là cánh cửa dẫn vào nó.
Tại sao hợp đồng API lại quan trọng đến vậy trong thiết lập headless?
Vì API là kết nối duy nhất giữa backend và mọi client. Một thay đổi gây lỗi không xuất hiện tại thời điểm biên dịch, nó xuất hiện trong môi trường sản xuất. Một hợp đồng rõ ràng, ổn định, được tài liệu hóa tốt là điều giúp mọi người tiêu dùng hoạt động khi hệ thống phát triển.