A New Era of Efficiency Improvement - Application of Component Development in Zhuanzhuan App - Backend Chapter

1 Introduction

Component development is a process of designing and developing computer systems using reusable software components. Minimized and efficient delivery can be achieved with component-based development.

The platform basic experience department abstracts business logic into components and quickly builds product feed flows by combining components, thus increasing the overall R&D efficiency by 2 times. Component-based development not only improves efficiency, but also greatly increases code reusability, reduces system complexity, etc. This article will introduce in detail the implementation process of component development and reveal the secret of rapid iteration of Zhuanzhuan App.

2 background

The platform basic experience department mainly undertakes the iteration of Zhuanzhuan App and mini programs.

At the end of 2021, based on the background of Zhuanzhuan's positioning as a "second-hand trading platform with quality inspection and safe buying and selling", the homepage Feed (Feed, that is, the product list page) and the main search Feed will be completely transformed. When scheduling, we found that rendering product cards took too much time and could not be delivered before the Spring Festival. For short-term solutions, additional manpower can be invested and delivered on schedule. However, considering that there will be an overall revision in the future, we need to find a way to quickly undertake product iterations across the entire platform.

In March 2022, we started planning a new solution and built a component-based development process.

At the end of September 2022, there is still one month left before Zhuanzhuan Group announces the brand upgrade. The App and mini-programs need to be updated as a whole, of which only the Feed function point has been upgraded to more than 20 points. Component development took this opportunity and began to be applied on a large scale, and the effect has been confirmed.

3 Current Situation Analysis

3.1 Docking process and development process

After the formal review of requirements, the interface review stage is entered. The daily docking process is shown in the figure below.

Development classmate Xiao Zhang defined the fields according to the UI legend on the App homepage and synchronized them to native and QA. Then start another functional point: App favorites recommendation, fixed fields, and synchronized fields.

After the interface review, enter development. The development process is shown in the figure below.

When RD Xiao Zhang develops the homepage, he first obtains the RPC data of each business, and then writes the data rendering logic from top to bottom. After completing the self-test, it will be provided to the native and QA test environments. Immediately afterwards, we invested in the development of favorites function points, and the process was similar.

The process that seems to be very smooth is not smooth during the execution, and there will always be some "hiccups", such as:

(1) A horizontal card style appears in the UI, and there is an additional mental element on the card. Native Xiao Liu requested to add a userText field.

(2) The same UI needs to use different product image sizes on the mini program. FE Xiaofang shouted: Return me the 16×16 size!

(3) Xiao Zhang was very busy. Xiao Zhao came to support and defined the product image field as infoImage, which was different from the previous image field. QA Xiao Zhang and native Xiao Li were very angry and said that I could not accept it. The field was not Uniformity is difficult to maintain.

There were many problems with the docking process, and the development process was certainly not as smooth as expected. The PM will make some temporary requests: add AB experiments on certain function points, or adjust the display logic of a certain function point. During the implementation process, RD may adjust the rendering order of elements, thereby affecting the correctness of global data rendering. In order to avoid code adjustments from introducing additional defects, QA test cases will also increase.

3.2 Project progress

Before entering development, RD makes a technical assessment based on existing change points and outputs a schedule. Take App homepage and App favorites recommendations as examples. From the product rules, only the RPC data source is different. RD believes that most of the logic can be reused. Therefore, locations with similar functions may have their schedules appropriately reduced.

However, in actual development, the new code logic conflicts with the historical logic and cannot be smoothly integrated into the data rendering code block. The entity class definitions of each interface are diverse. When reusing certain data rendering methods, there are many data conversions between entities, and the code becomes very bloated. Many unpredictable "incidents" resulted in the originally promised product being able to complete 20 feed modifications within 10 working days. Even with overtime work, the product could not be delivered on time. The progress of other functions can also be affected, posing risks to the entire project.

3.3 Summary of issues

Reviewing the docking and development process, the following issues are mainly exposed:

