Shulou(Shulou.com)06/02 Report--

Author: Lao Zhang 888

Original text: https://www.jianshu.com/p/bb8ac7db7e2d problem

"one cloud multi-terminal" has become a trend, and there are more and more terminal types. For example, now that we have PC Web products, we want to extend APP and Mini Program. What shall I do? One way you can think of directly is to add API interfaces to APP and others based on the original, as shown in the following figure:

This is OK, but once a change is encountered, it is troublesome and not perfect to modify several sides of the code at the same time.

"front and rear separation" has become a trend. At the beginning of the PC Web website, most of them use the front-end and back-end integration mode of server rendering. With the development of technology, front-end separation, front-end rendering has gradually become a trend. Accordingly, front-end developers are independent from the back-end team.

The recent rise of APP, Mini Program, etc., is inherently separated from the front and back end.

Front-end, APP, Mini Program and other independent teams, of course, can meet this trend.

Accordingly, the server needs to provide services for each front-end department. In practice, it is often found that there is a lot of repetitive content, is there any way to increase reuse? Or can the back-end be solved only by one "big front-end" department and the rest "big front-end" departments themselves?

The API interface designed by the server, for general service or for UI? Each end has different requirements for data display, to a common API or to a different API?

For example, time shows that the PC side may require the format of "2018-6-11", while the app side may require the format of "2018-6-11". How can the interface give it?

For another example, 20 fields are required for an interface with the same function on the PC Web side, which is already done. Now, because the screen on the app is small, only 10 fields are enough. Should we reuse the old API to make APP tolerate spam, or should we add an additional interface for APP?

Front-end and server-side personnel may have different opinions, which leads to conflict. Everyone has a certain reason, how to coordinate?

The product manager proposed PRD- "UED design interaction draft -" UI design interface-"background design API interface -" background implementation service-"front and back end joint adjustment.

The above is the general development process, the whole process is still relatively long. After the front end develops the static page, it often needs to wait for the background service to be developed before it can be co-debugged, and there is often a waste of waiting time. When the backstage service is ready, the time for testing is often approaching, and the atmosphere is very tense. The whole development experience is often "half sea water, half flame". Is there any way to shorten this process and allow the front end to complete the development on its own without relying on the completion of the background service?

Architecture

From the current situation, after the front and rear ends are separated, it is natural to think of a way for the server to provide services directly to various sides. The advantage of this approach is simplicity and directness, while the disadvantage is that it is not flexible enough. Therefore, consider inserting an intermediate layer between the front end and the back end as a bridge between the front end and the back end to increase flexibility.

For this middle layer, one is "gateway layer or access layer", which may be confused with the existing gateway and access layer in the background. Another name is BFF (Backend for Frontends, the back end that exists for the front end), which is relatively accurate and does not cause confusion.

Gateway layer or access layer

BFF (Backend for Frontends, the back end that exists for the front end)

Solution method

For "one cloud and multiple terminals", you can adapt at the BFF layer. You can consider the pattern of MVVM, where the data from the server is treated as Model, and different ViewModel is provided for various sides in BFF. If the data changes, just modify the Model. If you want to add an end, just add a ViewModel. If you focus on modification here, you can liberate the format conversion work of each terminal.

After "front and rear separation", various ends can be merged into a "big front end", and the window to talk to the back end is BFF. For the back end, as long as the data needs of the BFF are met, the rest is left to the "big front end" to solve on its own.

The API interface designed by the server is oriented to general service, but not to UI. The BFF layer is responsible for adapting the UI differences of various ends. In this way, the back-end can be more focused on business logic and data services, without worrying about the differences between the various sides.

The whole development process is too long, resulting in waiting for each other, resulting in waste. To solve this problem, consider dividing the development process into two parts in the BFF layer. As an independent development department, the "big front end" is ahead of the back end in a release cycle.

Specifically, for new businesses, generating Mock data in the BFF layer means that the back-end service is ready and can be co-tuned directly without waiting. This removes the data dependence of the front end on the back end and makes it more flexible.

