The book "Microservices on the .NET platform"

Hi, Habrozhiteli! We bring to your attention the chapter “Patterns for building applications based on microservices” from our new book by K. Horsdal devoted to programming microservices on the .NET platform

Composite applications: front-end integration
The first template for building applications based on microservices is the “Composite Application” template. Such an application consists of functionality taken from several places - in our case, from several microservices - with each of which it communicates directly. Microservices can communicate with each other to perform their tasks — for a composite application, this is unimportant.

In fig. 12.3 we return to the example with insurance - we have a universal application that includes all the functionality of the system. The system for working with insurance is built using microservices, so in order to provide all the functionality of the system, the application must receive business opportunities from several microservices. There are more microservices in the system than shown in the figure, and the application will not directly inherit the functionality from all of them. Such an application concentrates all the functionality in one place, hence the term “composite application”.


When you create a composite universal application based on a microservice system, these microservices provide functionality and an interface. As a result, the application interface is a combination of smaller interfaces obtained from different microservices. In fig. 12.4 shows an example of the structure of the insurance application interface: it consists of four sections, each of which is taken from a separate microservice supplying functionality and interface.
')
The implementation of GUI integration is performed depending on the technology used in building the client. When working with the Windows Presentation Foundation (WPF) desktop application (http: mng.bz/0YfW), you can, for example, use the Managed Extensibility Framework (MEF, mng.bz/6NKA ) to dynamically load components into the application, each of which will have its own interface. When using a web application, the interface can be created by loading HTML fragments and JavaScript packages from microservice into the main application and adding them to the DOM using JavaScript. In both cases, microservices provide functionality and interface.

Not all composite applications are universal applications; they may be smaller. For example, if an insurance application has applications for each type of user, each application must provide functionality that belongs to different business opportunities and, accordingly, to different microservices. It follows the principle that every application for a specific type of user can be created as a composite.


Benefits When you create composite applications, the interface is broken down into smaller parts according to business opportunities, just as the functionality is distributed between microservices. This means that the interface for each business opportunity is implemented and deployed along with the corresponding business logic. Since the composite application receives the interface for the business opportunity from microservice, the application is updated each time the microservice is updated. This means that the flexibility that you achieve by partitioning the system into small specialized microservices is applicable to the application interface.

Disadvantages . The composite application responds to the integration of all the functionality implemented in the microservice system. This task can be difficult: there are many business opportunities in the microservice system, and the application interface can be broken according to another principle, which leads to the appearance of pages that include interfaces for several different microservices that do not look like a single page for the end user.

This kind of complexity may mean that the composite application knows exactly how microservices and their interfaces work. If a composite application starts making too many assumptions about the interfaces of microservices, it becomes sensitive to changes in each microservice and therefore may stop working entirely as a result of a change in any one microservice. If you find yourself in a similar situation, this means that you have lost flexibility, which is one of the main benefits of using a composite application.

In conclusion, I would like to note that composite applications can work very well, but only if you can avoid implementing complex interactions.

Gateway API

The second template for building microservice applications is the Gateway API. The API Gateway is a microservice with an open HTTP API that covers the entire functionality of the system, but does not implement any functionality by itself. Instead, the API gateway delegates all the work to other microservices. In essence, the API gateway acts as an adapter between the applications and the microservice system.

When you build an application based on microservices that uses the API gateway, applications do not know how the system’s functionality is divided between microservices - they don’t even know that the system uses microservices. The application only needs to know about one microservice - about the API gateway.

Throughout this book, you saw an example of an implementation of a shopping cart for an online store that contains an API gateway. In fig. Figure 12.5 shows a request to add an item to the user’s basket, which comes from an application to an API gateway, which delegates it to other microservices to service the request. The role of the API gateway in this case is that the application has a single entry point, which simplifies the system interface, so applications do not need to interact with several microservices directly.

Using the API gateway, you can build any application, from the universal one, which uses all the functionality of the API gateway, to specialized applications that use only part of the API gateway, as well as any intermediate application.


Benefits The main advantage of the "Gateway API" template is that applications are decoupled from the microservice structure. The API gateway completely hides this structure from applications.

When the functionality of several applications overlaps or some applications are created by a third party, the use of the API Gateway template supports:

• low entry barrier for building applications;
• stability of open API;
• backward compatibility of open API.

Using the API gateway means that application developers need to consider only one API in order to get started. You can concentrate on maintaining the stability and backward compatibility of the API as other microservices evolve.

Disadvantages . The main disadvantage of the API Gateway template is the fact that the API Gateway itself can grow to the size of a large code base and, as a result, acquire all the shortcomings of a monolithic system. This is especially true if you succumb to the temptation to implement business logic in the API gateway. The API gateway can receive functionality from several other microservices in order to execute one request. Since he already combines data from several microservices, it may be tempting to apply some business rules to this data. In the short term, this can be done quickly, but it pushes the API gateway towards solidity.

In conclusion, I would like to say that the “Gateway API” template is very useful and is often the right way to develop an application. But you should carefully monitor the size of the API gateway and be prepared to respond if it becomes so heavy that it will be difficult to work with it.

Backend for frontend

The third and final pattern for building microservice applications that we will look at in this book is the Backend for the Frontend (backend for frontend, BFF). The BFF template is useful when you need to build more than one application for a microservice system. For example, the insurance system may have a web application that contains the most frequently used functionality, an iOS application that appraisers can use outside the office, as well as a specialized PC application designed to perform the tasks of actuaries. BFF is a microservice similar to the API gateway, but it is specialized for one application. If you use this template for insurance applications, you will have BFF for the web application, BFF for the iOS application and BFF for the desktop application for actuaries (Fig. 12.6).