• Differences in version, terminal, and UI increase the complexity of the code and make it difficult to reuse: In order to adapt to the different styles of each terminal, or to be compatible with online problems caused by native, RD Or in order to be compatible with different versions of styles, a lot of control logic often needs to be written, making the code logic more and more bloated, and the complexity and maintenance costs gradually increase.

• Interface return value fields are not uniform: Because developers have inconsistent naming habits, with the increase of interfaces and the continuous iteration of products, there may be multiple fields describing the same function. point situation. The number of interface fields has exploded, making it difficult to maintain. When a problem occurs, it is difficult for RD to quickly locate the field, and communication costs and cognitive costs will also increase significantly.

• Unable to adapt to rapid product iteration: The addition of the AB solution and the adjustment of product logic have made the rendering logic of elements too large, and the dependencies between elements have become more complex, and RD cannot Fast delivery.

• Duplicate work content, long schedule, and easy introduction of delay risks: Many functional points are very similar, but they cannot be perfectly reused during development, making the schedule long. Excessively long schedules and unpredictable hidden problems are likely to bring delays.

3.4 Problem entry points and solutions

• entry point

(1) Some contents in the RPC module and data rendering logic are exactly the same. If they are divided into modules, the reusability of the code will be greatly increased.

(2) Data rendering data is procedural and top-down. If this serial development model can be broken, the coupling between each data rendering logic will be greatly reduced.

(3) Take an in-depth look inside a single data rendering. If version compatibility, terminal differences, AB experiments, etc. are stripped away from the data rendering logic, leaving only the core logic, data model rendering will be more reusable.

(4) There will inevitably be dependencies between the data rendering logic of different elements. There is a need for a resource orchestration mechanism that can organize each data rendering logic according to rules.

• solution

Combining relevant technical research and industry-related experience, we introduced "Component Development", that is, component-based development. The advantages brought by components and component-based development can achieve our demands. What are components and component-based development specifically, and what are their advantages? The description will be detailed next.

4 Entering into component development

4.1 Component definition

A component is an aggregation of a set of functionally related logic and data.

Components are self-contained and complete, and are usually open to users in the form of a complete set of APIs. Users do not need to understand the internal logic of the component, but only need to pay attention to the use of the API. The component's implementation logic and dependencies are the responsibility of the component itself.

4.2 Component classification

• Components can be divided into by function: technical components and business components. A business component encapsulates a set of related business logic into a component, also called a management logic component.

• It can be divided into levels:: framework components, platform components, general management logic components, domain management logic components, industry management logic components, personalized management logic components, etc.

• Can be divided into by source: open source components, commercial components, self-developed components, etc.

4.3 Component model

Components need to adhere to the component model protocol. A component model is a set of standards. The component model given by the Department of Electrical and Computer Engineering at Victoria University is shown in the figure below.

The component model includes: interface list, naming, metadata, interoperability, custom component interface, composite interface, component evolution, packaging and deployment.

4.4 Component features

A well-designed component should have the following characteristics:

• Manageable: Components are designed and implemented based on a unified model, follow unified technical specifications, are described by unified metadata, and have clear classification and layering. It can be managed uniformly by component tools and used in a standardized and consistent mode.

• Reusable: Reusability is a core feature of components. Usually components are well designed and encapsulated and can be reused in multiple scenarios. Only by being able to reuse can the value of components be better utilized.

• Configurable: In order to achieve better reuse, the component does not need to modify itself when used in different scenarios. Usually, the component needs to configure the components that may change in different scenarios. Part of it is used as a variable parameter, allowing users to configure different values ​​to meet the needs of different usage scenarios, making the component more reusable. Configurable content usually includes environment information, parameters, rules, model attributes, etc.

• Extensible: In the process of using a component, when the scenario-based usage requirements cannot be met through configuration, the scalability of the component becomes particularly important. If a Components are not scalable, which will greatly reduce the reuse value of the component. The scalability of components can usually be achieved through good design, such as supporting inheritance and local logic rewriting; supporting events, through pre- and post-events, allowing the use of customized rules and logic, which can better meet the needs of different scenarios. Personalize usage requirements, improve the reusability of components, and maximize the value of components.

