When I asked this question why UI is hitting APIs all over different microservices instead of a single fronting microservice, the API Team responded that the Authorization Server (Keycloak) is already another microservice, so UI has to cater to two different microservices in any case, hence it doesn't matter to cater to other microservice too.
They responded that they follow Hexagonal Architecture, I skimmed through it and didn't find anything related to not having a single fronting microservice/or the UI can hit many microservices.
Am I missing something? Can you guys help me with some good documentation to understand this ?
First of all, let's make sure it's clear that your client-side is able to communicate with multiple APIs as long as it properly authenticates (for those where authentication is needed). Of course you could add a middleware that the UI communicates with and which on its turn pass the requests you send and responds to you with the response it receives so you would communicate with a single API. But it's not a matter of abilities, but a matter of approach. And such a middleware would unify the communication with the microservices and that would defeat the purpose of Hexagonal Architecture, which is all about loosely coupling the application controllers.
The hexagonal architecture, or ports and adapters architecture, is an architectural pattern used in software design. It aims at creating loosely coupled application components that can be easily connected to their software environment by means of ports and adapters.
By definition, your middleware would make them strongly coupled from the perspective of the UI even if they are loosely coupled inside the backend. It is a pattern that defies the purpose of separation of concerns as that would imply the build of a monolith middleware that strongly couples the microservices and make them interconnect for the purpose of the UI.