Microservices
- Microservices offer a streamlined approach to software development that accelerates deployment, encourages innovation, enhances maintainability, and boosts scalability. This method relies on small, loosely coupled services that communicate through well-defined APIs, which are managed by autonomous teams. Adopting microservices offers benefits, such as improved scalability, resilience, flexibility, and faster development cycles
Developers mostly use the strangler design pattern to incrementally transform a monolith application to microservices. This is accomplished by replacing old functionality with a new service — and, consequently, this is how the pattern receives its name. Once the new service is ready to be executed, the old service is “strangled” so the new one can take over.
To accomplish this successful transfer from monolith to microservices, a facade interface is used by developers that allows them to expose individual services and functions. The targeted functions are broken free from the monolith so they can be “strangled” and replaced.
To fully understand this specific pattern, it’s helpful to understand how monolith applications differ from microservices.
Centralizes external access to your microservices, simplifying communication and providing a single entry point for client requests.
An aggregator design pattern is used to collect pieces of data from various microservices and returns an aggregate for processing. Although similar to the backend-for-frontend (BFF) design pattern, an aggregator is more generic and not explicitly used for UI.
To complete tasks, the aggregator pattern receives a request and sends out requests to multiple services, based on the tasks it was assigned. Once every service has answered the requests, this design pattern combines the results and initiates a response to the original request.
Creates dedicated backend services for each frontend, optimizing performance and user experience tailored to each platform.
read more
BFF Provides Exclusivity - in providing features based on the client type (web/mobile/partner integration)
Think of the user-facing application as being two components — a client-side application living outside your perimeter and a server-side component (BFF) inside your perimeter. BFF is a variant of the API Gateway pattern, but it also provides an additional layer between microservices and each client type separately. Instead of a single point of entry, it introduces multiple gateways. Because of that, you can have a tailored API that targets the needs of each client (mobile, web, desktop, voice assistant, etc.), and remove a lot of the bloat caused by keeping it all in one place. The below image describes how it works.
Why BFF?
Decoupling of Backend and Frontend for sure gives us faster time to market as frontend teams can have dedicated backend teams serving their unique needs. The release of new features of one frontend does not affect the other.
We can much easier maintain and modify APIs and even provide API versioning dedicated for specific frontend, which is a big plus from a mobile app perspective as many users do not update the app immediately.
Simplify the system from Frontend and Backend perspectives as we don’t need any compromise.
The BFF can benefit from hiding unnecessary or sensitive data before transferring it to the frontend application interface, so keys and tokens for 3rd party services can be stored and used from BFF.
Allows to send formatted data to frontend and because of that can minimalize logic on it.
Additionally, give us possibilities for performance improvements and good optimization for mobile.
Fault tolerance in BFF
Fault tolerance is the most significant power of BFF allows us to handle most of the problems on the BFF layer instead of the client (frontend). In case of any microservice change, it can be controlled by all BFFs without emergency deployment of frontend clients. We all know that update of the mobile application on both stores is not an easy operation. It requires some additional time like review, which is not easy to estimate, and sometimes even its output can be a surprise — rejection. With BFF solution, we can cover versioning and backward compatibility separately per each client (frontend). Whole fault tolerance and strategies for that can be covered and managed in the BFF layer. For example, in our system, we can introduce separate BFF for each mobile client and avoid problems when one of them has some issues that affect the whole system, such as doing some self DDoS. In that case, we can disconnect this BFF from the system and investigate the problem inside of it without affecting the rest of the system. This is for sure a good strategy for BFFs dedicated for 3rd party services.
When to use BFF?
-
Consider BFF when you plan to extend the number of frontend types, it will make sense if and when you a significant amount of aggregation required on the server side.
-
If your application needs to develop an optimized backend for a specific frontend interface or your clients need to consume data that require aggregation on the backend, BFF is for sure a suitable option. Of course, you might reconsider if the cost of deploying additional BFFs’ services is high, but even then the separation of concerns that a BFF can bring make it a fairly compelling proposition in most cases.
-
https://medium.com/mobilepeople/backend-for-frontend-pattern-why-you-need-to-know-it-46f94ce420b0
Enables microservices to dynamically discover and communicate with each other, simplifying service orchestration and enhancing system scalability.
Implements a fault-tolerant mechanism for microservices, preventing cascading failures by automatically detecting and isolating faulty services.
Enhances microservices' resilience by automatically retrying failed operations, increasing the chances of successful execution and minimizing transient issues.
Attaches additional components to your microservices, providing modular functionality without altering the core service itself.
Manages distributed transactions across multiple microservices, ensuring data consistency while maintaining the autonomy of your services.
A saga is a series of local transactions. In microservices applications, a saga patterncan help maintain data consistency during distributed transactions.
The saga pattern is an alternative solution to other design patterns that allows for multiple transactions by giving rollback opportunities.
Separates the read and write operations in a microservice, improving performance, scalability, and maintainability.
- Focus on UI/UX and data needed by them.
- Don’t try to make everything generic from the beginning; this may cause that component to be used across organizations and many people will want to contribute.
- Use particular feature first over generic usage strategy. This is the best approach to keep clean API dedicated to one client.
- Use the gold rule of three - Refer here for definition.