4.5 Component development

Component-based development: Component-based development, namely: Component-Based Development (CBD), is a method that uses reusable software components (components) ) to design and develop computer systems.

The origin of component development: Component development appeared in the late 1990s. At that time, object-oriented modeling development (Object-Oriented, referred to as: OO) was not as widely reused as originally suggested. OO produces a large number of fine-grained classes, objects, and relationships, and it is very difficult to find reusable components in these smaller units. The idea behind CBD is to integrate related parts and reuse them collectively.

4.6 Types of component development

Component development is divided into two categories: opportunistic reuse and reuse with development volume.

• Opportunistic reuse: Combine existing components into a system.

• Reuse with development volume: Customize and develop certain components according to requirements, and then combine the components into a system.

In daily usage scenarios, because products are constantly iterating, there are fewer scenarios where existing components are directly combined into systems, and there are more extensive application scenarios for component reuse with a lot of development.

4.7 Advantages of component development

• Minimized delivery: Based on existing components, the system can be assembled.

• Efficient: Developers can focus more on demand change points and quickly complete product upgrades.

• Improving system quality: Developers can have more time to ensure system quality. The high quality of the components determines the quality of the system.

• Reduce spending: Reduce resource investment.

5 The implementation process of component development

With the help of component development ideas, we have built a set of component development architecture, which we call internally:Star Ring. The overall architecture is as follows As shown in the figure.

The Star Ring system can be summarized asTwo layers and one package: declaration layer, driver layer and business component package.

• Declaration layer: includes basic declarations, RPC module declarations, component declarations, and downgrade trigger rule declarations. The base declaration is declared in Java code and the remaining parts are declared in XML.

(1) Basic statement: defines the application name, application context, request parameters, component driving method, etc.

(2) RPC module declaration: defines which RPC references are included in the application and the dependencies between RPC modules.

(3) Component declaration: defines which business components are included in the application, the properties of the components, and the triggering conditions of the components.

(4) Degrade trigger rule statement: defines the monitoring strategy, downgrade trigger rules, monitoring frequency, etc. of the entry layer.

• Driver layer: Responsible for parsing and loading XML configuration files, resource arrangement and execution of RPC/components. Among them:

(1) RPC driver layer: the Avengers framework, a self-developed event-driven concurrency scheduling model (for more information, please see reference point 5), responsible for parsing RPC configuration statements, arranging RPC resources, and executing RPC transfer.

(2) Component driver layer: Responsible for component configuration analysis, component hit determination, component resource arrangement and providing component driver entry.

• Business component package: A resource package composed of business logic components, managed in jar form. Includes: title component, product image component, price component, etc.

In addition, there is also surrounding ecology to empower it, including: health monitoring and auxiliary ecology.

• Health monitoring: Detect the health of the entrance layer service. When the error rate reaches the upper limit within the specified time window, circuit breaker and downgrade are triggered.

• Assistant Ecosystem: Assist developers to quickly build component applications. Contains IDEA XML configuration auto-completion prompts, maven scaffolding-assisted code framework generation, etc.

How the entire architecture is gradually built, and what problems need to be solved during the construction process, are introduced one by one in modules below.

5.1 Preliminary work

5.1.1 Unified component caliber

First of all, we need to determine what a component is. As mentioned in the previous article: a component is an aggregation of a set of functionally related logic and data. Among them, data can be understood as each field in the interface, and logic is the product rule corresponding to each field. Why define each field as a component? This is closely related to our job functions. Different from the middle-end back-end, the platform back-end is the back-end that serves the front-end, namely: BFF (Backend For Frontend). The main responsibility of BFF is to combine and use the underlying data, then process the display logic according to product rules, and finally return it to the front end.

In daily docking, the backend defines the interface according to the UI requirements and adjusts the interface protocol according to the characteristics of each terminal. Each UI element corresponds to a set of product rules, and each UI element corresponds to a field. Fields also serve as a bridge for front-end and back-end data interaction. It is most appropriate to classify each field into a component.

