Can client-side call frontend microservices bypassing API gateway?

Question

Our system is build using microservices, that all sit behind an API gateway. Since all of them are REST API services, the benefits and whole point of using API gateway is clear to me. Now what about frontend microservices - the small components, that have both UI and corresponding backend to handle internal communication? Are there any scenarios where proxying every microservice HTTP calls is harmful?

Example

One of our microservice is a payment provider integration. As dealing with payments have specific regulations, one of those is a required web browser redirect to the user's bank page for authorization. Since this is impossible to do in a purely backend way, we deliver a frontend microservice - a service that essentially serves a HTML you must nest inside an iframe and should be able to process the payment in an e2e way. Very simplified and stripped example below.

Let's say you are on https://acme.com/order and want to pay, where such snippet is embedded:

<iframe src="https://pay.acme.com?amount=42+USD
                                 &returnUrl=https://acme.com/thankyou/[orderId]">
</iframe>

Basically a fire and forget thing for the developers of https://acme.com. What happens inside an iframe stays there. https://pay.acme.com however now worries about: collecting credit card details, validating them, redirecting user to the bank page to enter 2FA code or whatever needed, waiting until the payment is approved and finally moving user back to the returnUrl with a proper trail for which order the payment was finalized (orderId).

Now, what about pay.acme.com frontend <-> pay.acme.com backend communication? Would it be OK to let microservice talk to itself, or rather all, even the internal communication that doesn't make any sense for API consumers, must go through the API gateway? That is of course possible to do and still keep the microservice decoupled and unaware of the API gateway, but this is much more costful than deviating from the always do constraint and bring very small benefits, as we don't use any advanced rate limiting or proxying features for now.

Answer 1

There is simple approach - To have UI gateway. Gateway that instead of API calls will route and proxy asset request calls (static files serving).

If entities belong to the same bounded context (pay.acme.com frontend <-> pay.acme.com backend) they should definitely exist as single backend microservice that serves one of:

• isomorphic js
• thin client apps with real-time reload (then UI gateway will need to proxy ws connection)
• thick client app (SPA)

Such microservice is regular microservice which API (if exists) should be accessible through API gateway, and UI should be proxied via UI proxy/gateway.

Hope that helps.