Post History

Normally gateways just do routing and maybe load balancing. That's one well-defined job that can be done well. You are adding a second job, which is to be a universal adapter.

An adapter would be easier to implement as a common library. Then you don't have to bloat the gateway with adapter logic, and the library is easier to modularize - it's unlikely that each of your microservices needs to connect to each external service.

You mentioned the issue with multiple languages but this is easily solved by creating bindings for each language. There's probably not that many languages in circulation.

If you really don't want a library, the protocol adapter should be its own microservice. This would be service whose _one job_ is to be a man in the middle between external (routed via the gateway) and internal services. The nice thing is that you can have a single adapter, or you can break it up into separate ones as much as you want. You can assign different resources to each one, autoscale them independently, and when one adapter goes down it doesn't also kill all routing across your system. This would be more aligned with the microservice philosophy.