The idea of ​​BFF is to support an application built on its basis. This means that the application and BFF are closely related: BFF provides the necessary functionality for the application so that creating the application looks as simple as possible.

Benefits Thanks to the BFF pattern, each application can use an API that fits its needs perfectly. If you use the API gateway, there is a risk that it will swell over time as you add new functionality. When using BFF, this risk is reduced because it does not have to cover the entire functionality of the system — it needs only the part of it that is required for the application it serves.

It is not difficult to know when something can be removed from the BFF: this can be done if there is no active version of the application using this functionality. Compare this with an API gateway that serves several applications — you can only remove something from the API gateway if there are no active versions of any of the applications being served. Ultimately, BFF offer a way to simplify application development and keep the server part specialized and distributed.


Disadvantages . In cases where you need to create several applications that provide end users with similar or intersecting functionality, such as applications for iOS and Android, aimed at one type of users, the BFF template leads to writing duplicate code in several BFF. It also shows the usual drawbacks of duplication - you need to do the same work several times when making changes to duplicate code fragments, duplicated parts, as a rule, over time they begin to differ from each other and work a little differently in different applications.

In conclusion, we note: the BFF template will help to strike a balance between the need to integrate microservices in the application and create an API gateway that can grow over time.

When to use each of the templates

Now that you know about the three templates for creating end-user applications that work with the microservice system, the question inevitably arises: which one to use? All three templates have their advantages and benefits, so I can not recommend any one. When you create an application, you need to make a choice. I make this decision based on the answers to the following questions.

• How many features do you want to attach to the app? For business applications that are used only inside the company's firewall and only on company machines, you can create a desktop application that performs a large number of functions. In this case, the “composite application” pattern will be the obvious choice.

For a store application that should run in any browser, including the old one, when there is a risk that someone will try to hack the application, you can decide not to put many functions in the application, which makes the Composite Application template less attractive.

• How many applications are planned? If there are a lot of them, how much do they differ from each other? If you have assigned a few functions to an application and you have only one application, or all applications provide similar functionality, perhaps even in similar ways, you probably will find an API gateway. If you have several applications and they provide different sets of functions, the BFF template will suit you. In case you are using an API or BFF gateway, the functionality is on the backend. The API gateway works well as long as it remains connected, that is, as long as the entire set of endpoints provided to them complies with a specific system of how applications should use them and how they are structured.

If some endpoints follow the “remote procedure call” (RPC) style, while others follow the “representation state transfer” style (REST), they do not comply with the system and connectivity in the code base of the API gateway, most likely will be low. In such cases, you should consider using the BFF template. With BFF, you can combine applications that work with RPC-style APIs in one BFF, and applications that use the REST API, in another BFF, without breaking connectivity. Each BFF can be related and stable by itself, but you don’t need cohesion among the BFF in terms of the API style.

• How big is the system? In a large system — in terms of the amount of functionality available — the API gateway can become an unmanaged code base that has many shortcomings of monolithic systems. For such systems, it is better to use several BFF than one large API gateway. At the same time, if the system is not so large, the API gateway may be simpler than the BFF.

Finally, it should be noted that you do not need to make the same decisions for all applications. You can start with the API gateway and build several applications with it, and then decide that a new application with an innovative approach to solving problems cannot work with the API gateway, and provide it with the BFF. Similarly, you can have internal applications that use the Composite Application template, and external applications that run through an API gateway consisting of several BFFs.

Is it client-side or server-side rendering?

We reviewed three templates for building microservice applications — Composite Applications, API Gateway, and BFF. If you build web applications using these templates, another question arises: where to draw, on the server side or on the client side? That is, do you need to generate ready-made HTML on the server using, for example, Razor, or should you render HTML in a JavaScript application using one of the many JavaScript application frameworks like Angular , Ember , Aurelia, or React ?

This question does not have an exact answer; it all depends on which application you want to build. How dynamic will this application be? Does it work with data or just display and accept it? The more dynamic the application is and the more its execution flow is associated with data manipulation, the more I tend to draw on the client side. If the application is more static and more related to viewing and data entry, then I tend to draw on the server side. The basic idea, however, is that the choice of rendering method depends on which application you want to create, and not on the choice of server-side microservice architecture.

All three templates support rendering both on the client side and on the server side, to the extent that some parts of the application are drawn on the server, and some on the client. For example, the policy catalog in the insurance system is static and in most cases it does not change, so most likely it makes sense to draw it on the server side. And the score calculator is a more dynamic component that allows users to change parameters before saving the final result, so it may be better to draw it in a JavaScript application. Both modules can coexist in the same application.

• If you create a composite application, it can receive the policy catalog drawn on the server, as well as a JavaScript application for the rating calculator. The microservice responsible for the policy catalog will provide an interface generated on the server, and the microservice responsible for evaluation will provide a JavaScript application.

• If you use an API gateway, it may contain endpoints that return HTML, and endpoints that return data — for example, in JSON format. It may even contain endpoints that return data in HTML or JSON formats, depending on the Accept request header. Therefore, an application can contain a policy catalog drawn on the server, as well as a rating calculator drawn on the client side.

• If you use BFF, you can also create endpoints that return HTML, data, or both. In addition, BFFs allow you to make different decisions for different applications: in one BFF, the policy directory will be drawn on the server side, but in the other you can do it on the client side.

The choice between client-side and server-side rendering in the web interface is not affected by the fact that the server side uses microservices. All the templates we consider necessary for building applications based on microservices support both types of drawing.

»More information about the book can be found on the publisher's website.
» Table of Contents
» Excerpt

For Habrozhiteley a 20% discount on the coupon - Microservices