Integration Design Patterns Flashcards
API Gateway Pattern
Summary:
Single point of entry for all clients while still using different APIs for each client. Requests are routed to appropriate services. API Gateway can also provide level of security. You can also break up API Gateways for types of clients. For example: Web App, Mobile and Public API for 3rd parties.
Detail:
When an application is broken down to smaller microservices, there are a few concerns that need to be addressed:
There are multiple calls for multiple microservices by different channels
There is a need for handling different type of Protocols
Different consumers might need a different format of the responses
An API Gateway helps to address many concerns raised by the microservice implementation, not limited to the ones above.
An API Gateway is the single point of entry for any microservice call.
It can work as a proxy service to route a request to the concerned microservice.
It can aggregate the results to send back to the consumer.
This solution can create a fine-grained API for each specific type of client.
It can also convert the protocol request and respond.
It can also offload the authentication/authorization responsibility of the microservice.
Aggregator Pattern
Summary:
When needing to aggregate data from multiple services to a caller (but not requiring 2PC transaction).
Detail:
When breaking the business functionality into several smaller logical pieces of code, it becomes necessary to think about how to collaborate the data returned by each service. This responsibility cannot be left with the consumer.
The Aggregator pattern helps to address this. It talks about how we can aggregate the data from different services and then send the final response to the consumer. This can be done in two ways:
A composite microservice will make calls to all the required microservices, consolidate the data, and transform the data before sending back.
An API Gateway can also partition the request to multiple microservices and aggregate the data before sending it to the consumer.
It is recommended if any business logic is to be applied, then choose a composite microservice. Otherwise, the API Gateway is the established solution.
https://dzone.com/articles/design-patterns-for-microservices
Proxy Pattern
Summary:
Essentially an Interface. When Aggregation isn’t needed, proxies can be used to scale or don’t want/need to directly expose API to consumer
Detail:
API gateway we just expose Microservices over API gateway. I allow to get API features such as security and categorizing APIs in GW. In this example, the API gateway has three API modules:
Mobile API, which implements the API for the FTGO mobile client
Browser API, which implements the API to the JavaScript application running in the browser
Public API, which implements the API for third-party developers
Gateway Routing Pattern
Summary:
Request routing within API Gateway. GW consults a routing map to send requests to the appropriate service url. Basically same of Reverse Proxy features in NGINX.
Detail:
The API gateway is responsible for request routing. An API gateway implements some API operations by routing requests to the corresponding service. When it receives a request, the API gateway consults a routing map that specifies which service to route the request to. A routing map might, for example, map an HTTP method and path to the HTTP URL of service. This function is identical to the reverse proxying features provided by web servers such as NGINX.
Chained Microservice Pattern
Summary:
Not ideal due to tight coupling and synchronous nature. Essentially caller service needs data that requires daisy chaining multiple microservices. Good if needed to secure other downstream services.
Detail:
There will be multiple dependencies of for single services or microservice eg: Sale microservice has dependency products microservice and order microservice. Chained microservice design pattern will help you to provide the consolidated outcome to your request. The request received by a microservice-1, which is then communicating with microservice-2 and it may be communicating with microservice-3. All these services are synchronous calls.
Branch Pattern
Summary:
Mix of Chained and Aggregator patterns. Aggregates response from multiple services, including chained microservices. Can be useful for deconstructing monoliths.
Detail:
A microservice may need to get the data from multiple sources including other microservices. Branch microservice pattern is a mix of Aggregator & Chain design patterns and allows simultaneous request/response processing from two or more microservices. The invoked microservice can be chains of microservices. Brach pattern can also be used to invoke different chains of microservices, or a single chain, based your business needs.
Client Side UI Composition Pattern
Summary:
Micro Front End Pattern. Generate the UI using components or fragments that are responsible for various aspects of the UI. For example, Pay Button, vs. Product Recommendations vs. Product Inventory views based on search/category. Components can by Typescript classes based on templates and the data shaping UI ViewModel for the templates comes from each microservice.
Detail:
When services are developed by decomposing business capabilities/subdomains, the services responsible for user experience have to pull data from several microservices. In the monolithic world, there used to be only one call from the UI to a backend service to retrieve all data and refresh/submit the UI page. However, now it won’t be the same. With microservices, the UI has to be designed as a skeleton with multiple sections/regions of the screen/page. Each section will make a call to an individual backend microservice to pull the data. Frameworks like AngularJS and ReactJS help to do that easily. These screens are known as Single Page Applications (SPA). Each team develops a client-side UI component, such an AngularJS directive, that implements the region of the page/screen for their service. A UI team is responsible for implementing the page skeletons that build pages/screens by composing multiple, service-specific UI components.
https: //docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout
https: //dev.to/okmttdhr/series/10191
