การตั้งค่าและจัดการ Gateway

In GraphQL Federation, the Apollo Gateway acts as the central entry point for all client applications. Think of it as the brain that understands your entire supergraph.

It takes multiple independent GraphQL services (called subgraphs) and combines their schemas into one unified, client-facing schema.

With a microservices architecture, you might have many backend services, each with its own GraphQL API. Without a gateway, clients would need to know about and query each service individually.

• Unified Endpoint: Clients interact with a single GraphQL API.
• Schema Composition: The gateway automatically stitches together the schemas from all subgraphs.
• Simplified Client Logic: Clients don't need to know which service owns which data.

When a client sends a query to the gateway, here's what happens:

1. The gateway receives the query.
2. It analyzes the query against the composed supergraph schema.
3. It breaks down the query into smaller parts, determining which subgraph owns which piece of data.
4. It sends sub-queries to the relevant subgraphs.
5. It then combines the results from these subgraphs into a single response for the client.

While your subgraphs can be built with Spring Boot (or any other framework), the gateway itself is often implemented using Apollo's own tools.

The most common and robust implementation is the Apollo Server Gateway, which is a Node.js-based server designed specifically for federation. This lesson will focus on setting up this standard gateway.

Let's set up a minimal Apollo Gateway. First, create a new Node.js project and install the necessary packages:

Then, create an index.js file:

In the previous code, the serviceList array is crucial. It tells the gateway which subgraphs exist and where to find them. Each object in the array needs two properties:

• name: A unique identifier for the subgraph (e.g., "products").
• url: The endpoint where the subgraph's GraphQL API is running (e.g., "http://localhost:4001/graphql").

As you develop more microservices with GraphQL APIs, you simply add them to the serviceList. The gateway will automatically compose their schemas into the unified graph.

Here's how you'd add a reviews subgraph running on port 4002:

Once your index.js is set up, you can start the gateway:

The console will output the URL where your gateway is running, typically http://localhost:4000/. Open this URL in your browser to access the GraphQL Playground or GraphiQL interface provided by Apollo Server.

Clients will send their GraphQL queries directly to the gateway's URL. The gateway handles all the internal routing and data fetching from the subgraphs.

For example, a query combining data from both a products and reviews subgraph might look like this:

Beyond initial setup, managing your gateway involves several best practices:

• Deployment: Deploy the gateway as a standalone service, often alongside your subgraphs.
• Monitoring: Use tools to monitor its performance, error rates, and latency.
• Scaling: The gateway can be scaled horizontally to handle increased client traffic.
• Schema Changes: Ensure your gateway is configured to pick up schema updates from subgraphs reliably (e.g., via Apollo Studio or a local schema registry).

You've learned about the Apollo Gateway and its role in federation.

Congratulations! You've learned about the Apollo Gateway, a crucial component in GraphQL Federation. It provides a unified API endpoint for clients, seamlessly composing schemas from various subgraphs and routing queries effectively.

By configuring the serviceList, your gateway becomes the single source of truth for your entire supergraph, simplifying client interactions and enabling a robust microservices architecture.