How to deal with bad third party APIs in a microservices architecture?

Question

I'm currently in the process of transforming a monolithic application to a microservices based architecture. The monolith is dependent on third party services (as in other departments) for its data. Most of these third party services are accessible via SOAP while some of them use REST.

Some of these third party services have terrible (even unusable IMO) APIs. It adds a lot of unneeded complexity and boilerplate to our aggregator service (which is a monolith atm). I'm in the process of mapping the domain of one of these third-party APIs to a usable domain in an ACL to be able to offer a decent API to our aggregator service.

However, it got me wondering. Is this even the correct way to go? It's a lot of work, should I just bite the bullet and use those terrible APIs? How do you handle terrible third-party APIs in a microservices architecture which make your service less maintainable?

Thanks in advance!

Answer 1

I encounter this type of thing all the time, there are some unbelievable commercial SOAP/XML APIs out there. What I normally do is basically two things:

1. Define a facade for the functionality my service actually needs. This is a simplified interface that exposes the things my service cares about in a consumable way.
2. Create an adapter between the external service and the facade. This adapter interfaces with the terrible 3rd-party service and hides all of the detail. It then implements the facade interface that my service consumes, so all my service knows is how to use the facade.

This has worked pretty well for me, and it has the added benefit that if you ever move away from the terrible service to a better one, you can simply implement a new adapter without changing anything else, since your service will still just consume the facade.

Answer 2

Yes, you should have a microservice to call/hide the third party API. That service's job is to know how to call the third party API. Not only because it's messy, but to avoid carrying the idiosyncrasies and implementation details of the third party service into your design. Also, this gives you a chance at abstraction or generalization. You can then switch out the API or even switch to a different technology behind the scenes.

Such microservices are often doable without persistence, don't change a lot, and will not require much maintenance once created. It will allow you to drive your own best practices, like having a health check endpoint, token authorization, etc. into that domain instead of their domain dictating it.