Kiến trúc Serverless Frontend: Phân tích sâu về Tổ hợp và Điều phối Hàm

Trong bối cảnh phát triển web không ngừng phát triển, vai trò của frontend đã vượt xa việc hiển thị các giao diện người dùng đơn giản để quản lý trạng thái ứng dụng phức tạp, xử lý logic nghiệp vụ phức tạp và điều phối nhiều hoạt động không đồng bộ. Khi các ứng dụng ngày càng trở nên tinh vi, độ phức tạp đằng sau hậu trường cũng tăng lên. Kiến trúc backend nguyên khối truyền thống và thậm chí cả kiến trúc microservices thế hệ đầu tiên đôi khi có thể tạo ra các nút thắt cổ chai, liên kết tính nhanh nhẹn của frontend với chu kỳ phát hành của backend. Đây là nơi kiến trúc serverless, đặc biệt dành cho frontend, trình bày một sự thay đổi mô hình.

Nhưng việc áp dụng serverless không đơn giản chỉ là viết các hàm riêng lẻ. Một ứng dụng hiện đại hiếm khi thực hiện một tác vụ chỉ với một hành động riêng lẻ. Thông thường hơn, nó liên quan đến một chuỗi các bước, các quy trình song song và logic có điều kiện. Làm thế nào để chúng ta quản lý các quy trình công việc phức tạp này mà không quay lại tư duy nguyên khối hoặc tạo ra một mớ bòng bong các hàm liên kết với nhau? Câu trả lời nằm ở hai khái niệm mạnh mẽ: tổ hợp hàm và điều phối hàm.

Hướng dẫn toàn diện này sẽ khám phá cách các mẫu này biến đổi lớp Backend-for-Frontend (BFF), cho phép các nhà phát triển xây dựng các ứng dụng mạnh mẽ, có khả năng mở rộng và có thể bảo trì. Chúng ta sẽ phân tích các khái niệm cốt lõi, kiểm tra các mẫu phổ biến, đánh giá các dịch vụ điều phối đám mây hàng đầu và thực hiện một ví dụ thực tế để củng cố sự hiểu biết của bạn.

Sự phát triển của Kiến trúc Frontend và Sự trỗi dậy của Serverless BFF

Để đánh giá cao tầm quan trọng của việc điều phối serverless, sẽ rất hữu ích nếu hiểu được hành trình của kiến trúc frontend. Chúng ta đã chuyển từ các trang được kết xuất bởi máy chủ sang các Ứng dụng một trang (SPA) phong phú giao tiếp với backends thông qua API REST hoặc GraphQL. Sự phân tách các mối quan tâm này là một bước tiến lớn, nhưng nó đã đưa ra những thách thức mới.

Từ Nguyên khối đến Microservices và BFF

Ban đầu, các SPA thường nói chuyện với một API backend nguyên khối duy nhất. Điều này đơn giản nhưng dễ vỡ. Một thay đổi nhỏ đối với ứng dụng di động có thể phá vỡ ứng dụng web. Phong trào microservices đã giải quyết vấn đề này bằng cách chia nhỏ khối nguyên khối thành các dịch vụ nhỏ hơn, có thể triển khai độc lập. Tuy nhiên, điều này thường dẫn đến việc frontend phải gọi nhiều microservices để hiển thị một chế độ xem duy nhất, dẫn đến logic phía client phức tạp, nhiều cuộc trò chuyện.

Mẫu Backend-for-Frontend (BFF) xuất hiện như một giải pháp. BFF là một lớp backend chuyên dụng cho một trải nghiệm frontend cụ thể (ví dụ: một cho ứng dụng web, một cho ứng dụng iOS). Nó đóng vai trò là một giao diện, tổng hợp dữ liệu từ các microservices xuôi dòng khác nhau và điều chỉnh phản hồi API cụ thể cho nhu cầu của client. Điều này đơn giản hóa mã frontend, giảm số lượng yêu cầu mạng và cải thiện hiệu suất.

Serverless là sự kết hợp hoàn hảo cho BFF

