Frontend API Gateway: Làm chủ Schema Federation và Stitching với GraphQL

Trong bối cảnh phát triển web hiện đại không ngừng thay đổi, việc áp dụng kiến trúc microservices đã trở thành nền tảng để xây dựng các ứng dụng có khả năng mở rộng, linh hoạt và dễ bảo trì. Khi hệ thống phát triển và đa dạng hóa, việc quản lý vô số dịch vụ độc lập có thể đặt ra những thách thức đáng kể, đặc biệt đối với các đội ngũ frontend. Đây là lúc sức mạnh của GraphQL, kết hợp với các chiến lược API gateway tinh vi như schema federation và stitching, thực sự tỏa sáng.

Hướng dẫn toàn diện này đi sâu vào sự phức tạp của việc tận dụng GraphQL làm một frontend API gateway, với sự phân tích sâu về các khái niệm quan trọng của schema federation và schema stitching. Chúng ta sẽ khám phá cách những kỹ thuật này cho phép tạo ra một API GraphQL hợp nhất, mạnh mẽ từ các schema microservice riêng lẻ, qua đó hợp lý hóa quá trình phát triển frontend, cải thiện hiệu suất và thúc đẩy trải nghiệm tốt hơn cho các nhà phát triển trong các đội ngũ toàn cầu.

Sự trỗi dậy của Microservices và Thách thức đối với Frontend

Kiến trúc microservices mang lại nhiều lợi ích, bao gồm việc triển khai độc lập, đa dạng công nghệ và cách ly lỗi. Tuy nhiên, đối với các ứng dụng frontend, bản chất phân tán này có thể làm tăng độ phức tạp. Các nhà phát triển frontend thường phải tương tác với nhiều dịch vụ backend, mỗi dịch vụ lại có thiết kế API, định dạng dữ liệu và giao thức giao tiếp riêng. Điều này có thể dẫn đến:

• Tăng số lượng yêu cầu mạng: Việc lấy dữ liệu thường đòi hỏi nhiều lượt đi và về đến các dịch vụ khác nhau.
• Phức tạp trong việc tổng hợp dữ liệu: Các đội ngũ frontend phải tự kết hợp dữ liệu từ nhiều nguồn khác nhau.
• Khớp nối chặt chẽ (Tight coupling): Những thay đổi trong các dịch vụ backend có thể gây ảnh hưởng không tương xứng đến frontend.
• Sự mệt mỏi của nhà phát triển: Gánh nặng quản lý nhiều tương tác API có thể làm chậm chu kỳ phát triển.

Sự xuất hiện của mẫu thiết kế Backend for Frontend (BFF) đã tìm cách giải quyết một số vấn đề này bằng cách tạo ra các dịch vụ backend được tùy chỉnh cho các client frontend cụ thể. Mặc dù hiệu quả, cách tiếp cận BFF thuần túy đôi khi có thể dẫn đến sự gia tăng của các dịch vụ backend, làm tăng gánh nặng bảo trì. GraphQL mang đến một giải pháp thay thế hấp dẫn, cung cấp một endpoint duy nhất để client truy vấn chính xác dữ liệu họ cần, giảm thiểu việc lấy thừa (over-fetching) và thiếu (under-fetching) dữ liệu.

GraphQL như một Frontend API Gateway

GraphQL, với khả năng tìm nạp dữ liệu theo kiểu khai báo, có một vị trí độc đáo để hoạt động như một lớp tổng hợp trong môi trường microservices. Thay vì trực tiếp sử dụng nhiều REST API hoặc dịch vụ gRPC, các client frontend tương tác với một endpoint GraphQL duy nhất. Endpoint GraphQL này, hoạt động như một API Gateway, sau đó có thể giải quyết các truy vấn bằng cách điều phối các yêu cầu đến các microservice bên dưới.

Thách thức cốt lõi sau đó là làm thế nào để xây dựng schema GraphQL hợp nhất này từ các schema riêng lẻ của các microservice của bạn. Đây chính là lúc schema federation và schema stitching phát huy tác dụng.

Tìm hiểu về Schema Stitching

Schema stitching, một trong những cách tiếp cận sớm hơn để kết hợp các schema GraphQL, bao gồm việc hợp nhất nhiều schema GraphQL thành một schema duy nhất, συνεκτικός. Ý tưởng cốt lõi là lấy các schema từ các dịch vụ GraphQL khác nhau và kết hợp chúng, thường bằng cách thêm các type và field từ schema này vào schema khác.

