Microservices application boundary types
A microservices architecture is an approach of building a server application as a set of small services. This type of architecture is mainly oriented to the back-end, although it can also be used on front-end.
While building a microservice we need to carefully design boundaries of microservices. A boundary layer provides a façade over the complex interactions inside the microservice.
Let's explore three different patterns.
# API gateways
An API gateway provides an extra layer, a single client-entry point over a service-oriented back-end. An API gateway takes all API calls from clients, then routes them to the appropriate microservice with request routing, composition, and protocol translation. Typically it handles a request by invoking one or more microservices and combining the results into a unified, seamless experience for the user.
Sitting in front of APIs, the gateway acts as protector, enforcing security and ensuring scalability and high availability. An API gateway can restrict the microservices which external consumers can access within the protected architecture as well as control the bandwidth which flows into the system.
Rather than provide a one-size-fits-all style API, the API gateway can expose a different API for each client.
# Backends for frontends (BFF)
In the Backend for Frontend pattern, a service (“the backend”) serves as a termination point for a requesting interface (“the frontend”). BFF is a variation on the API gateway approach.
A BFF can be used to elegantly expose complex backend systems to multiple client-facing platforms, such as iOS and the web, without building a monolothic API that attempts to serve all clients equally.
As BFF is tightly coupled to a specific user experience, it will typically be maintained by the same team as the user interface. Having this in mind it will be easier to define and adapt the API as the UI requires. As a result, each backend will be smaller, less complex and likely faster (and more decoupled) than a generic backend that tries to satisfy the requirements for all interfaces, because each backend is specific to one user interface.
# Consumer driven gateways
In both previous approaches, the API gateway determines the structure of the data returned to the consumer. In order to serve different clients, you might choose to build unique backends. But, you can also flip things around — build a gateway that allows consumers to express exactly what data they need from the service.
Think of it as a variation of BFF approach, building a single "super-set" API that allows consumers to define the shape of response they require. Most popular libraries using this approach are GraphQL an Apollo.
