Microservice to Microservice Architecure using gRPC : .NET Core

userzy3i1 0
Viewed 71

So I've this Microservice architecture where there is an ApiGateway, 2 microservices i.e., Configurations. API and API-1. The Configuration. API is mainly responsible to parse the JSON request and access the DB and update Status tables, also to fetch required data, it even adds up more values to the JSON request and send it to the API-1. API-1 is responsible to just generate report based on the json passed.

Yes I can merge the configurations. API to the API-1 and make it a single service/container but the requirement is not to merge and create two different components i.e., 1 component purely based on fetching the data, updating the status while the other just to generate the reports.

So here are some questions:

  • : Should I use gRPC for the configuration.API or is there a better way to achieve this.

Thank you.

grpc microservices asp.net asp.net-core api
1 Answers
  • RPC is a synchronous communication so you have to come up with strong reason to use it in service to service communication. it brings the fast and performant communication on the table but also coupling to the services. if you insist use rpc it is better to use MASSTRANSIT to implement the rpc in less coupled way. however in most cases the asynchronous event-base communication is recommended to avoid coupling (in that case look at CAP theory, SAGA, circuit breaker ).
  • since you said

but the requirement is not to merege and create two different components

and that is your reason and also base on the fact

also to fetch requried data, it even adds up more values to the JSON request and send it to the API-1

i think the second one makes scenes more. how ever i cant understand why you change the database position since you said the configuration service is responsible for that.

  • if your report service needs request huge data to generate report you have to think about the design. there is no more profile on you domain so there cannot be an absolute answer to this. but consider data reduce from insertion or request or some sort of pre-calculation if you could and also caching responses.
Rouzbeh Zarandi0
Related