Why do microservices need an API client sdk for HTTP and Messaging?
How does microservice usage ramp up?
Microservice usage scales very fast. At first, a single service is the APIs. Suddenly there is a bunch.
Each implements the same methods to access the same rest APIs. Each one of them would implement contract testing.
This is a wasted effort.
API Client SDK
We can, as an alternative, create one client code and let everyone use it. Or one client in each programming language that uses it.
This gives us the following advantage:
- Only the client code deals with the format of the API.
- Only the client code needs to be contract tested.
- If the endpoints of the API change, only the client code needs to be changed.
- We can create a single @Value for the base URL for the client and inject it via a config server for all applications.
- If we need to add micrometer-prometheus usage metrics for an API, we have one destination.
- If we need to retire an API, we just add @deprecated and release the client.
The client would also include:
- Request validation: To avoid unnecessary network calls.
- Request Body POJOs: So that everyone uses the same format.
- Response Body POJOs.
- Standard Exception handling
The same can be used for messaging like Kafka, where the client can include POJOs format and methods to publish messages in case of incoming webhooks.
In conclusion, an API client would help reduce the efforts of all developers in developing and using an API. The developers using the client need not be concerned with how the API works internally, weather it works on REST, Graph QL, gRPC, etc. They just need to send and receive data in using the right client provided POJOs.