5.1.2 Promote standardization

The elements that make up a component are a set of standards. The establishment of standards helps achieve component reusability. In the previous article, we defined fields as components, and there is a one-to-one correspondence between fields, components, and UI. Promote the standardization of components, that is, the standardization of fields and UI.

(1) Field naming standardization

Because developers have inconsistent naming habits, multiple fields may describe the same function point. When different components are divided by field dimensions, the components will become very redundant, and communication costs will also increase during interface docking. In addition, non-standardized fields are not very friendly to native component implementation. Native needs to additionally maintain the mapping between non-standard field data and UI elements, which increases development and maintenance costs.

(2) UI style standardization

Although the UI shows personalized differences in different terminals and different pages. But the corresponding product logic behind some elements is consistent. For example: the official quality color label in the product card conveys the same content, and the style can be unified on the homepage and main search. From a product perspective, standardized UI can create a unified user experience atmosphere across the entire platform; in terms of technology, it not only reduces the cost of maintaining APIs, but native can build UI components based on standardized UI, thereby enriching the component library and improving Reusability.

5.1.3 Standard interface return value structure

The interface return value contains various data displayed on the front end. With the iteration of the product, there will be more and more element types in the UI, and developers habitually continue to tile new fields in the interface return value. As the time period lengthens, the number of fields increases explosively, making it difficult to maintain. Therefore, the return value structure also needs to have a set of standards to restrain the growth rate of the number of fields.

(1) Collapse fields by object content type

Taking the elements in the product card as an example, there are many label elements on the page: official color verification labels, function description labels, hidden point labels, etc. These fields are all expressed in the form of pure pictures or pure text, and can be summarized as Label object.

(2) Merge fields by function

On different terminals, image links sometimes need to be spliced ​​with attribute parameters. In the past, we would return two fields, picUrl and picUrlWH, to determine whether the image carries width and height attributes. Now they are unified as: picUrl. Whether to splice the width and height parameters is moved to the component as a component property.

(3) Integrate into KV structure

The KV structure is used to store some non-standard fields, such as the buried point field postIdMap, including the reported buried point transparent transmission field.

(4) Support return value VO extension

It is currently impossible to confirm whether it will be defined as a standardized field in the future, so it will be placed in VOExt, a subclass of VO. Only standardized field declarations are included in VO.

5.2 Component granularity

Obtaining the execution results of the component goes through two steps: executing RPC calls, and then performing data processing according to the product logic. Take actual usage scenarios as an example:

When rendering the title: Call product services to obtain basic product information.

When the hand price is rendered: call the product service to obtain basic product information; call the promotion service to obtain event promotion information.

When rendering the underlined price: call the promotion service to obtain event promotion information.

The relationship between RPC calls and data rendering is summarized, as shown in the figure below.

There is a many-to-many relationship between RPC calls and data rendering logic. Looking back at the definition of components again, a component is an aggregation of a set of functionally related logic and data. How should functional logic be defined? If the functional logic of a component is defined as a combination of RPC calls and data rendering logic, the following problems will arise:

(1) Repeated RPC calls: Multiple components may contain the same RPC data source. Each component obtains RPC data once and calls it repeatedly, causing pressure on the downstream.

(2) Component responsibilities are not single and difficult to reuse: If multiple components are merged and RPC is called only once, then the component responsibilities are no longer single and reusability is reduced.

(3) Difficulty in resource orchestration: There are dependencies between components and between RPC modules, and there is no necessary connection between the execution order of RPC and the execution order of components. When RPC Resource orchestration is difficult when tied to data rendering.

In summary, RPC calls should be independent of data rendering logic, and the functional logic of components only includes data rendering.

Furthermore, when the RPC call is separated from the component, it is necessary to provide the component with a way to obtain RPC data. The attribute domain SynchronizedMap can be provided in the application context to store the RPC result set and establish a communication bridge between the two.