Organization structure

In view of the "big front-end" technical architecture mentioned above, the corresponding "big front-end" organizational structure is needed.

Classification train of thought

The "big front end" is for the whole back end, so this layer is divided according to function.

Under the "big front end", is it still divided according to functions? Such as iOS development, Android development, H5 development and so on. This method is feasible, but the benefit is not very large. This is just a "combination" of small departments into a relatively large department, the degree of integration is not very high.

Another division method with a higher degree of integration is to divide it into two sub-departments: "basic services" and "business development" under the "big front end".

The main responsibility of "basic services" is to provide public services, public components, peripheral facilities and so on for the whole "big front-end" department. According to the needs and actual situation, it can be divided into "architecture", "tools", "components" and other groups.

The main responsibility of "Business Development" is to fulfill the requirements of the business unit. According to the business development, divide the group according to the specific business.

Personnel composition

Personnel should be found according to the perspective of professional division of labor, according to the idea of at least 2 people in each role to prevent single point of risk.

The personnel requirements are as follows:

IOS developer: 2 people

Android developer: 2 people

H5 developer: 4 people

Node or Java developer (BFF): 2 people

Administration and Management

The management mode adapts to the organizational structure and adopts the combination of functional management and agile management.

Functional management

The "big front end" is divided according to functions, corresponding to the back end, and is a sub-department under the technology department, which is managed uniformly according to the functional management mode.

Agile management

The interior of the "big front end" is mainly grouped according to the business, and due to the introduction of BFF, the "big front end" can form a closed loop of development, and agile management can be considered.

Agile management requires the support of products and tests. According to the business, the related products, design, testing and development ("big front end") are formed into a virtual team.

Process flow

Corresponding to the management model, the combination of waterfall model and agile model is adopted.

Waterfall model

For functional organizations, it is appropriate to adopt the development process of waterfall model. Product Department, Technology Department, Test Department are generally related to product development, according to the waterfall model. The development mode of separation of front and rear ends is considered here, and the "big front end" can independently complete the development closed loop, although the data in the BFF layer is Mock.

In addition, the development of the large front-end version requires more than one version ahead of the back-end, which is also convenient for testing back-end services. To put it simply, it is to change the usual "back-end function-driven" to "large front-end product pull".

Product PRD-"interaction / UI design -" large front-end development-"large front-end testing -" large front-end internal release

Backend service development-"backend testing -" appropriate version of docking big front end (mainly the work of BFF, Mock data is changed to fetch data from backend service)-"pre-release environment verification -" product launch

Agile model

Products, tests, and large front ends can consider working together to develop according to the agile model. The aim is to break the department wall, strengthen communication, and take business development as the common goal to form a joint force.

The development cycle is 4 weeks, which is allocated according to the proportion of 1-week pre-research, 2-week development testing and 1-week refactoring.

1 week pre-research: the main task of this week is to fully communicate with products, testing and development, and reach a consensus on the business goals of this phase.

The main work of the product is to explain the requirements, prototypes, design, scene description, set priorities, to ensure that team members have a correct understanding of the current business.

The main work of testing is to write test cases, review use cases, and finally through the corresponding tools, the test case data in the BFF layer into executable Mock data.

The main work of the development is to carry out technical pre-research, technical selection, technical design, task division, job evaluation and so on according to business requirements. Complete the requirements of the "planning meeting" and assign development tasks to people.

2-week development: develop according to the agile mode and put the business on the ground. "Daily station meeting" should be held and communicated in a timely manner. Each time the development completes a project, the test can be verified directly, focusing on efficiency. Mock data is uniformly responsible for testing, and development tests use the same set of data to reduce misunderstandings. The end of this period is marked by a "review meeting" two weeks later, where the development test demonstrates the completed business scenario to the product.

