Does it make sense to abstract common client concerns in a separate API

Question

Recently I worked on different client side APIs, such as HTTP ReST client, messaging client, and a database client. In each case, the same concerns sprang up, which are the following:

• Connection pooling
• Async and non-blocking I/O with clean error handling
• Request retrying with backoff policy implementation (this is more the case for ReST and messaging)
• Request batching (this is more the case for databases)

The way I see it, the above concerns can be abstracted from the underlying request in a separate API. Furthermore, due to the complexity of coding the above concerns, it makes sense not to pay the cost multiple times.

Therefore, I would have expected to have a generic client helper API which would permit me to retry and batch any sort of request, all while performing all requests asynchronously. It would be kind of a task executor API, but without the other complexities (such as scheduling, since there is only one task that needs to be executed).

Hence my question, or am I missing something?

Answer 1

I would say to keep them separate. My guess is that you'll find 3rd party solutions for each of these, but I don't know of any libraries that would do all three.

I'm not sure if your programming in Java, but I think the apache project has done a good job at segmenting utilities in their commons-* libraries. You may want to draw some inspiration from there.

https://commons.apache.org/