5.3 Component class design

According to the component model protocol that the component component follows, defining the component class includes the following content:

• metadata

Component type (componentType): Identifies the function point to which the current component belongs. For example: title component, product image component, price component, etc.

Dependent component list (dependencyComponentTypeList): Identifies which business component basic data the current component depends on. For example: the presence or absence of the "Coupon Information" data depends on the data status of the "Obtained Price".

The above attributes are defined in the component's top-level interface. The component's top-level interface class structure is as follows.

• behavioral definition

General behavior doHandle(): defines the standard behavior of the component, which is defined in the component's top-level interface.

• Custom component interface

Custom behavior doInnerHandle(): Defines the custom behavior of the component. The difference from doHandle() is that doHandle() defines the general execution logic of component behavior, while doInnerHandle() is used to implement the personalized business logic of each component. This behavior is defined in the top-level class of the custom component. The top-level class structure of the custom component is as shown in the figure below.

After the basic component class is defined, it needs to be defined according to the business scenario: define the parent component and create a new business component. The summary class diagram is shown below.

• Parent component class

There is no specific return value VO type declared in the top-level class of the custom component. In actual use, it is necessary to declare the return value type, primary key type, parameter type, etc. according to the scenario. These contents are declared in the parent component class. For example, in the feed flow product card scenario, create a new FeedComponentHandleService, specify the primary key type as Long type product infoId, specify the return value type as FeedBaseInfoVOExt, etc.

• Business component class

Based on the parent component class, you can create new business component classes, such as: title component TitleV1, product image component ImageV1, product image component ImageV2...

5.4 Parameter passing

In order to improve the reusability of RPC modules and components, variable parameters will be added to allow users to configure different values ​​in different scenarios. RPC/component parameter values ​​come from interface parameters. When the interface request parameters are directly used as RPC/component parameters, because the interface request parameter attribute domain = {RPC module parameter attribute domain, component parameter attribute domain, other parameters}, RPC/component Many useless parameter attributes have been added to the parameters. On the other hand, there are various types of interface parameters, making it difficult for the same component to adapt to different scenarios, and the reusability is greatly reduced. So RPC/component should only focus on the parameters it needs to use.

After the interface request parameters and RPC/component parameters are managed independently, when an external request arrives, the RPC/component needs to establish a communication method to obtain the interface parameters. The process of RPC/component obtaining parameter attribute values ​​is shown in the figure below.

When obtaining the RPC/component parameter attribute value, the proxy object requested by the RPC/component is first obtained, and then the MethodInterceptor intercepts the method of the proxy object and instead executes the method in the original request object.

realistic path：

(1) Define the IRequestFiledAutoMapped interface, and the attribute domain contains a ThreadLocal object to store the original request object. RPC/component request classes all implement this interface.

(2) Define the interceptor MethodInterceptor, which is used to intercept method requests of each implementation class of IRequestFiledAutoMapped.

(3) Define BeanProcessor. After the component Bean is generated, use Enhancer to create a proxy object.

5.5 Component hit conditions

In the traditional programming model, data rendering contains a large number of conditional judgment statements, as shown in the figure.

Different scenarios often only hit one path in the conditional statement. Separating these conditional judgments from product function logic, and only containing product function logic in component logic, will greatly improve the reusability of components. In addition, the stripping of conditions can make functional code blocks slimmer, and developers' learning and cognitive costs will be greatly reduced.

Looking back at the example in the above figure, after separating the conditions and product function logic, it can be divided into 3 components:

Component 1: title = title + content

Component 2: title = tinyTitle

Component 3: title = title + paramsValue

After division, different components can be selected according to different scenarios, and the component logic is easier to upgrade and maintain.

The component model specifies the interfaces and rules for combining components. The hit condition of a component is used as a rule and is used in conjunction with the component to determine which component should be selected for a certain scene. In terms of implementation, we provide two conditional declaration forms.

(1) Provide a conditional top-level interface IBaseCondition, implement the evaluation() method, and declare hit rules in the method.

