Microservices, API Gateways, and Frontends [closed]

Question

I have recently begun exploring the concept of microservices and API gateways and am particularly confused on how frontend endpoints should be hosted.

If I have an API gateway that acts as the middleman between requests to all of my services, where exactly should the frontend be hosted? If I request /api/example, I understand that my API gateway should route that to the appropriate service and forward that services response. I do not understand however, how an API gateway should handle /home/ in a microservice context. In this case, we want to deliver html/css/javascript corresponding to /home/ to the client making the GET request. Does this mean that we should have some sort of frontend service? Won't creating a service that just returns HTML/CSS/JS be redundant and add increased latency, since all we really need to do is just immediately return the HTML/CSS/JS associated with our frontend?

An alternative I was thinking about was to have the API gateway itself provide endpoints that return the HTML/CSS/JS required for the client to render the frontend. In other words, the API gateway could just immediately respond with the HTML corresponding to /home/ when receiving a GET request to /home/ rather than calling a service. However, I read online that API gateways should not be actually serving endpoints, rather just proxying them to services.

That is my main question: Where should frontend code go when your backend is built out using a microservice architecture?

Answer 1

I assume your frontend is Single Page Application. SPA has static content like HTML, CSS, images, fonts etc. It is the perfect candidate to be deployed as static website that gets data from backend using REST APIs.

In cloud environments like AWS, GCP it is recommended to host SPA applications separately from REST APIs. e.g. in AWS SPA can be deployed in Amazon S3 and it remains directly accessible without going through API gateway.

API gateway is supposed to be used to only route REST API calls and performing cross cutting concerns such as authentication etc. However the problem with this approach is that you will get CORS error while hitting REST APIs from frontend because SPA and API gateway will be hosted on different domains. To overcome this issue CORS need to be enabled at API gateway.

If you are looking for simpler solution, frontend can be served from a service through API gateway. Since static content is served only once in SPA it should be okay to start with this approach for simpler applications.

https://aws.amazon.com/blogs/apn/how-to-integrate-rest-apis-with-single-page-apps-and-secure-them-using-auth0-part-1/

https://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html

Answer 2

API Gateway as you have already mentioned should act as a proxy/router with minimal logic. And as the name says it all, its main purpose is to expose API and not GUI components/pages for different types of clients and address some of the non-functional aspects e.g. security. Provide high-level API [use case driven] based on requesting client[basically BFF/Backend for Frontend approach].

When it comes to having frontend/GUI fittin to microservices, you can think of having UI Gateway/Container which is backed by Micro FrontEnds. Also, refer to MF's site for details on micro frontends.

So, following microservices architecture for frontend, your frontend code should reside in micro frontends along with other microservices.