Các hàm serverless, hoặc Function-as-a-Service (FaaS), phù hợp một cách tự nhiên để triển khai BFF. Thay vì duy trì một máy chủ chạy liên tục cho BFF của bạn, bạn có thể triển khai một bộ sưu tập các hàm nhỏ, hướng sự kiện. Mỗi hàm có thể xử lý một điểm cuối API hoặc tác vụ cụ thể, chẳng hạn như tìm nạp dữ liệu người dùng, xử lý thanh toán hoặc tổng hợp nguồn cấp dữ liệu tin tức.

Cách tiếp cận này mang lại những lợi ích đáng kinh ngạc:

• Khả năng mở rộng: Các hàm tự động mở rộng dựa trên nhu cầu, từ không đến hàng nghìn lần gọi.
• Hiệu quả về chi phí: Bạn chỉ trả tiền cho thời gian tính toán bạn sử dụng, điều này rất lý tưởng cho các mẫu lưu lượng thường xuyên của BFF.
• Tốc độ nhà phát triển: Các hàm nhỏ, độc lập dễ phát triển, kiểm tra và triển khai hơn.

Tuy nhiên, điều này dẫn đến một thách thức mới. Khi độ phức tạp của ứng dụng của bạn tăng lên, BFF của bạn có thể cần gọi nhiều hàm theo một thứ tự cụ thể để đáp ứng một yêu cầu của client. Ví dụ: việc đăng ký người dùng có thể liên quan đến việc tạo một bản ghi cơ sở dữ liệu, gọi một dịch vụ thanh toán và gửi email chào mừng. Việc để client frontend quản lý trình tự này là không hiệu quả và không an toàn. Đây là vấn đề mà tổ hợp và điều phối hàm được thiết kế để giải quyết.

Hiểu các khái niệm cốt lõi: Tổ hợp và Điều phối

Trước khi đi sâu vào các mẫu và công cụ, hãy thiết lập một định nghĩa rõ ràng về các thuật ngữ chính của chúng ta.

Hàm Serverless (FaaS) là gì?

Về cốt lõi, các hàm serverless (như AWS Lambda, Azure Functions hoặc Google Cloud Functions) là các thể hiện tính toán ngắn hạn, không trạng thái, chạy để phản hồi một sự kiện. Một sự kiện có thể là một yêu cầu HTTP từ API Gateway, một tệp mới được tải lên một bộ chứa lưu trữ hoặc một tin nhắn trong hàng đợi. Nguyên tắc chính là bạn, nhà phát triển, không quản lý các máy chủ cơ bản.

Tổ hợp Hàm là gì?

Tổ hợp hàm là mẫu thiết kế để xây dựng một quy trình phức tạp bằng cách kết hợp nhiều hàm đơn giản, có mục đích duy nhất. Hãy nghĩ về nó như việc xây dựng bằng gạch Lego. Mỗi viên gạch (hàm) có một hình dạng và mục đích cụ thể. Bằng cách kết nối chúng theo những cách khác nhau, bạn có thể xây dựng các cấu trúc phức tạp (quy trình công việc). Trọng tâm của tổ hợp là vào luồng dữ liệu giữa các hàm.

Điều phối Hàm là gì?

Điều phối hàm là việc triển khai và quản lý tổ hợp đó. Nó liên quan đến một bộ điều khiển trung tâm — một người điều phối — người hướng dẫn việc thực thi các hàm theo một quy trình công việc được xác định trước. Người điều phối chịu trách nhiệm:

• Kiểm soát luồng: Thực thi các hàm theo trình tự, song song hoặc dựa trên logic có điều kiện (phân nhánh).
• Quản lý trạng thái: Theo dõi trạng thái của quy trình công việc khi nó tiến triển, truyền dữ liệu giữa các bước.
• Xử lý lỗi: Bắt lỗi từ các hàm và triển khai logic thử lại hoặc các hành động bồi thường (ví dụ: hoàn nguyên giao dịch).
• Phối hợp: Đảm bảo toàn bộ quy trình đa bước hoàn thành thành công dưới dạng một đơn vị giao dịch duy nhất.

