Comparison of Web application architectures

Architecture	Technical advantages	Technical challenges	Team Advantage	Team Challenge
monomer	Low latency development simple No duplicate model / validation	telescopic	The overhead of communication within the feature is low	Fear of failure
frontend + back end	Separating business logic from presentation able to reuse backend and build multiple front ends	complexity due to network calls	professional < Span style= "font-family: Song body; Font-size:14px "> Faster iteration of the front end Ladder to service Oriented architecture	communication overhead knowledge barrier Front and back end development blocking each other
Service Oriented Architecture (SOA)	Fine-grained scalability Isolation Packaging	Operation and maintenance overhead Delay Service discovery Trace / debug / Log logging Hot Service API documentation, client Integration Testing Data fragmentation	Autonomy	Dilemma of the degree of autonomy Risk of duplication of work
Micro-Service	Just as with service-oriented architectures, there will be more	Just as with service-oriented architectures, there will be more The risk of implicit coupling	Because the bounded context produces more autonomy	means DevOps is required. Need a platform Team Important transitions that require a way of thinking

One, monomer

Benefits:

1. If the database query has been well optimized, the site should be fairly fast.
2. Development is relatively straightforward because developers do not have to worry about the various challenges associated with invoking remote APIs.

Disadvantages:

1. The ability to scale applications to handle loads can only be extended by deploying multiple copies of the entire application

Second, front and rear end separation

Benefits:

1. By separating the business logic (the kernel of the application) from the presentation layer, the code should be easier to understand and the application easier to change. The two services are conceptually (and physically) isolated through the API, so as long as the interface is not changed, either party is free to make internal changes.
2. Another benefit of exposing the API with the backend is that it can be used by multiple front ends.
3. Independent development of the front and back ends means that each service can be developed at its own pace.

Disadvantages:

1. Some of the blockages between teams are almost inevitable.

Third, service-oriented

Advantages:

1. Emphasizing the independence of the service-oriented architecture, the service must be decoupled so that the new version can be deployed at any time without impacting any other services.

Characteristics:

2. Operational overhead: A service-oriented architecture may include dozens of or even hundreds of services, as well as a variety of data stores and message queues, all of which need to be configured, deployed, monitored, and maintained.
4. Latency: In a service-oriented architecture, a user request can result in dozens of inter-service API calls. This may include chained calls, which service a calls service B, service B calls service C, and so on. Without careful application programming, delays in these requests are superimposed quickly, resulting in a very delayed user experience.
6. Service discovery: There are dozens of different services, each of which has multiple instances running, so an easy way to find the service they want to communicate with is needed.
8. Tracking, debugging, logging: When an application is having problems, it is quite difficult to figure out what the problem is.
10. Hotspot Services: There may be some services, and almost all other services depend on them. User authentication/Identity service is a common example. Service A is passed a user ID, uses the authentication service to find the user, performs some processing, and then passes the user ID to service B, service B also contacts the authentication service, and so on. These hotspot services can eventually receive large amounts of traffic and can therefore be a single point of failure and an extended bottleneck.
12. API documentation and clients: exposing APIs to each other through so many services, the team spends a lot of time writing documents and clients for these APIs. They need to be kept up-to-date to ensure usefulness.
14. Integration testing: It can be difficult to check for proper interaction between all services and whether an application can run as a whole.
16. Data fragmentation: Service-oriented architectures can have many small databases, which makes reporting and data analysis difficult because you need to get data from multiple databases, compress them into a common format, and connect them together.
18. The platform team should write a common library for all teams to use for all teams.

Reference: The people's post and Telecommunications publishing house "legacy system reconstruction actual combat"

Comparison of Web application architectures