I have 2 microservices. In one of them, I expose an API to geolocate a point via GMaps.
So now I'm in this situation:
- Service 1, where the geolocation API is deployed, needs information from Service 2.
- Service 2, in some cases, needs to geolocate its data.
I can't reference my application contract from Service 1 in Service 2, and at the same time, I can't add the contract from Service 1 to Service 2. I tried to call my HttpClient from the Domain, but I can't check permissions and still have a 401 issue.
So my questions are:
- Is it correct to call a service (via HttpClient) in the Domain module? Or is it better to call HttpClient only from the Application?
- In this case, do I need to redesign the architecture and isolate my geolocation service to be called separately by Service 1 and Service 2? Or should I call it via EventBus? If I call it via EventBus, I don't need to import permissions in the application contract.
5 Answer(s)
-
0
You can check the document
https://docs.abp.io/en/commercial/latest/startup-templates/microservice/interservice-communication
-
0
I’ve checked the documentation, but it’s not clear and the pattern we need to solve is not covered. My question is more related to best practices and potential bottlenecks.
-
0
Hi,
I don't know much about your solution structure and user cases.
I would suggest that services not depend on each other, you can consider refactoring the structure.
I can't add the contract from Service 1 to Service 2. I tried to call my HttpClient from the Domain, but I can't check permissions and still have a 401 issue.
You need to add the current user's access_token to the request header
-
0
When you say ‘I would suggest that services not depend on each other,’ do you mean that each service must be independent? Should I use events via a buffer to get data from other services? But generally speaking, if I need to check the stock level and the stock level is managed by the stock service, how can I achieve that?
-
0
Hi,
I mean don't rely on each other, they can one-way dependency