Tổ hợp so với Điều phối: Một sự khác biệt rõ ràng

Điều quan trọng là phải hiểu sự khác biệt:

• Tổ hợp là thiết kế hoặc 'cái gì'. Đối với việc thanh toán thương mại điện tử, tổ hợp có thể là: 1. Xác thực Giỏ hàng -> 2. Xử lý thanh toán -> 3. Tạo Đơn hàng -> 4. Gửi xác nhận.
• Điều phối là công cụ thực thi hoặc 'làm thế nào'. Người điều phối là dịch vụ thực sự gọi hàm `validateCart`, đợi phản hồi của nó, sau đó gọi hàm `processPayment` với kết quả, xử lý mọi lỗi thanh toán bằng cách thử lại, v.v.

Mặc dù tổ hợp đơn giản có thể đạt được bằng một hàm gọi trực tiếp một hàm khác, nhưng điều này tạo ra sự liên kết chặt chẽ và dễ vỡ. Điều phối thực sự tách các hàm khỏi logic quy trình công việc, dẫn đến một hệ thống linh hoạt và có thể bảo trì hơn nhiều.

Các mẫu cho Tổ hợp Hàm Serverless

Một số mẫu phổ biến xuất hiện khi kết hợp các hàm serverless. Hiểu những điều này là chìa khóa để thiết kế các quy trình công việc hiệu quả.

1. Xâu chuỗi (Thực thi tuần tự)

Đây là mẫu đơn giản nhất, trong đó các hàm được thực thi lần lượt theo một trình tự. Đầu ra của hàm đầu tiên trở thành đầu vào cho hàm thứ hai, v.v. Nó tương đương với đường ống dẫn của serverless.

Trường hợp sử dụng: Quy trình xử lý hình ảnh. Frontend tải lên một hình ảnh, kích hoạt một quy trình làm việc:

1. Hàm A (ValidateImage): Kiểm tra loại tệp và kích thước.
2. Hàm B (ResizeImage): Tạo một số phiên bản hình thu nhỏ.
3. Hàm C (AddWatermark): Thêm hình mờ vào các hình ảnh đã thay đổi kích thước.
4. Hàm D (SaveToBucket): Lưu các hình ảnh cuối cùng vào một bộ chứa lưu trữ đám mây.

Điều này tạo ra một luồng rõ ràng, dễ đoán: A -> B -> C -> D.

2. Fan-out/Fan-in (Thực thi song song)

Mẫu này được sử dụng khi nhiều tác vụ độc lập có thể được thực hiện đồng thời để cải thiện hiệu suất. Một hàm duy nhất (fan-out) kích hoạt một số hàm khác để chạy song song. Một hàm cuối cùng (fan-in) đợi tất cả các tác vụ song song hoàn thành và sau đó tổng hợp kết quả của chúng.

Trường hợp sử dụng: Xử lý một tệp video. Một video được tải lên, kích hoạt một quy trình công việc:

1. Hàm A (StartProcessing): Nhận tệp video và kích hoạt các tác vụ song song.
2. Các tác vụ song song:
   • Hàm B (TranscodeTo1080p): Tạo phiên bản 1080p.
   • Hàm C (TranscodeTo720p): Tạo phiên bản 720p.
   • Hàm D (ExtractAudio): Trích xuất bản nhạc.
   • Hàm E (GenerateThumbnails): Tạo hình thu nhỏ xem trước.
3. Hàm F (AggregateResults): Khi B, C, D và E hoàn tất, hàm này sẽ cập nhật cơ sở dữ liệu bằng các liên kết đến tất cả các nội dung đã tạo.

Việc xử lý song song này làm giảm đáng kể tổng thời gian cần thiết so với một chuỗi tuần tự.

3. Nhắn tin không đồng bộ (Biên đạo hướng sự kiện)

