I am using API gateway in order to make microservice resource publicly available.
I have the following situation (simplified as possible)
Microservice A - serve provides product prices on
/product-prices/{id}
Microservice B - provides product availability on
/product-availability/{id}
In order to get product price and availability I would either need to do the following
a) have Microservice A be dependent on Microservice B and have
/product-prices-and-availability/{id} endpoint
or
b) have API gateway consume Microservice A and Microservice B in order to provide price end availability resource
Basically my question is should I merge data on microservice level or on api gateway level?
Related
I am writing a microservice app by spring boot and spring cloud. I have five modules which are
API-Gateway (base on spring cloud gateway spect)
Discovery-Server (base on spring cloud Netflix Eureka service discovery)
Microservice-A (It is a spring boot app that includes our business)
Microservice-B (It is a spring boot app that includes our business)
Microservice-C (It is a spring boot app that includes our business)
All requests which come from users route to API gateway and through API gateway send to app A or B or C (these are not exposed out). Now I have a question, base on one business role, app A will need to call one rest endpoint of app B. Which approach is the best? I call app B endpoint from app A directly or I call by API-Gateway?
The API Gateway should serve as an ingress layer, it only accepts traffic which is coming from outside of your application (clients / external integrations). More details here.
Any internal communication between your microservices, should be a point-to-point interaction, that can be done in multiple ways. This answer describes that in more details.
So the API Gateway should not be concerned with orchestration of the microservices.
If I were you I'll use a message broker for microservices communication. Let the api gateway for external clients. I think we overuse the http protocol. With a microservice architecture we should try to think differently.
We have micro-services with the following architecture:
web-ui <-> graphQL <-> n * back-end services
We are implementing PACT consumer driven contract tests which is working well between the back-end services.
However there are questions on how to implement this through the graphQL layer. In reality this is a consumer of the back-end services, and a provider to the web-ui.
As the consumer, GraphQL doesn't have the domain information for the actual required json that is initiated from the web-ui service. Then the web-ui service doesn't test against the back-end providers (as the graphQL layer is its provider) - and it hasn't got that association / knowledge of the back-end services.
Is it that graphQL should create a PACT interaction with each back-end provider containing all its potential values with each service. Then this demonstrates that those interfaces remain compliant. Thus the real request (interaction) from the user (web-ui) has pacts with the GraphQL service (with mocks of the back-end services), so implicitly would work all the way through the stack.
Has anyone got advice of how this works across this aggregation layer?
The setup:
I have a set of Spring Boot based microservices that are fronted by Spring Cloud Gateway, meaning every request that comes from UI or external API client first comes to Spring Cloud Gateway and is then forwarded to appropriate microservice.
The routes are configured in Consul, and Spring Cloud Gateway communicates with Consul to get the routes accordingly.
Requirement:
There is a need of some microservices communicating with each other with REST APIs. I would prefer this communication to happen via the Spring Cloud Gateway as well. This will help in reducing multiple services going to Consul for getting other service's details.
This means every service should know Gateway's detail at least. And there can be multiple instances of Gateways as well. How is this dealt with in bigger architectures?
Any example that I look up contains one service using Consul, or Gateway using the consul with one microservice. Couldn't understand how to extrapolate that design to a bigger system.
I have a group of microservices built using Spring Boot and each registered to a Eureka instance. I also have a Zuul gateway built which does authentication / authorization layer for external requests coming into my microservices. External consumers are not allowed to consume my microservices directly and must go through Zuul. Let's assume that my microservices takes care of a grouped business domain called "Consumer Banking Channel".
Now, somewhere else in my organization there is another grouped domain called "Customer Relationships", where they have built another Eureka-based microservices network and have also configured Zuul to take care of authentication / authorization.
We want to consume each other's exposed API services and want to take advantage of service discovery to do that. However, we do not want to allow direct access to our microservices for security reasons and only want to allow the other group to access our services through our respective Zuuls.
How can this be accomplished?
One possible way that I thought of is to have a Spring Cloud Sidecar to register the other group's Zuul to our Eureka, but that approach does not really scale as the number of different Eureka networks in the organization grows (if we have 10 Eureka networks in the organization, we end up having to run 9 sidecars for each group, totaling up to 90 JVMs just for sidecar alone).
If we move the authentication / authorization layer down to individual microservices and create a big single Eureka network, that would make a big monolith of Zuul with different departments in the organization clashing on how to configure Zuul optimally, not ideal either.
I have read few details of use of api gateway in microservices architecture. I have read that it basically helps with security , transformation , throttling etc. Is orchestration also one of it responsibilities? When I read about microservices , I saw that it should have dumb pipes and smart endpoints and services must be choreographed and not orchestrated. So my assumption is that orchestration is not a responsibility of api gateway.
Probably no orchestation but there is a pattern called API Gateway
Using an API Gateway
Usually a much better approach is to use what is known as an API
Gateway. An API Gateway is a server that is the single entry point
into the system. It is similar to the Facade pattern from
object-oriented design. The API Gateway encapsulates the internal
system architecture and provides an API that is tailored to each
client. It might have other responsibilities such as authentication,
monitoring, load balancing, caching, request shaping and management,
and static response handling. pattern call API Gateway
https://www.nginx.com/blog/building-microservices-using-an-api-gateway/
http://microservices.io/patterns/apigateway.html?utm_source=building-microservices-using-an-api-gateway&utm_medium=blog
https://www.nginx.com/blog/microservices-reference-architecture-nginx-proxy-model/