Team,
I was an evaluating architecture and it seems that the architecture plans to have a BFF like GraphQL sitting before API Gateway like APIGEE. Just to add, the backend microservices are written in Spring Boot.
Does it make sense to have both BFF and APIGEE? Is there anything that can't be handled via GraphQL which has to be taken care of by the API Gateway?
Thanks
Ashish
In case you missed that API Gateway is now available: https://cloud.google.com/api-gateway/docs/about-api-gateway
I am also currently running a Cloud Run service (kotlin/spring-boot) with a GraphQL endpoint and will try to bring it together with the API Gateway (beta)
Related
I am working on a distributed application project where there is need for rate limiting and authentication depending on the client consuming the service on an api gateway. I am wondering the best solution for designing the gateway.
Should I go with Spring cloud gateway or Spring Cloud function/AWS Lambda to create the gateway service?
I'd argue that using AWS API Gateway will make your life easier...
The benefits of using AWS API Gateway are:
it will remove all the operational cost of maintaining, configuring, monitoring and operating a Spring Cloud Gateway instance,
it will be highly available, with failover,
it will give you instant features like rate limiting, api keys, caching, authorization, canary testing, proxying, integration mapping, environments
it is very very cheap ($3.50 x MM requests).
The benefits of using Spring Cloud Function:
Define your API's as code within the application code itself
Leverage the ecosystem integration within Spring, for example, to run it locally on a dev's PC.
Cons of using API Gateway:
Deployment of new API's will be harder than using Spring Cloud Gateway (you need to configure each new resource/method)
Your costs are now tied to the number of requests... if you have a 900.000.000 millons/months API it could get expensive
Vendor lock-in
Cons of using Spring Cloud Function:
Operative cost of maintenance
Single point of failure
You can use Amazon API Gateway.
For more info on request throttling and quotas, please refer to the docs:
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html
I will rather use Istio gateway Envoy proxy rather than both options if permitted. Keeping my operational and maintenance cost little and no code change.
I have developed my microservices in springboot, want to implement API gateway in it.
My frontend is Angular.
Read in detail from here:
https://spring.io/guides/gs/gateway/
(All about how to create and config gateway in spring-boot.)
I'm wondering what to do with an API Endpoint when using a API Gateway. For example when you following the tutorial here: https://wiredcraft.com/blog/securing-components-in-a-microservice-context
You are using keycloak and kong (api-gateway) to secure the api. With kong you're getting an new Endpoint under http://localhost:8000/data. But the "original" express Server is still listening on http://localhost:3001/data.
That means that when a user/attacker knows the url of the "orignal" service and doesn't use the kong url (port 8000) he/she can still work with the api.
So my question is about the strategy and what to do with the original api? How could that be secured. Shall we implement the keycloak request on the api as well? But where are the benefits of kong then?
Your API gateway gives you a single entrypoint that simplifies how client applications access your services. You could add keycloak security on the gateway and not on the services behind - perhaps if you've a setup where you can block network access for clients to any services except the gateway. But even then you might still want the gateway and keycloak on the services behind.
The reason you might put keycloak on the services behind is because they are likely to need to know the identity of the user making the request. If they are going to read the token anyway then it might be most straightforward to add keycloak to them. And you'd still want the gateway to simplify life for clients. You'd then also want the gateway to forward the token to the services behind the gateway. (We're using keycloak and spring cloud gateway on the Activiti Cloud project and this is essentially how we decided to secure the services themselves with keycloak and have the gateway forward the token to them.)
My understanding is that API gateway pattern is like a proxy to all microservices. So client calls the API gateway which takes care of further routing. BFF is a specific case of API gateway pattern where we have a routing mechanism for each type of client. Am I right?
Yes, it is a specific case of API Gateway. For me this comment was helpful for understanding. It says you may think about the following cases when we are talking about API Gateway - Client relationships:
A single API gateway providing a single API for all clients.
A single API gateway provides an API for each kind of client.
A per-client API gateway providing each client with an API. This is the BFF pattern.
I'm trying to understand if it's possible to use KONG as API Gateway to microservices implementing REST and/or GraphQL interfaces
As API Gateway will expose a GraphQL API and will request to our microservices currently implemented in REST/GraphQL and grpc coming soon.
It can route the Graphql as any other HTTP request but it doesn't parse graphql to route each bit to a a specific service
Kong can front any RESTful API and through a transformation plugin you should be able to deal with GraphQL API as well.