Mặc dù không hoàn toàn là điều phối (nó thường được gọi là biên đạo), mẫu này rất quan trọng trong kiến trúc serverless. Thay vì một bộ điều khiển trung tâm, các hàm giao tiếp bằng cách xuất bản các sự kiện lên một xe buýt tin nhắn hoặc hàng đợi (ví dụ: AWS SNS/SQS, Google Pub/Sub, Azure Service Bus). Các hàm khác đăng ký các sự kiện này và phản ứng phù hợp.

Trường hợp sử dụng: Một hệ thống đặt hàng.

1. Frontend gọi một hàm `placeOrder`.
2. Hàm `placeOrder` xác thực đơn hàng và xuất bản một sự kiện `OrderPlaced` lên một xe buýt tin nhắn.
3. Nhiều hàm người đăng ký độc lập phản ứng với sự kiện này:
   • Một hàm `billing` xử lý thanh toán.
   • Một hàm `shipping` thông báo cho kho hàng.
   • Một hàm `notifications` gửi email xác nhận cho khách hàng.

Mẫu này tạo ra một hệ thống linh hoạt và có tính linh hoạt cao. Nếu dịch vụ thông báo bị ngừng hoạt động, nó sẽ không ngăn đơn hàng được thanh toán và vận chuyển.

Sức mạnh của Dịch vụ Điều phối được Quản lý

Mặc dù bạn có thể triển khai các mẫu này theo cách thủ công, nhưng việc quản lý trạng thái, xử lý lỗi và truy nguyên các lần thực thi sẽ nhanh chóng trở nên phức tạp. Đây là nơi các dịch vụ điều phối được quản lý từ các nhà cung cấp dịch vụ đám mây lớn trở nên vô giá. Chúng cung cấp khuôn khổ để xác định, trực quan hóa và thực thi các quy trình công việc phức tạp.

AWS Step Functions

AWS Step Functions là một dịch vụ điều phối serverless cho phép bạn xác định các quy trình công việc của mình dưới dạng máy trạng thái. Bạn xác định quy trình công việc của mình một cách khai báo bằng định dạng dựa trên JSON được gọi là Ngôn ngữ Trạng thái Amazon (ASL).

• Khái niệm cốt lõi: Máy trạng thái có thể thiết kế trực quan.
• Định nghĩa: JSON khai báo (ASL).
• Các tính năng chính: Trình chỉnh sửa quy trình công việc trực quan, logic xử lý lỗi và thử lại tích hợp sẵn, hỗ trợ các quy trình công việc có sự tham gia của con người (gọi lại) và tích hợp trực tiếp với hơn 200 dịch vụ AWS.
• Tốt nhất cho: Các nhóm thích cách tiếp cận trực quan, khai báo và tích hợp sâu với hệ sinh thái AWS.

Ví dụ đoạn ASL cho một chuỗi đơn giản:

{ "Comment": "Một quy trình công việc tuần tự đơn giản", "StartAt": "FirstState", "States": { "FirstState": { "Type": "Task", "Resource": "arn:aws:lambda:us-east-1:123456789012:function:MyFirstFunction", "Next": "SecondState" }, "SecondState": { "Type": "Task", "Resource": "arn:aws:lambda:us-east-1:123456789012:function:MySecondFunction", "End": true } } }

Azure Durable Functions

Durable Functions là một phần mở rộng của Azure Functions cho phép bạn viết các quy trình công việc có trạng thái theo phương pháp ưu tiên mã. Thay vì một ngôn ngữ khai báo, bạn xác định logic điều phối bằng ngôn ngữ lập trình đa năng như C#, Python hoặc JavaScript.

