Spring Cloud Gateway for Centralized API Routing

The Role of an API Gateway

An API Gateway is a server that acts as a single entry point into a system. It's an architectural pattern that sits between the client applications and the collection of backend microservices.

The key responsibilities of a gateway include:

• Reverse Proxy & Routing: It forwards client requests to the appropriate backend service.
• Single Point of Entry: Clients only need to know the address of the gateway, not every individual microservice.
• Cross-Cutting Concerns: It's the perfect place to handle logic that applies to multiple services, such as authentication, SSL termination, rate limiting, logging, and caching.

Step 1: Creating Your First API Gateway

Let's create a new Spring Boot application to act as our gateway.

1. Create the Project: Navigate to start.spring.io.
2. Add Dependencies: You will need two key dependencies:
   • Gateway: This includes the core Spring Cloud Gateway functionality.
   • Eureka Discovery Client: This allows our gateway to connect to the Eureka server we built in the previous lesson, enabling it to discover other services.
3. Generate and open the project in your IDE.

Step 2: Configuring Routes

The primary job of our gateway is routing. A Route in Spring Cloud Gateway is defined by an ID, a destination URI, a collection of Predicates, and a collection of Filters.

• Predicate: A condition that must be met for the route to be matched. For example, "does the request path match /api/users/**?".
• Filter: An action to modify the request or response. For example, "add a header to the request" or "rewrite the path before forwarding".

We will explore two ways to configure routes: using the application.yml file and using the Java Fluent API.

Method 1: Static Routing with application.yml

This is the most common approach. We'll start by configuring a route to the service-a we built in the previous lesson.

First, let's configure our gateway application itself. Open src/main/resources/application.properties, rename it to application.yml, and add the following configuration:

# Give the gateway application a name and port
server:
  port: 8080
spring:
  application:
    name: api-gateway

# Tell the gateway where to find the Eureka server
eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/

Now, let's add our first route. We'll statically route requests from /service-a/** on the gateway to our service-a microservice. Assume for a moment service-a is running on localhost:8081.

spring:
  # ... (other properties) ...
  cloud:
    gateway:
      routes:
        - id: service-a-route # A unique ID for the route
          uri: http://localhost:8081 # The destination
          predicates:
            - Path=/service-a/** # If the path starts with /service-a

This configuration tells the gateway: "If a request comes in with a path like /service-a/hello, forward it to http://localhost:8081/service-a/hello".

spring:
  cloud:
    gateway:
      routes:
        - id: service-a-route
          uri: http://localhost:8081
          predicates:
            - Path=/service-a/**
          filters:
            - StripPrefix=1

Method 2: Dynamic Routing with Eureka

The static configuration above has a flaw: we've hardcoded the address http://localhost:8081. This defeats the purpose of our service registry! The better way is to tell the gateway to look up the service's address from Eureka.

To do this, we modify the uri and use the special lb:// (load-balancer) protocol. This tells the gateway to use the service ID from Eureka.

spring:
  cloud:
    gateway:
      routes:
        - id: service-a-route
          uri: lb://service-a  # Use Eureka service ID!
          predicates:
            - Path=/service-a/**
          filters:
            - StripPrefix=1 # Remove '/service-a' before forwarding

        - id: service-b-route
          uri: lb://service-b
          predicates:
            - Path=/service-b/**
          filters:
            - StripPrefix=1 # Remove '/service-b' before forwarding

With this setup, the gateway will ask Eureka for the current location of service-a or service-b and route the request dynamically. This is much more resilient.

Test Your Setup

1. Start your Eureka Server.
2. Start service-a (from the previous lesson, which has a /hello endpoint).
3. Start service-b (from the previous lesson, which has a /call-a endpoint).
4. Start your new api-gateway application.
5. Open your browser and navigate to http://localhost:8080/service-a/hello. You should see "Hello from Service A!".
6. Now navigate to http://localhost:8080/service-b/call-a. You should again see "Hello from Service A!", demonstrating that the gateway routed to service-b, which then called service-a via Eureka.

Step 3: Alternative Configuration with the Java Fluent API

For more complex or conditional routing logic, you can define routes programmatically in a Java configuration file.

Create a new Java class for this configuration:

package com.example.apigateway;

import org.springframework.cloud.gateway.route.RouteLocator;
import org.springframework.cloud.gateway.route.builder.RouteLocatorBuilder;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class GatewayConfig {

    @Bean
    public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {
        return builder.routes()
                .route("service-a-java-route", r -> r.path("/service-a/**")
                        .filters(f -> f.stripPrefix(1))
                        .uri("lb://service-a"))
                .route("service-b-java-route", r -> r.path("/service-b/**")
                        .filters(f -> f.stripPrefix(1))
                        .uri("lb://service-b"))
                .build();
    }
}

Note: You should typically choose one method of configuration (YAML or Java) for clarity, but they can be combined. If a route is defined in both, the Java configuration often takes precedence.

Step 4: Monitoring Your Gateway Routes

How can you be sure your routes are loaded correctly? If you included the Spring Boot Actuator dependency, Spring Cloud Gateway provides a helpful endpoint.

Navigate to http://localhost:8080/actuator/gateway/routes.

You will see a JSON response detailing all the routes currently active in your gateway, including their predicates and filters. This is an invaluable tool for debugging.

Conclusion

Fantastic work! You have now established a proper entry point into your microservices ecosystem. By centralizing request handling with an API Gateway, you've made your system more secure, manageable, and easier for client applications to consume.

Key Takeaways:

• An API Gateway acts as a reverse proxy and single entry point for a microservices architecture.
• Spring Cloud Gateway allows you to define Routes that consist of Predicates (conditions) and Filters (actions).
• Routes can be configured declaratively in application.yml or programmatically using the Java Fluent API.
• For a resilient system, you should use dynamic routing by integrating the gateway with a service registry like Eureka, using the lb://<service-name> URI format.
• The /actuator/gateway/routes endpoint is essential for monitoring and debugging your gateway's configuration.

What's Next?

Our gateway can now successfully route traffic into our system. The next step is to refine how our services talk to each other. In the upcoming lesson, "Implement synchronous inter-service communication using RestTemplate or Feign," we will dive deeper into the RestTemplate we used previously and introduce a powerful, declarative alternative called Feign Client, which makes writing inter-service communication code even cleaner and simpler.