An API Gateway serves as the front-door to your APIs providing features such as route matching and forwarding, rate limiting, path rewriting, circuit breaker patterns, security policy management, throttling, API version management, among other features.
Typically you will place the Gateway near the “edge” of your platform, and more often you might use the Cloud providers API Gateway or a commercial one. A robust API Gateway can scale to manage thousands of concurrent calls. Some of the features such as circuit breakers are required both at the edge of your API delivery, and also deeper down inside your architecture (in places such as Kubernetes sidecars with Istio). Architecture has multiple layers, with each layer having its own story to live by, and at times making some things seemingly duplicative in the stack.
An API Gateway can stand in front of a plethora of backend components and route to RESTful APIs, do some protocol translation to call older SOAP services, route calls to serverless functions, maybe do some protocol translation before sending the response back to caller, track API metrics (using say CloudWatch if you are in AWS), and maybe even provide a GraphQL layer. The last one is an interesting one. I do see GraphQL as a potential standalone component or part of an API Gateway. If your APIs are being accessed from multiple channels such as web, mobile, IoT, chatbots, IVR etc., then you might need to provide flexibility to the caller to only send back data that they want vs sending them 100s of useless fluff. The other (not pretty) approach is to stand up independent services for each channel. Having GraphQL at the entry door is an enabler feature, and thus my view that it also could belong in a robust API Gateway.
Spring API Gateway is a DIY gateway, that provides some of the features of a full featured one (or maybe all, since I have not done a 1:1 matchup yet). It is a valid question to ask, why would we use a DIY API Gateway vs from a Cloud Provider or commercial one. Like most things in tech the answer is “it depends”.
One reason could be that you want flexibility and ownership of every aspect of your architecture, and no dependencies with 3rd parties or you want to control costs, etc. Regardless if your path takes you to a DIY API Gateway then Spring API Gateway is an option you can consider.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
@Bean public RouteLocator myRoutes(RouteLocatorBuilder builder) { return builder.routes() // rewrite URL and route to my blog site .route(p -> p .path("/myblog") .filters(f -> f.setPath("/")) .uri(httpUri.getMyblog())) // rewrite URL and route to my spring guides site .route(p -> p .path("/spring") .filters(f -> f.setPath("/guides")) .uri(httpUri.getSpring())) // add request header before routing to httpbin .route(p -> p .path("/get") .filters(f -> f.addRequestHeader("Hello", "World")) .uri(httpUri.getHttpbin())) // apply the circuit breaker pattern to the route .route(p -> p .host("*.circuitbreaker.com") .filters(f -> f .circuitBreaker(config -> config.setFallbackUri("forward:/fallback"))) .uri(httpUri.getHttpbin())) .build(); } |
Once you have this running with “mvn clean spring-boot:run” you can try on of these to test this out…
|
1 2 3 4 5 6 7 8 |
// route Get to httpbin curl http://localhost:8080/get // circuit breaker curl --dump-header - --header 'Host: www.circuitbreaker.com' http://localhost:8080/delay/3 // route to my blog (with URL rewrite curl http://localhost:8080/myblog |
Code is in Git at https://github.com/thomasma/tryout-spring-api-gateway