• Khái niệm cốt lõi: Viết logic điều phối dưới dạng mã.
• Định nghĩa: Mã mệnh lệnh (C#, Python, JavaScript, v.v.).
• Các tính năng chính: Sử dụng mẫu tạo sự kiện để duy trì trạng thái một cách đáng tin cậy. Cung cấp các khái niệm như hàm Orchestrator, Activity và Entity. Trạng thái được quản lý ngầm bởi framework.
• Tốt nhất cho: Các nhà phát triển thích xác định logic, vòng lặp và phân nhánh phức tạp trong ngôn ngữ lập trình quen thuộc của họ hơn là trong JSON hoặc YAML.

Ví dụ đoạn mã Python cho một chuỗi đơn giản:

import azure.durable_functions as df def orchestrator_function(context: df.DurableOrchestrationContext): result1 = yield context.call_activity('MyFirstFunction', 'input1') result2 = yield context.call_activity('MySecondFunction', result1) return result2

Google Cloud Workflows

Google Cloud Workflows là một dịch vụ điều phối được quản lý đầy đủ cho phép bạn xác định quy trình công việc bằng YAML hoặc JSON. Nó vượt trội trong việc kết nối và tự động hóa các dịch vụ của Google Cloud và API dựa trên HTTP.

• Khái niệm cốt lõi: Định nghĩa quy trình công việc dựa trên YAML/JSON.
• Định nghĩa: YAML hoặc JSON khai báo.
• Các tính năng chính: Khả năng yêu cầu HTTP mạnh mẽ để gọi các dịch vụ bên ngoài, trình kết nối tích hợp sẵn cho các dịch vụ của Google Cloud, quy trình công việc phụ cho thiết kế mô-đun và xử lý lỗi mạnh mẽ.
• Tốt nhất cho: Các quy trình công việc liên quan nhiều đến việc xâu chuỗi các API dựa trên HTTP, cả trong và ngoài hệ sinh thái Google Cloud.

Ví dụ đoạn mã YAML cho một chuỗi đơn giản:

main: params: [args] steps: - first_step: call: http.post args: url: https://example.com/myFirstFunction body: input: ${args.input} result: firstResult - second_step: call: http.post args: url: https://example.com/mySecondFunction body: data: ${firstResult.body} result: finalResult - return_value: return: ${finalResult.body}

Một Kịch bản Frontend Thực tế: Quy trình công việc Onboarding người dùng

Hãy liên kết mọi thứ lại với nhau bằng một ví dụ thực tế, phổ biến: một người dùng mới đăng ký ứng dụng của bạn. Các bước bắt buộc là:

1. Tạo bản ghi người dùng trong cơ sở dữ liệu chính.
2. Song song:
   • Gửi email chào mừng.
   • Chạy kiểm tra gian lận dựa trên IP và email của người dùng.
3. Nếu kiểm tra gian lận vượt qua, hãy tạo đăng ký dùng thử trong hệ thống thanh toán.
4. Nếu kiểm tra gian lận không thành công, hãy gắn cờ tài khoản và thông báo cho nhóm hỗ trợ.
5. Trả về thông báo thành công hoặc thất bại cho người dùng.

Giải pháp 1: Cách tiếp cận do Frontend điều khiển 'Ngây thơ'

Nếu không có BFF được điều phối, client frontend sẽ phải quản lý logic này. Nó sẽ thực hiện một chuỗi các cuộc gọi API:

1. `POST /api/users` -> đợi phản hồi.
2. `POST /api/emails/welcome` -> chạy trong nền.
3. `POST /api/fraud-check` -> đợi phản hồi.
4. `if/else` phía client dựa trên phản hồi kiểm tra gian lận:
5. Nếu vượt qua: `POST /api/subscriptions/trial`.
6. Nếu không thành công: `POST /api/users/flag`.

Cách tiếp cận này có nhiều sai sót:

• Dễ vỡ và nhiều cuộc trò chuyện: Client được liên kết chặt chẽ với quy trình backend. Mọi thay đổi đối với quy trình công việc đều yêu cầu triển khai frontend. Nó cũng thực hiện nhiều yêu cầu mạng.
• Không có tính toàn vẹn trong giao dịch: Điều gì sẽ xảy ra nếu việc tạo đăng ký không thành công sau khi bản ghi người dùng đã được tạo? Hệ thống hiện ở trạng thái không nhất quán và client phải xử lý logic hoàn nguyên phức tạp.
• Trải nghiệm người dùng kém: Người dùng phải đợi nhiều cuộc gọi mạng tuần tự hoàn thành.
• Rủi ro bảo mật: Việc hiển thị các API chi tiết như `flag-user` hoặc `create-trial` trực tiếp cho client có thể là một lỗ hổng bảo mật.

Giải pháp 2: Cách tiếp cận BFF Serverless được điều phối

Với một dịch vụ điều phối, kiến trúc được cải thiện đáng kể. Frontend chỉ thực hiện một cuộc gọi API an toàn duy nhất:

POST /api/onboarding

Điểm cuối API Gateway này kích hoạt một máy trạng thái (ví dụ: trong AWS Step Functions). Người điều phối đảm nhận và thực thi quy trình công việc:

1. Trạng thái Bắt đầu: Nhận dữ liệu người dùng từ cuộc gọi API.
2. Tạo Bản ghi Người dùng (Tác vụ): Gọi một hàm Lambda để tạo người dùng trong DynamoDB hoặc cơ sở dữ liệu quan hệ.
3. Trạng thái Song song: Thực thi hai nhánh đồng thời.
   • Nhánh 1 (Email): Gọi một hàm Lambda hoặc chủ đề SNS để gửi email chào mừng.
   • Nhánh 2 (Kiểm tra gian lận): Gọi một hàm Lambda gọi một dịch vụ phát hiện gian lận của bên thứ ba.
4. Trạng thái Lựa chọn (Logic phân nhánh): Kiểm tra kết quả của bước kiểm tra gian lận.
   • Nếu `fraud_score < threshold` (Vượt qua): Chuyển sang trạng thái 'Tạo Đăng ký'.
   • Nếu `fraud_score >= threshold` (Không thành công): Chuyển sang trạng thái 'Gắn cờ Tài khoản'.
5. Tạo Đăng ký (Tác vụ): Gọi một hàm Lambda để tương tác với API Stripe hoặc Braintree. Khi thành công, chuyển sang trạng thái kết thúc 'Thành công'.
6. Gắn cờ Tài khoản (Tác vụ): Gọi một Lambda để cập nhật bản ghi người dùng và sau đó gọi một Lambda hoặc chủ đề SNS khác để thông báo cho nhóm hỗ trợ. Chuyển sang trạng thái kết thúc 'Không thành công'.
7. Trạng thái Kết thúc (Thành công/Không thành công): Quy trình công việc kết thúc, trả về thông báo thành công hoặc thất bại rõ ràng thông qua API Gateway cho frontend.

Những lợi ích của cách tiếp cận được điều phối này là rất lớn:

• Frontend đơn giản hóa: Công việc duy nhất của client là thực hiện một cuộc gọi và xử lý một phản hồi. Tất cả logic phức tạp được đóng gói trong backend.
• Khả năng phục hồi và độ tin cậy: Người điều phối có thể tự động thử lại các bước không thành công (ví dụ: nếu API thanh toán tạm thời không khả dụng). Toàn bộ quá trình là giao dịch.
• Khả năng hiển thị và gỡ lỗi: Các trình điều phối được quản lý cung cấp nhật ký trực quan chi tiết của mọi lần thực thi, giúp dễ dàng xem quy trình công việc đã thất bại ở đâu và tại sao.
• Khả năng bảo trì: Logic quy trình công việc được tách biệt với logic nghiệp vụ bên trong các hàm. Bạn có thể thay đổi quy trình công việc (ví dụ: thêm một bước mới) mà không cần chạm vào bất kỳ hàm Lambda riêng lẻ nào.
• Bảo mật nâng cao: Frontend chỉ tương tác với một điểm cuối API được bảo mật. Các hàm chi tiết và quyền của chúng bị ẩn trong VPC hoặc mạng backend.

Các phương pháp hay nhất để Điều phối Serverless Frontend

Khi bạn áp dụng các mẫu này, hãy ghi nhớ các phương pháp hay nhất toàn cầu này để đảm bảo kiến trúc của bạn vẫn sạch sẽ và hiệu quả.

• Giữ cho các Hàm chi tiết và không trạng thái: Mỗi hàm phải thực hiện tốt một việc (Nguyên tắc Trách nhiệm Duy nhất). Tránh để các hàm duy trì trạng thái của riêng chúng; đây là công việc của người điều phối.
• Để Trình điều phối Quản lý Trạng thái: Không chuyển tải trọng JSON lớn, phức tạp từ hàm này sang hàm khác. Thay vào đó, hãy chuyển dữ liệu tối thiểu (như `userID` hoặc `orderID`) và để mỗi hàm tìm nạp dữ liệu mà nó cần. Người điều phối là nguồn gốc của sự thật cho trạng thái của quy trình công việc.
• Thiết kế để Tính chất bất biến: Đảm bảo rằng các hàm của bạn có thể được thử lại một cách an toàn mà không gây ra các tác dụng phụ không mong muốn. Ví dụ: một hàm `createUser` nên kiểm tra xem người dùng có email đó đã tồn tại hay chưa trước khi cố gắng tạo một người dùng mới. Điều này ngăn chặn các bản ghi trùng lặp nếu người điều phối thử lại bước.
• Triển khai Ghi nhật ký và Truy nguyên Toàn diện: Sử dụng các công cụ như AWS X-Ray, Azure Application Insights hoặc Google Cloud Trace để có được chế độ xem thống nhất về một yêu cầu khi nó di chuyển qua API Gateway, trình điều phối và nhiều hàm. Ghi lại ID thực thi từ người điều phối trong mọi lệnh gọi hàm.
• Bảo mật Quy trình công việc của bạn: Sử dụng nguyên tắc đặc quyền tối thiểu. Vai trò IAM của người điều phối chỉ có quyền gọi các hàm cụ thể trong quy trình công việc của nó. Đổi lại, mỗi hàm chỉ có các quyền cần thiết để thực hiện tác vụ của mình (ví dụ: đọc/ghi vào một bảng cơ sở dữ liệu cụ thể).
• Biết Khi nào để Điều phối: Đừng lạm dụng kỹ thuật. Đối với một chuỗi A -> B đơn giản, việc gọi trực tiếp có thể đủ. Nhưng ngay khi bạn giới thiệu phân nhánh, các tác vụ song song hoặc nhu cầu xử lý lỗi và thử lại mạnh mẽ, một dịch vụ điều phối chuyên dụng sẽ giúp bạn tiết kiệm thời gian đáng kể và ngăn ngừa các vấn đề trong tương lai.

Kết luận: Xây dựng thế hệ trải nghiệm Frontend tiếp theo

Tổ hợp và điều phối hàm không chỉ là những mối quan tâm về cơ sở hạ tầng backend; chúng là những người cho phép cơ bản để xây dựng các ứng dụng frontend hiện đại tinh vi, đáng tin cậy và có khả năng mở rộng. Bằng cách di chuyển logic quy trình công việc phức tạp từ client sang một Backend-for-Frontend được điều phối, serverless, bạn trao quyền cho các nhóm frontend của mình tập trung vào những gì họ làm tốt nhất: tạo ra trải nghiệm người dùng đặc biệt.

Mô hình kiến trúc này đơn giản hóa client, tập trung hóa logic quy trình kinh doanh, cải thiện khả năng phục hồi của hệ thống và cung cấp khả năng hiển thị vô song vào các quy trình công việc quan trọng nhất của ứng dụng của bạn. Cho dù bạn chọn sức mạnh khai báo của AWS Step Functions và Google Cloud Workflows hay tính linh hoạt ưu tiên mã của Azure Durable Functions, việc chấp nhận điều phối là một khoản đầu tư chiến lược vào sức khỏe và sự nhanh nhẹn lâu dài của kiến trúc frontend của bạn.

Kỷ nguyên serverless đã đến và nó không chỉ nói về các hàm. Đó là về việc xây dựng các hệ thống mạnh mẽ, hướng sự kiện. Bằng cách thành thạo tổ hợp và điều phối, bạn sẽ mở khóa toàn bộ tiềm năng của mô hình này, mở đường cho thế hệ ứng dụng có khả năng phục hồi, có thể mở rộng trên toàn cầu tiếp theo.