Cách Schema Stitching hoạt động:

Schema stitching thường bao gồm:

1. Lấy các Sub-schema: Gateway stitching sẽ lấy schema introspection từ mỗi microservice GraphQL bên dưới.
2. Hợp nhất các Schema: Một thư viện (như hàm graphql-tools' mergeSchemas) sẽ hợp nhất các sub-schema này. Quá trình này bao gồm việc giải quyết các xung đột tiềm ẩn, chẳng hạn như tên type bị trùng lặp, và định nghĩa cách các type từ các schema khác nhau liên quan đến nhau.
3. Giải quyết các truy vấn xuyên Schema: Khi một truy vấn cần dữ liệu từ nhiều dịch vụ, gateway stitching phải được cấu hình để ủy quyền các phần của truy vấn đến dịch vụ bên dưới phù hợp. Điều này thường bao gồm việc định nghĩa 'remote schemas' và chuyển tiếp các truy vấn.

Các khái niệm chính trong Schema Stitching:

• Type Merging (Hợp nhất Type): Cho phép các type có cùng tên trong các schema khác nhau được kết hợp lại.
• Schema Extensions (Mở rộng Schema): Thêm các field từ một schema vào một type được định nghĩa trong schema khác. Ví dụ, thêm một field reviews vào một type Product được định nghĩa trong một dịch vụ sản phẩm riêng biệt.
• Delegation (Ủy quyền): Cơ chế cốt lõi để chuyển tiếp các phần của một truy vấn GraphQL đến dịch vụ GraphQL bên dưới phù hợp.

Ưu điểm của Schema Stitching:

• Đơn giản cho các dự án nhỏ: Có thể dễ dàng triển khai cho một số lượng dịch vụ hạn chế.
• Linh hoạt: Cho phép kiểm soát chi tiết về cách các schema được kết hợp.

Nhược điểm của Schema Stitching:

• Cấu hình thủ công: Có thể trở nên phức tạp và dễ gây lỗi khi số lượng dịch vụ tăng lên.
• Nguy cơ xung đột: Việc quản lý các xung đột về tên type và field đòi hỏi phải lập kế hoạch cẩn thận.
• Vấn đề về hiệu suất: Việc ủy quyền không hiệu quả có thể dẫn đến các điểm nghẽn về hiệu suất.
• Khớp nối chặt chẽ: Gateway thường cần phải biết về các triển khai dịch vụ bên dưới, tạo ra một hình thức khớp nối.

Giới thiệu về Schema Federation

Schema federation nổi lên như một giải pháp mạnh mẽ và có khả năng mở rộng tốt hơn cho các thách thức mà schema stitching gặp phải, đặc biệt là trong các kiến trúc microservice lớn, phân tán. Được phát triển chủ yếu bởi Apollo, schema federation cho phép bạn xây dựng một API GraphQL duy nhất từ nhiều dịch vụ GraphQL độc lập, được gọi là subgraphs.

Sự khác biệt cơ bản nằm ở cách tiếp cận của nó đối với việc tổng hợp schema. Thay vì hợp nhất các schema hiện có, schema federation định nghĩa một giao thức nơi các subgraph khai báo các type và field của chúng, và một gateway trung tâm (router hoặc supergraph) sẽ tổng hợp các khai báo này thành một schema hợp nhất. Việc tổng hợp này diễn ra mà gateway không cần biết chi tiết về việc triển khai của mỗi subgraph, chỉ cần biết hợp đồng schema của nó.

Cách Schema Federation hoạt động:

Schema federation bao gồm:

1. Subgraphs: Mỗi microservice cung cấp một API GraphQL tuân thủ đặc tả federation. Các subgraph khai báo các type của chúng bằng cách sử dụng các chỉ thị (directive) federation cụ thể (ví dụ: @key, @extends, @external, @requires, @provides).
2. Supergraph: Một router federation (như Apollo Federation Gateway) truy vấn mỗi subgraph để lấy định nghĩa schema của nó. Sau đó, nó tổng hợp các định nghĩa này thành một schema duy nhất, hợp nhất – gọi là supergraph.
3. Entity Resolution (Giải quyết thực thể): Chìa khóa của federation là khái niệm về entities (thực thể). Một thực thể là một type có thể được xác định duy nhất trên nhiều subgraph. Chỉ thị @key trên một type trong một subgraph đánh dấu nó là một thực thể và chỉ định các field xác định duy nhất nó. Khi một truy vấn tham chiếu đến một thực thể, gateway biết subgraph nào chịu trách nhiệm lấy thực thể đó dựa trên chỉ thị @key của nó.
4. Composition (Tổng hợp): Gateway điều phối các truy vấn. Nếu một truy vấn yêu cầu dữ liệu từ nhiều subgraph, gateway sẽ thông minh chia nhỏ truy vấn và gửi các truy vấn con phù hợp đến mỗi subgraph, sau đó kết hợp các kết quả lại.

Các khái niệm chính trong Schema Federation:

• Subgraphs: Các dịch vụ GraphQL độc lập đóng góp vào supergraph.
• Supergraph: Schema hợp nhất được tổng hợp từ tất cả các subgraph.
• Entities (Thực thể): Các type có thể được xác định duy nhất trên các subgraph, thường được đánh dấu bằng chỉ thị @key.
• Chỉ thị @key: Định nghĩa các field xác định duy nhất một thực thể. Điều này rất quan trọng cho các mối quan hệ xuyên subgraph.
• Chỉ thị @extends: Cho phép một subgraph mở rộng một type được định nghĩa trong một subgraph khác (ví dụ: thêm các field vào một type User được định nghĩa trong một subgraph User riêng biệt).
• Chỉ thị @external: Cho biết một field được định nghĩa trên một subgraph khác.
• Chỉ thị @requires: Chỉ định rằng một field trên một thực thể yêu cầu một số field nhất định từ khóa của thực thể phải có mặt để được giải quyết.
• Chỉ thị @provides: Cho biết rằng một field trên một thực thể được cung cấp bởi subgraph.

Ưu điểm của Schema Federation:

• Khả năng mở rộng: Được thiết kế cho các hệ thống lớn, phân tán và số lượng microservice ngày càng tăng.
• Tách rời (Decoupling): Các subgraph chỉ cần biết schema của riêng chúng và cách giải quyết các type của chúng. Gateway sẽ xử lý việc tổng hợp.
• Sự tự chủ của đội ngũ: Các đội ngũ khác nhau có thể sở hữu và quản lý các subgraph tương ứng của họ một cách độc lập.
• An toàn về kiểu (Type safety): Quá trình tổng hợp thực thi các hợp đồng schema, đảm bảo an toàn về kiểu trên toàn bộ supergraph.
• Trải nghiệm client được đơn giản hóa: Client tương tác với một schema duy nhất, hợp nhất.

Nhược điểm của Schema Federation:

• Đường cong học tập: Yêu cầu hiểu biết về đặc tả và các chỉ thị của federation.
• Phụ thuộc vào công cụ: Thường dựa vào các thư viện và gateway cụ thể (ví dụ: Apollo Federation).
• Phức tạp trong thiết lập ban đầu: Việc thiết lập các subgraph và gateway có thể phức tạp hơn so với stitching đơn giản.

Federation và Stitching: So sánh tổng quan

Trong khi cả schema federation và schema stitching đều nhằm mục đích hợp nhất các schema GraphQL, chúng đại diện cho các triết lý khác nhau và mang lại những lợi thế riêng biệt:

Đối với hầu hết các kiến trúc microservice hiện đại hướng tới khả năng mở rộng lâu dài và sự tự chủ của đội ngũ, schema federation thường là cách tiếp cận được ưa chuộng. Schema stitching vẫn có thể là một lựa chọn khả thi cho các hệ thống nhỏ hơn, ít phức tạp hơn hoặc cho các kịch bản tích hợp cụ thể nơi mong muốn một sự hợp nhất thủ công, trực tiếp hơn.

Triển khai Schema Federation: Một ví dụ thực tế

Hãy xem xét một kịch bản thương mại điện tử đơn giản với hai microservices:

• Dịch vụ Người dùng (Users Service): Quản lý thông tin người dùng.
• Dịch vụ Sản phẩm (Products Service): Quản lý thông tin sản phẩm.

Subgraph của Dịch vụ Người dùng

Dịch vụ này định nghĩa một type User và đánh dấu nó là một thực thể (entity) với chỉ thị @key.

            # users-service/schema.graphql

# Federation directives
directive @key(fields: "id!") on OBJECT

type User @key(fields: "id") {
  id: ID!
  name: String
}

type Query {
  user(id: ID!): User
}

            

              
                Copy
              
            
          

Dịch vụ này cũng sẽ có các resolver để lấy dữ liệu người dùng dựa trên ID của họ.

Subgraph của Dịch vụ Sản phẩm

Dịch vụ này định nghĩa một type Product. Quan trọng hơn, nó cũng định nghĩa một mối quan hệ với thực thể User bằng cách thêm một field (ví dụ: createdBy) tham chiếu đến type User.

            # products-service/schema.graphql

# Federation directives
directive @key(fields: "id!") on OBJECT
directive @extends on OBJECT
directive @external on OBJECT
directive @requires(fields: "userId!") on FIELD_DEFINITION

type Product @extends {
  # We are extending the User type from the Users Service
  # The @external directive indicates 'id' is defined elsewhere
  createdBy: User @requires(fields: "userId")
}

type User @extends {
  # Declare that 'id' is an external field on User, defined in another subgraph
  id: ID! @external
}

type Query {
  product(id: ID!): Product
}

            

              
                Copy
              
            
          

Trong Dịch vụ Sản phẩm:

• @extends trên Product cho biết schema này mở rộng type Product.
• id: ID! @external trên User có nghĩa là field id của type User được định nghĩa trong một subgraph khác (Dịch vụ Người dùng).
• createdBy: User @requires(fields: "userId") trên Product có nghĩa là để giải quyết field createdBy (trả về một đối tượng User), dữ liệu sản phẩm phải chứa một userId. Gateway sẽ sử dụng thông tin này để biết cần yêu cầu những field nào từ dịch vụ sản phẩm và cách liên kết nó với dịch vụ người dùng.

Gateway Federation (Supergraph)

Gateway federation (ví dụ: Apollo Gateway) chịu trách nhiệm:

1. Khám phá các subgraph (thường bằng cách truy vấn schema introspection của chúng).
2. Tổng hợp các schema subgraph riêng lẻ thành một schema supergraph duy nhất.
3. Định tuyến các truy vấn đến từ client đến các subgraph phù hợp và kết hợp các kết quả.

Khi một client truy vấn một sản phẩm và tên người tạo ra nó:

            
query GetProductCreator($productId: ID!) {
  product(id: $productId) {
    id
    name
    createdBy {
      id
      name
    }
  }
}

            

              
                Copy
              
            
          

Gateway sẽ thực hiện các bước sau:

1. Nó thấy field product, được xử lý bởi Dịch vụ Sản phẩm.
2. Nó giải quyết field name từ type Product, cũng được xử lý bởi Dịch vụ Sản phẩm.
3. Nó gặp field createdBy trên Product. Vì createdBy được định nghĩa là một type User và type User có chỉ thị @key(fields: "id") trong Dịch vụ Người dùng, gateway biết rằng nó cần lấy thực thể User.
4. Chỉ thị @requires(fields: "userId") trên createdBy cho gateway biết rằng Dịch vụ Sản phẩm cần userId để giải quyết mối quan hệ này. Do đó, gateway sẽ yêu cầu sản phẩm và userId của nó từ Dịch vụ Sản phẩm.
5. Sử dụng userId đã lấy được, gateway sau đó biết phải truy vấn Dịch vụ Người dùng để tìm một người dùng với ID cụ thể đó.
6. Cuối cùng, nó giải quyết field name từ đối tượng User được trả về bởi Dịch vụ Người dùng.

Quá trình này minh họa cách schema federation kết nối liền mạch dữ liệu liên quan giữa các microservice khác nhau, cung cấp một trải nghiệm truy vấn hợp nhất và hiệu quả cho frontend.

Chọn Cách tiếp cận phù hợp cho Dự án của bạn

Quyết định giữa schema federation và schema stitching (hoặc thậm chí các mẫu API gateway khác) phụ thuộc rất nhiều vào các yêu cầu cụ thể của dự án, cấu trúc đội ngũ và tầm nhìn dài hạn của bạn.

Khi nào nên cân nhắc Schema Stitching:

• Dự án vừa và nhỏ: Nếu bạn có một số lượng giới hạn các microservice GraphQL và một mô hình dữ liệu đơn giản, stitching có thể là đủ và dễ thiết lập ban đầu hơn.
• Các dịch vụ GraphQL hiện có: Nếu bạn đã có một số dịch vụ GraphQL độc lập và muốn kết hợp chúng mà không cần tái cấu trúc đáng kể, stitching có thể là một con đường tích hợp nhanh hơn.
• Logic hợp nhất cụ thể: Khi bạn cần kiểm soát chi tiết về cách các schema được hợp nhất và các type được mở rộng, và sự phức tạp của federation có vẻ là quá mức cần thiết.

Khi nào nên chọn Schema Federation:

• Microservices quy mô lớn: Đối với các tổ chức có số lượng lớn microservice và đội ngũ, federation cung cấp khả năng mở rộng và cấu trúc tổ chức cần thiết.
• Sự tự chủ của đội ngũ là chìa khóa: Nếu các đội ngũ khác nhau chịu trách nhiệm cho các lĩnh vực khác nhau và cần phát triển các API GraphQL của họ một cách độc lập, federation cho phép sự tự chủ này.
• Khả năng bảo trì lâu dài: Các hợp đồng rõ ràng và mô hình tổng hợp của federation dẫn đến các hệ thống dễ bảo trì và linh hoạt hơn theo thời gian.
• Các mối quan hệ phức tạp: Khi mô hình dữ liệu của bạn bao gồm các mối quan hệ phức tạp giữa các thực thể được quản lý bởi các dịch vụ khác nhau, khả năng giải quyết thực thể của federation là vô giá.
• Áp dụng GraphQL dần dần: Federation cho phép bạn giới thiệu GraphQL một cách tăng dần. Các dịch vụ REST hiện có có thể được bọc trong các subgraph GraphQL, hoặc các dịch vụ GraphQL mới có thể được xây dựng như các subgraph ngay từ đầu.

Các Thực hành tốt nhất cho Frontend API Gateway với GraphQL

Bất kể bạn chọn federation hay cách tiếp cận stitching, việc áp dụng các thực hành tốt nhất là rất quan trọng để thành công:

• Định nghĩa Hợp đồng Rõ ràng: Đối với federation, các schema subgraph và việc sử dụng các chỉ thị như @key, @external, và @requires định nghĩa các hợp đồng này. Đối với stitching, các thỏa thuận về cách hợp nhất và ủy quyền là hợp đồng của bạn.
• Phiên bản hóa API của bạn: Triển khai một chiến lược phiên bản hóa rõ ràng cho các subgraph của bạn để quản lý các thay đổi một cách mượt mà.
• Giám sát Hiệu suất: Triển khai giám sát mạnh mẽ cho gateway và các subgraph của bạn. Theo dõi hiệu suất truy vấn, tỷ lệ lỗi và độ trễ. Các công cụ như Apollo Studio có thể là vô giá ở đây.
• Triển khai Caching: Tận dụng các chiến lược caching GraphQL ở cấp độ gateway hoặc client để cải thiện hiệu suất và giảm tải cho các dịch vụ backend của bạn.
• Bảo mật Gateway của bạn: Triển khai xác thực, phân quyền và giới hạn tỷ lệ yêu cầu (rate limiting) ở cấp độ API gateway để bảo vệ các dịch vụ backend của bạn.
• Tối ưu hóa Truy vấn: Hướng dẫn các nhà phát triển frontend về cách viết các truy vấn GraphQL hiệu quả để tránh lấy thừa dữ liệu hoặc các truy vấn lồng sâu có thể gây căng thẳng cho gateway và các subgraph.
• Công cụ và Tự động hóa: Sử dụng các công cụ để tạo schema, xác thực và tự động hóa triển khai để hợp lý hóa vòng đời phát triển.
• Tài liệu: Duy trì tài liệu cập nhật cho schema supergraph và các subgraph riêng lẻ. Các công cụ như GraphiQL và GraphQL Playground rất tuyệt vời để khám phá tương tác.
• Xử lý Lỗi: Triển khai các chiến lược xử lý lỗi nhất quán trên gateway và các subgraph của bạn.
• Kiểm thử: Đảm bảo kiểm thử kỹ lưỡng các subgraph và supergraph đã được tổng hợp để phát hiện sớm các vấn đề.

Các lưu ý Toàn cầu

Khi triển khai một chiến lược API gateway cho đối tượng người dùng toàn cầu, một số yếu tố trở nên quan trọng:

• Độ trễ: Thiết kế phân phối gateway và subgraph của bạn để giảm thiểu độ trễ cho người dùng ở các khu vực địa lý khác nhau. Cân nhắc sử dụng Mạng phân phối nội dung (CDN) cho các tài sản tĩnh và triển khai các phiên bản gateway gần hơn với cơ sở người dùng của bạn.
• Nơi lưu trữ dữ liệu và Tuân thủ: Hiểu rõ nơi dữ liệu của bạn được lưu trữ và xử lý. Đảm bảo cấu hình API gateway và subgraph của bạn tuân thủ các quy định về quyền riêng tư dữ liệu khu vực (ví dụ: GDPR, CCPA). Federation có thể giúp quản lý vị trí dữ liệu bằng cách để các subgraph xử lý dữ liệu liên quan đến các khu vực cụ thể.
• Tiền tệ và Bản địa hóa: Nếu ứng dụng của bạn xử lý dữ liệu tài chính hoặc nội dung được bản địa hóa, hãy đảm bảo schema GraphQL và các resolver của bạn có thể xử lý các loại tiền tệ, ngôn ngữ và định dạng ngày tháng khác nhau một cách phù hợp.
• Múi giờ: Lưu ý đến sự khác biệt về múi giờ khi xử lý và hiển thị dữ liệu nhạy cảm về thời gian.
• Mở rộng cơ sở hạ tầng: Lập kế hoạch mở rộng gateway và các subgraph của bạn để xử lý các mô hình lưu lượng truy cập toàn cầu biến động.

Tương lai của GraphQL Gateways

Hệ sinh thái GraphQL tiếp tục phát triển. Chúng ta đang chứng kiến những tiến bộ trong:

• Thông số kỹ thuật Federation được cải tiến: Sự phát triển không ngừng của đặc tả GraphQL Federation bởi Apollo và cộng đồng rộng lớn hơn đang dẫn đến những cách thức mạnh mẽ và chuẩn hóa hơn để xây dựng các API GraphQL phân tán.
• Các dịch vụ GraphQL được quản lý: Các nhà cung cấp đám mây và dịch vụ của bên thứ ba đang cung cấp các giải pháp gateway GraphQL được quản lý, đơn giản hóa việc triển khai và vận hành.
• Thư viện và Công cụ mới: Sự phát triển của các công cụ và thư viện mới để xây dựng, kiểm thử và giám sát các gateway và subgraph GraphQL đang làm cho việc áp dụng trở nên dễ dàng và hiệu quả hơn.
• GraphQL Mesh: Các công cụ mới nổi như GraphQL Mesh nhằm mục đích trừu tượng hóa sự phức tạp của các nguồn dữ liệu khác nhau (REST, gRPC, GraphQL, OpenAPI) và cho phép chúng được phục vụ như một API GraphQL hợp nhất, cung cấp một giải pháp thay thế cho federation truyền thống cho các nhu cầu tích hợp rộng hơn.

Kết luận

Khi các tổ chức ngày càng áp dụng kiến trúc microservices, nhu cầu về các chiến lược API gateway hiệu quả trở nên tối quan trọng. GraphQL, với khả năng truy vấn mạnh mẽ, cung cấp một giải pháp thanh lịch, và schema federation nổi bật như là cách tiếp cận có khả năng mở rộng và bảo trì tốt nhất để hợp nhất các microservice GraphQL riêng lẻ.

Bằng cách hiểu các nguyên tắc của schema federation và stitching, và bằng cách áp dụng các thực hành tốt nhất cho việc triển khai và vận hành toàn cầu, các đội ngũ frontend có thể hợp lý hóa đáng kể quy trình phát triển của mình, xây dựng các ứng dụng linh hoạt hơn và mang lại trải nghiệm người dùng đặc biệt. Cho dù bạn đang bắt đầu một dự án mới hay phát triển một hệ thống microservices hiện có, đầu tư vào một API gateway GraphQL được kiến trúc tốt, được cung cấp bởi federation là một bước đi chiến lược hướng tới việc xây dựng thế hệ tiếp theo của các ứng dụng mạnh mẽ, có khả năng mở rộng và lấy người dùng làm trung tâm.

Những điểm chính cần nhớ:

• GraphQL hoạt động như một API gateway mạnh mẽ cho microservices.
• Schema Federation xây dựng một supergraph hợp nhất từ các subgraph độc lập bằng cách sử dụng một giao thức hợp đồng rõ ràng.
• Schema Stitching hợp nhất các schema hiện có, cung cấp nhiều quyền kiểm soát thủ công hơn nhưng ít khả năng mở rộng hơn cho các hệ thống lớn.
• Federation thường được ưa chuộng hơn vì khả năng mở rộng, tách rời và sự tự chủ của đội ngũ.
• Các thực hành tốt nhất bao gồm hợp đồng rõ ràng, giám sát, bảo mật và các lưu ý toàn cầu.

Việc nắm bắt những khái niệm này sẽ trao quyền cho các đội ngũ phát triển của bạn để điều hướng sự phức tạp của microservices và xây dựng các ứng dụng vừa mạnh mẽ vừa có khả năng thích ứng với các yêu cầu luôn thay đổi của bối cảnh kỹ thuật số toàn cầu.