This is the 14th day of my participation in the November Gwen Challenge. Check out the event details: The last Gwen Challenge 2021

This series of articles is the learning record of Frontend Architecture: From Getting Started to Micro Frontend by Fengda Huang.

What is architecture

Architecture is an evolutionary process. It doesn’t mean evolving with history, it means evolving with the project. When we say architecture, we usually mean architectural patterns.

The architecture is based on current technology, personnel, financial resources, etc. The architecture is not static. Over the life of the software, the architecture can be constantly optimized and getting better, making it suitable for the current scenario.

How do you judge an architecture?

◎ An application architecture that doesn’t live is not a good software architecture.

◎ A software architecture that no one can develop is not a viable software architecture.

◎ An architecture that is technically unworkable is not a sound software architecture.

What kind of software architecture do we want to implement?

◎ Relationships between systems. Clearly indicate the relationship between the system and other systems, whether it is an invocation relationship, a dependency relationship, etc.

◎ Relationships within the system. The relationship between subsystems in the system, such as front-end application and back-end application, how to communicate, what kind of communication mechanism is needed.

◎ In-app architecture. Contains application-related frameworks, components, and clearly shows their relationships.

◎ Norms and principles. Used to guide developers on projects to write code that meets requirements to build the architecture in design.

How to design the architecture

Designing the architecture involves a series of complex tasks, as shown in figure

The corresponding steps are as follows:

(1) Collect the needs of stakeholders. Listen to the needs of business personnel, project leaders and other stakeholders, conduct user interviews, collect relevant needs.

(2) Discuss with appropriate technical personnel (such as developers, testers) to understand potential architectural limitations.

(3) Looking for potential feasible technical solutions.

(4) Sort out the functional requirements and cross-functional requirements in the functional list.

(5) Identify risk points that will seriously affect development.

(6) Repeatedly confirm the plan with the technical Committee and stakeholders (optional). (7) Conceptual proof of architecture design.

(8) To refine some implementation details of the framework.

(9) Combined with technology and business, make demand scheduling.

Architectural concerns:

Considerations for quality and maintainability:

Execution Qualities: The Qualities, such as security, ease of use, that can be observed while the system is operating.

Evolution Qualities: They are embodied in the static structure of the system, such as software testability, maintainability, Scalability, etc.

◎ Availability: The probability that the system will work properly over a period of time. How can such availability be guaranteed?

◎ Maintainability: The index of its performance is that after receiving the modification, it can be modified within the corresponding time (such as 1 ~ 3 days for small functions).

◎ Variability: Where will apps change in the future? Do you need to prepare in advance?

◎ Fault tolerance: What faults can occur in the system? How do you make sure these failures don’t cripple your system?

◎ Scalability: Which services will fail when larger users use the system?

◎ Browser support: Specify which browsers we want to work with, and which versions of browsers we want to work with.

◎ Supported versions of mobile devices: Common devices such as Android and iOS, the lowest supported version of the device, and which device manufacturers are supported.

Architectural patterns

(1) Layered mode

This is the most common architectural style that divides the system into layers in a horizontal shard. A system consists of several layers, each consisting of multiple modules. Each layer serves the upper layer and uses the functionality provided by the lower layer.

For example, the OSI seven-tier model and TCP/IP five-tier model are well-known.

(2) MVC architecture pattern

This style, which is widely used, emphasizes separation of responsibilities and divides a software system into three basic parts: Model, View, and Controller.

The functions of the user interface are completed by the view and the controller together, and a change mechanism is designed to ensure that the user interface is consistent with the model.

It is a common architectural style, and it is often found in graphical user interfaces, such as front-end applications, mobile applications, etc.

(3) Publish-subscribe model

This style, also known as event-based architectural style, is a one-to-many relationship in which all subscribed objects are notified when the state of an object changes.

The biggest benefit of this architectural style is the decoupling of the code. Publishers do not care about the subscribers of events and only need to publish events when appropriate; Subscribers depend on events, not their publishers.

This pattern is often used in daily front-end development to decouple the dependencies of different UI components.

(4) Management and filters

This is an architectural pattern suitable for handling data flows, in which each step is encapsulated in a filter component and data is piped between adjacent filters.

Angular, for example, has a Pipe system built in directly.

Architecture development methodology

(1) 4+1 view

Each project will have a system architecture diagram, which contains the relationship between the major layers of the system, as well as the relationship between some third-party systems.

We can understand the architecture of the system through development, deployment, and process-related content:

Definition:

◎ Logical View: Modules, interface division, responsibilities and collaboration during design. ◎ Process View: Data synchronization during runtime, such as data flow and control flow in the micro front end.

◎ Development View: framework, library, technology selection and corresponding compilation during Development.

◎ Physical View: Also called deployment View. Technical decisions related to continuous delivery during deployment.

Scenarios, also known as a use case view, uses a set of use cases or Scenarios to illustrate an architecture.

4+1 View design process

(1) Architects create corresponding logical architectures according to requirements, and developers carry out detailed design.

(2) Architects and developers design physical architecture according to requirements, and then developers make detailed design according to physical architecture.

conclusion

4+1 view method relies on software modeling and OO technology to carry out architecture design, especially in logical architecture design is more consistent with the traditional waterfall mode, need to design all kinds of interfaces in advance, before entering the project development stage. This cumbersome design is not suitable for Internet applications, and not suitable for front-end applications.

(2) TOGAF and ADM