(2) Use EL expressions to describe hit rules, and the Aviator rule engine loads the rules.

How to bind conditions and components, and how to execute hit conditions will be described in 5.6.

5.6 Managing multi-version components

• management style

After the various components are prepared, they need to be organized, and how to assemble the components also needs to follow a set of standards. Use XML files to describe assembly information of components. Using this declaration method, each assembly point is organized into a block structure with a clear hierarchy. The following is an XML configuration example.

The configuration file mainly contains four parts: application declaration, RPC module declaration, component declaration, and custom parameter declaration. The contents of each part of the statement are in the pre-introduction in Section 5 and will not be repeated again.

• Load XML

Zhuanzhuan's microservices are supported by the Spring Boot framework. With the help of AbstractBeanDefinitionParser, the parseInternal method is rewritten to parse XML and generate singleton mode beans. The structure of Bean is shown in the figure below.

• Let’s mention the component hit conditions again

The framework provides two component conditional access methods: implementing the IBaseCondition interface or using EL expressions. In the configuration file, a sample declaration is as shown below.

(1) If the IBaseCondition interface is implemented, complete the attribute value of conditionClass, and the value is the class path of the IBaseCondition interface implementation class.

(2) If an EL expression is used, complete the attribute value of conditionEL, and the value is the content of the EL expression.

• component hit

When conditional and functional logic are separated, functional logic evolves into multiple components. Because the request scenario is unknown and uncertain, the components are gathered according to type: component group, as shown in the figure below.

In actual scenarios, different scenarios will only hit only one component. Whether the component is hit is triggered according to the following rules:

(1) Determine component hits from top to bottom. If any component is hit, the determination of the component group is completed.

(2) The conditionEL configuration is read first. If the rule engine execution result returns true, the component is hit, otherwise it is not hit; if the conditionClass class path is configured, execute the evaluate method in the condition instance. If the method return value is true, the component is hit. , otherwise it will not hit.

• Component collection

When the result determination of a certain component group is completed, the hit components will be collected in the collection, namely: Set<Class< ? extends IComponentHandleService>>. Component hits from multiple component groups are aggregated here.

5.7 Component sorting

After collecting the component list, the behavior of these components cannot be executed immediately. In actual scenarios, there are data dependencies between components, as shown in the figure below.

The display conditions of the "Coupon Label" component depend on the "Activity Information" component and the "Obtained Price" component. Therefore, in the order of component execution, the "Activity Information" and "Obtained Price" components need to be executed in advance. In the underlying implementation, components are sorted according to the dependency relationships between components.

Dependencies between components can be actively declared or obtained through automatic resolution. In terms of sorting implementation, the automatic parsing method can realize component arrangement through the reverse parsing method of three-color marking (for more information, please see reference point 10, chapter 4.3.3). We adopt the method of actively declaring dependencies and arranging directed graph topology.

Specifically:

(1) When writing a component, declare the component type and dependent component types inside the component.

(2) Treat each component as a node of the graph, and the dependency relationship as an arc to generate a directed graph. The directed graph is stored using an adjacency list.

(3) Perform topological sorting on the directed graph. When the directed graph has a ring structure, the log prompts that there are mutual references; if the directed graph has no ring, the final sorting result is output.

(4) Execute component behaviors in sequence.

5.8 Component driver

After the aforementioned process, the component model construction is completed. The framework needs to provide an entrance for external calls. The scene is divided according to the number of entities in the calling scene: single view and multi-view.

• Single View: Renders data for a single homogeneous entity. For example: a product card, a product details page.

• Multiple views: Render data of multiple entities of the same type. For example: multiple product cards, multiple product detail pages.

For each scenario, the corresponding call entry and method of customizing the driver component list are provided, as shown in the figure below.

Single view entry: renderView(); multi-view entry: renderViewList(). The view entry provides methods for customizing the driver component list. For example: in a multi-view scenario, implement the driveCardView() method to implement serial execution components or parallel execution components.

