Managing multiple routes in Spring Cloud Gateway - spring

Question

I know Spring Cloud Gateway has multiple ways to configure routes:
using a Java-based DSL (eg: using RouteLocatorBuilder) and/or
property based configuration.
The offical Spring Cloud Gateway docs use properties to manage routes.
My questions are:
It is simple to configure routes for 2-3 microservices in a single file, but how do enterprise applications with so many microservices manage routes efficiently?
What is the recommend way to configure routes?
If using Java DSL, is it a good practice to use multiple Beans with the same return type. something like:
#Bean
RouteLocator bookRouteLocator(RouteLocatorBuilder builder) {
return builder.routes()
.route("book_route", r -> r.method(HttpMethod.GET)
.and().path("/api/book/**")
.uri("lb://book-service"))
.build();
}
#Bean
RouteLocator chapterRouteLocator(RouteLocatorBuilder builder) {
return builder.routes()
.route("chapter_route", r -> r.method(HttpMethod.GET)
.and().path("/api/chapter/**")
.uri("lb://chapter-service"))
.build();
}

Answer 1

This is a decently old post but this is something I recently ran into and wanted to share a solution.
Exposing multiple beans will not work - those two RouteLocator instances will collide with each other causing an error or you can allow spring to override the other bean - either way, its not going to work for you.
Instead, expose a Router that references other classes that expose functions that create your routes. Here is an example in Kotlin
Routes.kt
#Configuration
class Routes(
private val purchaseRoute: PurchaseRoute
) {
#Bean
fun router(routeLocatorBuilder: RouteLocatorBuilder): RouteLocator {
return routeLocatorBuilder.routes()
.route("purchase", purchaseRoute.route())
.build()
}
}
Router.kt interface all sub-routes will implement
interface Router {
fun route(): Function<PredicateSpec, Buildable<Route>>
}
PurchaseRoute.kt
#Configuration
class PurchaseRoute() : Router {
override fun route(): Function<PredicateSpec, Buildable<Route>> =
Function {
it.path("/api/purchase/**")
it.filters {
stripPrefix(1)
dedupeResponseHeader("Access-Control-Allow-Origin", "RETAIN_FIRST")
}
it.uri(routeConfigProperties.uri)
}
}
Then just create as many route classes as you like. The separation into multiple files dramatically cleaned up a gateway service I maintain.