Myujth

I have a micro-service project with multiple services in .NET Core. When it comes to placing the controllers, there are 2 approaches:

1. Place the controllers in respective Micro Services, with Startup.cs in each micro-service.


2. Place all controllers in a separate project and have them call the individual services.

I think the 1st approach will involve less coding effort but the 2nd one separates controllers from actual services using interfaces etc.
Is there a difference in terms of how they are created and managed in Fabric using both approaches.

This is very broad topic and can raise points for discussion because it all depends on preferences, experiences and tech stacks. I will add my two cents, but do not consider it as a rule, just my view for both approaches.

First approach (APIs for each service isolated from each other):

• the services will expose their public APIs themselves and you will need to put a service discovery approach in place to enable clients to call each microservice, a simple one is using the reverse proxy to forward the calls using the service name.


• Each service and it's APIs scales independently


• This approach is better to deploy individual updates without taking down other microservices.


• This approach tends to have more code repetition to handle authorization, authentication, and other common aspects, from there you will end up doing shared libraries using on all services.


• This approach increase the points of failures, it is good because failures will affect less services, if one API is failing, other services won't be impacted (if the failure does not affect the machine like memory leak or high CPU usage).

The second approach (Single API to forward the calls to right services):

• You have a single endpoint and the service discovery will happen in the API, all work will be handled by each services.


• The API must scale for everyone even though one service consumes much more resources than others. just the service will scale independently.


• This approach, to add or modify api endpoints, you will likely update the API and the service, taking down the API will affect other services.


• This approach reduces the code duplication and you can centralize many common aspects like Authorization, request throttling and so on.


• This approach has less points of failures, if one microservices goes down, and a good amount of calls depend on this service, the API will handle more connection and pending requests, this will affect other services and performance. If it goes down, every services will be unavailable. Compared to the first approach, the first approach will offloaded the resilience to the proxy or to the client.

In summary,
both approaches will have a similar effort, the difference is that the effort will be split into different areas, you should evaluate both and consider which one to maintain. Don't consider just code in the comparison, because code has very little impact on the overall solution when compared with other aspects like release, monitoring, logging, security, performance.

In our current project we have a public facing API. We have several individual microservice projects for each domain. Being individual allows us to scale according to the resources each microservice use. For example we have an imaging service that consumes a lot of resources, so scaling this is easier. You also have the chance to deploy them individually and if any service fails it doesn't break the whole application.

In front of all the microservices we have an API Gateway that handles all the authentication, throttles, versioning, health checks, metrics, logging etc. We have interfaces for each microservice, and keep the Request and Response models seperately for each context. There is no business logic on this layer, and you also have the chance to aggregate responses where several services need to be called.

If you would like to ask anything about this structure please feel free to ask.