One week of refactoring: this week corresponds to a "review meeting" in agile development, as well as a week of full communication among products, testing, and development. The product will be trial run within the company for a week, check and accept, collect feedback, and provide data support for the next phase of product design. On the one hand, the developer can modify the bug, and more importantly, according to the content of the "review meeting", the process can be improved and the "technical debt" can be reconstructed in time. Component development can also be carried out to improve the reuse of code in the future.

What's special about Mock data

In the past, the developer was responsible for the Mock data, either writing the code directly or with the help of tools such as Charles. Now, the Mock data will be uniformly responsible for the test and generated directly in the BFF layer.

In the past, developers had to write self-test code and unit test code; after the test designed use case data, it was generally required to develop self-test through process tools such as JIRA. The current model is to test full-time maintenance of Mock data on BFF, transform the designed use cases into actual available Mock data, develop tests with the same set of standards, and reduce the loss of process and communication.

Internal version

The internal version of the "big front-end" development test is semi-finished and lacks the actual support of the background. After the internal release, try it on the internal test server. The development version runs on the development server. The test is responsible for the Mock of the data needed to run.

This build cannot be given to actual users, but internal products, development, testing can be used, used to experience, find bug, and so on.

For back-end development, it is also very convenient. After the service is developed, there are ready-made products for testing, which can save a lot of trouble.

It is also convenient to report to the boss or show it to the customer, and there are actually available products to experience, even though the data is Mock. This is completely different from looking at word documents, ppt, prototyping, or UI diagrams.

The cost of modification is small, generally speaking, 70% of the work is developed in the background, and 30% of the work is in the "big front end" page. During the week of internal trial, problems found, or requirements changes, can be easily iterated in the next release. At this time, the development of the background service has not yet begun, or has just begun, and the cost of change is very small.

Demand pull

In the past, if you wanted to develop a feature, the first consideration was what the back-end logic looked like. In many cases, it is necessary to modify the presentation of the page, the order of interaction, and so on, according to the existing logic of the back end. It is a "back-end function-driven model"

Now, the product, together with the "big front end", is at least one iteration ahead of the back end. When there is a strong change in requirements, or a controversial point, you can consider making the build run a little longer, such as two or three versions ahead. Wait for the product to think clearly, basically stable, and then go up the back end. In this way, the focus of product thinking shifts from the existing functions of the back end to the actual needs of customers. "demand-driven development model" liberates the thinking of products and makes it easier to design products that meet customer expectations.

The original mode is to push the front end by the back end, but now the mode is that the product and the front end pull the back end, and the mode of thinking is completely different.

"large front-end demand-driven development model": first have an available product, figure out what users like, and then connect to the back-end implementation.

"back-end function-driven development model": first do a requirements analysis, evaluate the existing back-end functions, and then find ways to meet customer needs.

The question is: "do customers or users know what they want? can requirements analysis be effective?" . Relatively speaking, if there is something available that is really in use, it is easier for users to know what they want. For example, "this color had better be changed", "the button here is a nuisance and had better be removed", "here I want to see more information, it is best to add it". and so on

A steady rhythm

Functional organization, waterfall development model, is conducive to risk control, the disadvantage is that the time is too long, the general project at least 1 month, the ability to face demand change is weak. It's a planning-oriented model.

Agile development model, conducive to team communication, the time is generally short, usually 2-4 weeks. As for the risk, consider less, generally use it first, find the problem, and then change it in the next cycle. It is a model that emphasizes experience.

The combination of the two is to achieve a balance between risk and speed and form a steady rhythm. Extending the four-hour planning and review meetings in the agile model to a week is to make cross-departmental communication more adequate, make product acceptance more comprehensive, and reduce risk.

Concentrate resources on "important but not urgent things". Customer needs are important, but it's not that fast from idea to landing. So give full play to the flexible advantage of "big front end", so that customers can see their ideas fall to the ground earlier, which can exceed customer expectations.