For large enterprise architectures, TOGAF (TheOpen Group Architecture Framework) can be used to design enterprise architectures in a standardized way.

Architecture domain of TOGAF

◎ Business Architecture: Define Business strategies, governance approaches, and key Business processes.

Application Architecture: Provides a blueprint for the individual applications to be deployed and shows how they interact and relate to the core business process.

◎ Data Architecture: Describes the Architecture of an organization’s logical, physical Data assets, and Data management resources.

Technology Architecture: Defines the logical software and hardware capabilities required to support the deployment of business, data, and application services. IT encompasses IT infrastructure, middleware, networking, communications, processing, and standards.

ADM

ADM, for creating enterprise-level architectures. ADM is divided into eight phases:

The eight stages are explained below:

A. Architectural vision. Set the scope, constraints, and expectations of the project.

B. Business architecture. Develop the business architecture to support the set architectural vision.

C. Information system architecture. Develop the information system architecture to support the set architectural vision.

D. Technical architecture. Develop the technical architecture to support the set architectural vision.

E. Opportunities and solutions. Initial implementation plan and identification of delivery tools for the architecture defined in the previous phases.

F. Migration plan. Explain how to migrate from the base architecture to the target architecture with a finalized detailed implementation and migration plan.

G. Implement governance. Prepare and publish architectural contracts and monitor the implementation of the architecture to ensure that the implementation project meets the requirements of the architecture.

H. Architecture change management. Continuous monitoring of architectural changes.

Architectural output

No matter which architectural design approach is adopted, architectural documentation needs to be left behind, which will lay the foundation for the team’s development.

◎ Architecture Diagram: It contains the overall architecture of the system and is used to visually tell developers how they constitute the entire system and how each part relates to another. Also, explicitly indicate which parts are third-party systems and how they relate to that system.

◎ Iteration Plan: Arrange project implementation plan in chronological order according to business and technical requirements. Since the launch time is also included, the iteration time can also be calculated forward from the launch time. Development process: define how developers will work, such as agile or waterfall development, which source code approach (main branch, GitFlow or FeatureBranch workflows), and prepare tools and equipment in advance if necessary. Then, tailor the development process to meet the needs of the team.

◎ Technology stack and selection: determine the language, framework, library and other related technology stack used in the project, as well as the corresponding dependencies.

◎ Sample code: Show the architecture style and corresponding design specifications in this code.

◎ Test strategy: Define the test type and process of the project, as well as the level at which the corresponding personnel conduct the test.

◎ Deployment mode: Defines the application deployment mode and corresponding deployment scheme.

◎ Continuous integration solution: Describes how the modules of the system (such as the front and back ends) are integrated, and how often and when the related modules are integrated.

Architectural Design Principles

◎ No more, no less: No extra design, no missing pieces.

Evolutionary: Constantly evolving to adapt the architecture to the current environment.

◎ Sustainability: Long-term architectural improvements are more important than anything else.

According to Martin Fowler, an expert in software development and design, the optimal split between the two is 20% planned design and 80% evolutionary design. Such a design requires attention to the following aspects:

(1) Planned design at the early stage of the project to ensure that the architecture can handle the biggest risks.

(2) Conduct preliminary architectural practice in Iteration 0 and write architectural code for examples — to integrate design principles and styles into the project.

(3) In the process of project implementation, adopt partial design or evolutionary design to cope with the change of demand.

(4) Cooperate with agile practices such as refactoring, test-driven design and continuous integration to drive architecture implementation and prevent architecture rot.

How to design the front-end architecture through hierarchical design

From the expert’s years of experience, the front-end architecture can be carried out through the way of hierarchical design, that is, from top to bottom, layer by layer of technical decisions, and then from bottom to top layer by layer to verify the feasibility of the scheme.

Architectural design can be divided into four levels:

The corresponding hierarchy is explained as follows:

◎ System level refers to the relationship between the application in the whole system, such as how to communicate with background services and how to integrate with third-party systems.

◎ Application level refers to the overall architecture outside the application, such as how multiple applications share components and communicate with each other.

◎ Module-level refers to the internal application module architecture, such as code modularization, data and state management, etc.

◎ Code level, which ensures architecture implementation from infrastructure.

Front – end separation architecture

It includes a series of decisions, user authentication, API interface management and design, API (contract) document management, Mock Server usage, BFF (back-end serving the front end), whether Server rendering is required, and so on.

When in a system, the micro front end is an architecture solution between applications, when in multiple applications, the micro front end is an architecture solution between systems.

The design method of hierarchy design:

(1) Application-level architecture

Application-level architecture refers to the relationship between a single application and external applications, such as the collaboration of multiple applications under a microservice architecture.

  • The scaffold

  • The pattern library

  • Design system

(2) Module-level architecture

Module-level architecture is to design the architecture of a single application in more detail, and it involves the content that we often touch in daily development.

  • Modularity: It includes modularity of CSS, JavaScript, HTML/ templates

  • Componentization: It is concerned with the principles and granularity of how components can be enclosed within an application.

(3) Code level: specifications and principles

Architecture to implement

Both short-term and long-term projects involve similar start-up and implementation cycles:

The work of these three periods is described below.

◎ Technical lead-up: Start work related to architecture implementation, such as scaffolding, testing, and deployment.

◎ Business replenishment period: to fill the problems caused by the lagging business progress in the first period, and to prove the value of technology through technical practice.

◎ Growth optimization period: Continuously optimize the technology and business of the project to meet the needs of the development and business people.