How common are wrapper services/APIs in a microservice architecture? From my personal experience, it feels like it's an anti-pattern but perhaps I am missing some details?
I am working on splitting up a tightly coupled architecture into a microservice setup. Hence, each service will have its own database if needed, otherwise fully stateless.
The client uses some 3rd party integrations that have their own service, since they all provide similar but differently formatted responses. The client is insisting on building a wrapper service on top of all integrations that would be responsible for calling the said integrations (like a proxy service) and map the responses to a common model.
I can perhaps see what the added value of the consistent response is (although it can be achieved differently) but I am having a hard time finding pro arguments to be on board with the wrapper idea.
Also, these integrations do not need to always be there - one customer can decide how many and which integrations they are willing to pay for.
The only serious reason (as in, the other ones are because a programmer thinks its cool, or has been reading blogs on the internet) is if you think the API should be interchangeable with another providing the same service and you will want to cater for that. eg if you have a Google search integration and you think you might want to swap it for Bing at some time.
Otherwise you're just making work for yourself, YAGNI style. You may think you want a common interface so clients can call any of the services with the same code, but all you've done is shift the effort of calling the service to a proxy - not actually saved yourself anything, just moved it elsewhere.
So YMMV depending on your circumstances, but ask yourself what business benefits this would achieve.