5.9 New development model

Using component development, building a feed stream only requires the following steps:

(1) Create a new business component (optional): If there is new business logic, create a new business component class.

(2) Declaration configuration: Declare the application name, RPC module list, and component list in the XML configuration.

(3) Declaration driver: Define application beans, application context, request parameters, component driving methods, etc.

(4) Execution driver: List of components hit by execution.

(5) Additional logical processing: buried log printing, etc.

(6) Result return

6 Performance data

Take the scenario of adding recommended feed to my page as an example:

Overall improvement in R&D side efficiency: 2.2 times.

Based process: Work hours invested before componentization model ÷ Work hours invested after componentization model. That is: 84H÷37H≈2.2.

The details of investment costs on the R&D side are as follows:

7 Auxiliary Ecology

• XML autocomplete plug-in

When writing component configuration, you often need to check component meta-information: component attributes and other content, which affects writing efficiency.
Based on IntelliJ Platform Plugin Template, an XML auto-completion prompt plug-in was developed.

• maven scaffolding (under planning)

The component development model can precipitate a set of code structure. Scaffolding can further reduce development investment by generating common code.

8 Summary

• Traditional development model: Affected by multiple factors such as versions, terminals, product iterations, etc., as time goes by, code logic becomes more and more complex, maintenance costs are high, and reuse Low reliability and unable to cope with rapid product iterations.

• Component-based development model: Condensing functional logic into components makes the code more reusable. By combining components, you can complete the system construction and deliver it efficiently.

This article describes the implementation process of component development technology in detail, and I hope it will be helpful to everyone. Everyone is welcome to leave a message in the comment area, or add a WeChat ID: zpc_1994 for further communication.

9 References

[1] Bi Wei. Component-based software development method, 2022, http://mm.chinapower.com.cn/zjqy/gddh/20221207/178571.html

[2] Margaret Rouse.Component-Based Development，2015，https://www.techopedia.com/definition/31002/component-based-development-cbd

[3] UNIC.Component-Based Development，2014，https://www.ece.uvic.ca/~itraore/seng422-06/notes/arch06-7-1.pdf

[4] Kan Yaoguang.appview-auto-degrade-cache, 2022.

[5] Chen Qien. The evolution of concurrent scheduling models in complex concurrency scenarios, 2022, https://mp.weixin.qq.com/s/6o4hQokmRytrb0Hevzly0g

[6] Lu Chen, Zhiyuan, Chen Qi. Practice of GraphQL and metadata-driven architecture in back-end BFF, 2021, https://mp.weixin.qq.com/s/mhM9tfWBlIuMVkZQ-6C0Tw

[7] Sam Newman.Backends For Frontends，2015，https://samnewman.io/patterns/architectural/bff/

[8] Gu Jin. Design process of universal commodity cards, 2022.

[9] Lu Chen, Zhiyuan, Chen Qi. The practice of standardized thinking and assembled architecture in back-end BFF, 2022, https://mp.weixin.qq.com/s/7VlXBl9syw2ppiR3x237bA

[10] Le Bin, Guoliang, Yulong. Exploration and practice of Meituan’s takeout advertising platform, 2022, https://mp.weixin.qq.com/s/Iyd_uYkNI5cH2sv_VwT3NA

[11] Yan Weimin, Wu Weimin. Data Structure (C Language Edition) [M]. Beijing: Tsinghua University Press, 2007.163～183.

---

Framework author

Zhang Pengcheng, Wu Ao, Kan Yaoguang, and Zhao Tianming all come from the R&D Center of Zhuanzhuan Group - Platform Basic Experience Backend Team.

Zhuanzhuan is a technical learning and exchange platform for R&D centers and industry partners, regularly sharing frontline practical experience and cutting-edge technical topics in the industry.

Follow the public accounts "Zhuan Zhuan Technology" (comprehensive), "Da Zhuan Zhuan FE" (focused on FE), "Zhuan Zhuan QA" (focused on QA), and more useful practices, welcome to exchange and share~