The Microservice Architecture is an architecture that combines applications with the following characteristics

• Loosely coupled, Highly cohesive
• Can be deployed independently
• Bounded by a business domain
• Accessible via some communication protocol
• Developed by an autonomous team

If you want to know more about Microservice Architecture, please refer to the book Building Microservices.

In this section, I'll show you some of the patterns in communicating with Microservices, focusing on the Frontend.

Service Discovery

Service Discovery is a pattern that creates an abstraction layer of multiple interfaces on the Frontend side and interacts with the Backend.

The pattern is to create a layer that abstracts multiple interfaces on the Frontend and interact with the Backend.

For example, you can imagine JSON like the following. In practice, you may want to create a layer of abstraction for the request, such as a Repository Pattern.

{
  "micro_service_foo": {
    "v1": "https://api.foo.service.com/v1",
    "special": "https://api.foo.service.com/special"
  },
  "micro_service_bar": {
    "v1": "https://api.bar.service.com/v1",
    "v2": "https://api.bar.service.com/v2"
  }
}

One of the nice things about Service Discovery is that you can freely combine them in the Frontend; in the context of Micro Frontends, multiple components may each request different Microservices, and it may be convenient to change them freely in the App Shell layer.

We can also get JSON returned by the API.

In this case, it is easier to do version upgrades or changes on the server side. This pattern is inspired by Client-side service discovery used in Backend Microservices.

Gateway Aggregation

Gateway Aggregation is a pattern that combines requests to multiple Microservices into a single endpoint (API Gateway) (from Microsoft Cloud Design Patterns.

The abstraction layer at the client, as it was in Service Discovery, is gone and simplified, and performance overhead is improved.

Backends for Frontends

Backends for Frontends (BFF) is a pattern that is similar to Gateway Aggregation, but provides an interface for each specific Frontend application (from Microsoft Cloud Design Patterns).

With Gateway Aggregation, we had the following problems.

• Different data that different Frontend teams wants causes the data manipulation process in Frontend.
• Data that is only used by one application can be added to the interface, which can be redundant.
• Difficulty in updating Backend APIs by considering all platforms.

The goal of this pattern is to provide a more application-specific interface, so that the interactions are optimized for each of them.

The case of Netflix

Netflix is using GraphQL Federation for their API Gateway.

• How Netflix Scales its API with GraphQL Federation | Netflix TechBlog

For more information on GraphQL Federation, please see the following

• Introduction to Apollo Federation - Apollo Federation - Apollo GraphQL Docs
• Apollo Federation specification - Apollo Federation - Apollo GraphQL Docs

Netflix is facing the following problems with a simple API Gateway

• Lack of domain knowledge on the part of the Gateway team
• The connection to the Gateway had to be done manually.
• A lot of things to do for the Gateway team due to the above

In order to solve this problem, they have taken an approach to merge each schema with GraphQL Federation and reduce the scope of responsibility of Gateway. In the end, the architecture became the following "federated gateway architecture" to realize One Graph API.

Each Microservices team, which is familiar with the domain, provides its own schema, and the Gateway team is responsible for managing the Graph. I feel that this leads to the topic of "Who develops the BFF?" which will be discussed later.

Pros and Cons

One of the topics of creating an API Gateway is "Who will develop the API Gateway?". For example, if you are creating a BFF, it seems correct for the Frontend engineer to have a responsibility of it, but in reality, you will consider the engineer's skills and development costs.

Another topic is the common function; in a BFF, only application-specific logic should be placed, but there may be an increase in duplicated code in multiple BFFs. For these, the basic idea is Duplication over the wrong abstraction, but how should it be extracted? Should we really extract them? Which team will be responsible for it? These will be a point of discussion. It is also necessary to design it so that it is loosely coupled with the Microservices it calls.

In the context of Micro Frontends, we could be talking about, at what level do you want to use the API Gateway? or should use Service Discovery?

Summary

In this article, we introduced how to interact with Microservices from the Frontend in the recent situation.

Instead of interacting with multiple Microservices directly, there is a trend to abstract the complexity by providing one interface for one Frontend app.