Client per MicroService vs Generic Client | Who is responsible for microservice client?

Question

I have a microService architecture with 10 microServices and each of those provides a client. Inside of that client which is managed/controlled by microService team we just receive the parameters and pass them to a generic http invoker which receives the endpoint and N params and then does the call. All microService use http and web api (I guess technology doesn't matter).

For me doesn't make sense to be the microService team to provide a client, should be the responsibility of the consumer, if they want to create some abstractions or invoke it directly is their problem, not a microService problem. And the way I see a web API is as a contract. So I think we should delete all clients (pass responsibility to consumers) on the microService side and create a service layer on the consumer's side that uses the generic invoker to reach the endpoints.

The image below represents all components where the red line defines the boundaries, who is responsible for what:

• The gateway has Adapter Layer
• Adapter Layer references the microService client package
• MicroService client package references Generic HTTP invoker package

The other side of that is because we might have N number of consumers and they are all repeating the code of the client. And if the microService provides a client, we have a unique/central place to control that.

Which approach is correct? Is the client a responsability of the microService or the consumer?

This is an internal product.

Answer 1

I have a similar setup at work, with several microservices (~40) and a dozen teams. I was asked the same question several times, and my answer is the consumer is responsible for consuming. If the API works as designed and expected, there is no point in making the providing team responsible for anything.

The team that provides the service (team a), may provide a client, if they want (in doubt, without warranty). The consuming team (team B) may use the client if they want (taking all the risks included). The only contract should be the API, everything else should be a goodie a team may provide on top. If team a has to provide a client, why do they provide an api at all then?

Given that both teams are loosely coupled and may use different technologies (or e.g. different spring framework versions), providing a client library to the other team proves to bring more problems than solve any. In a Java+spring-boot world e.g. you get into dependency problems very fast, especially if you include several clients from different service providing teams that evolve differently in time.

And even worse: what if the client-library of team A makes the system of team B unstable and introduces bugs? Who is responsible to fix that now?

If you want to reduce the work needed for your consuming teams because re-coding the client is so much work, your API may be to complex and/or your microservice may be no more microservice at all. Imagine using HATEOAS on a restful API - writing a client for that is just a few lines of code, even with included API-Browser, Documentation and whatnot. See e.g. spring-rest-docs, hal-browser, swagger and various other technologies that make reading/browsing/documenting an API and implementing a client a breeze.

Above cases are described with two teams, imagine that with 10. We had a "client library" provided by one team, used by 4 other teams. You can guess how fast it became a complete mess until it was just deleted :)