"demand change" itself is also a kind of potential customer demand. In many cases, customers don't know what they want before using a product that is actually available. Therefore, the use of two-stage delivery, with a total development cost of about 30% of the "big front-end" semi-finished products, tap the potential needs of customers, can improve customer satisfaction.

"An available product is better than a complete document", although it is a semi-finished product, from the customer's point of view, it is more tangible and reliable than word documents, prototyping, etc.

Attach importance to reconstruction

What about the technology debt? Should we deal with it immediately or wait for it to accumulate to a certain extent and then concentrate on it?

Let the business stop, specialize in refactoring, this kind of opportunity can only be seen rather than sought.

Extending the review session in Agile for no more than 4 hours to an one-week refactoring phase is precisely to solve the problem of accumulating technology debt. To achieve the effect of "changing the engine while flying".

At this stage, the product and business do not stop, in the trial, in the experience, in verifying whether the initial design concept is in line with reality. This leads to a win-win situation of products and technology.

Attach importance to pre-research

Here, the original 4-hour "planning meeting" in agile development is extended to 1 week.

In the introduction of the agile model, there is an assumption that various resources such as requirement determination, prototype design, UI resources, front and rear interface design and so on are ready, and the related feasibility, that is, the pre-research has been completed, and then hold a "planning meeting".

The reality is that the conditions mentioned above are often not ready or missing. In the middle of the development, it is often found that the interaction logic does not fall to the ground, and the prototype should be changed. Or find that UI resources are missing, interface definition is unreasonable, and so on.

In particular, functional organizations, cross-departmental communication, this lack of information is more likely to happen.

Before the formal development, spend a week to focus on communication, conduct technical pre-research, be fully prepared, and find problems before the start of the project, which is meaningful to reduce unnecessary rework.

BFF-oriented programming

BFF becomes the abstract interface between the "big front end" and the back end.

BFF needs to adapt to both sides.

You can consider taking over some public business to achieve the goal of "light client".

Naturally "hot update", BFF uses the back-end technology, doing the "big front-end" work. If there is a modification, update service, it will take effect, a natural hot update.

Natural "cross-platform", BFF this one place to modify, all kinds of ends can work.

Increase control. BFF is maintained by the enterprise, while various sides are in the hands of users. Moving business from various sides to BFF can significantly provide the control of the enterprise.

The boundary here is: "if you can implement it on the server side (BFF), don't put it on the client side unless you encounter serious performance problems."

Pay attention to the performance bottleneck, which is the key node and the butt point of the front and rear ends. Also note that after docking, the Mock data should be cleaned up to ensure that the production version of the data comes from the real backend.

Attach equal importance to efficiency and safety

The "big front end" pays attention to efficiency and responds quickly to changes in the needs of users.

The back end pays attention to security, according to the waterfall model or iterative model, pay attention to risk control.

Through BFF decoupling, the front and rear ends are allowed to run independently.

Thinking

"big front end" is a recent concept. Compared with the traditional front end, the "big front end" has two aspects of expansion. One is the diversity of the end, such as adding iOS,Android, Mini Program, official account and so on. The other is to extend to the backend, such as the rise of Node.js, or writing a backend service is not as mature as Java, and writing BFF is still competent.

The "big front end" is relative to the traditional front end, iOS,Android,H5 and other independent small teams. Promote the integration of the team from two aspects: basic services and business support. Improve reuse and efficiency in several aspects, such as architecture, tool chain, component and so on.

The "big front-end" is gradually put forward with the trend of separation of the front and rear ends, which is relative to the back-end. Therefore, it is necessary to achieve the goal of mutual independence, reducing dependence, mutual cooperation and clear communication with the back-end.

The concept of "big front end" was first spread from Ali. Later, ele.me is the most famous. Now many companies are using it. Together with micro-services, the acceptance is also increasing, becoming a trend.

When the "big front end" landed, there was no fixed model, and the plans of each family were not the same. There are success stories for reference, and there is no mature model for replication. We need to explore and move forward according to our own specific conditions.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.