The problem

  • “One cloud and multiple terminals” has become a trend, with more and more terminal types. For example, now the PC Web site products have been, now want to extend APP, small procedures… . How to do? An immediate solution is to add API interfaces for APP and others on the original basis, as shown in the figure below:


image.png

image.png

This is ok, but when it comes to changes, you have to modify several sides of the code at the same time, which is cumbersome and not perfect.

  • The trend is to separate the front and back ends. At the beginning of PC Web sites, most of them use server-side rendering of the front and back integration mode. With the development of technology, front and back end separation, front-end rendering gradually become a trend. Accordingly, the front-end developers are separate from the back-end team. Apps, small programs, and so on, are inherently separated from the front and back ends. Front-end, APP, small programs and other independent specialized 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 repeated content. Is there any way to increase reuse? Or can the backend be connected to only one “big front end” department, and the rest of the “big front end” department work out its own?


    image.png

  • Is the server-side API designed for general service or UI? Each end has different data display requirements. Do you want a common API or do you want different apis? For example, for time display, the PC side may require the format of “2018-6-11”, while the APP side may require the format of “2018/6/11”. How to give the interface? For example, an interface with the same function, the PC Web side needs 20 fields, which has been done. Because the screen of the APP is small, only 10 fields are enough. Should WE reuse the old API and make the APP tolerate spam information, or add an extra interface for the APP? Front-end and server people may disagree, which creates conflict. Everyone has a certain sense, how to coordinate?

  • Product manager put forward PRD- “UED design interaction draft -” UI design interface – “background design API interface -” background implementation service – “front and back end joint… . The above is the general development process, the whole process is relatively long. After the development of static pages, the front end often needs to wait for the development of background services to be coordinated, where there is often a waste of waiting time. Such as the background service is good, often test time is also approaching, the atmosphere is very tense. The whole development experience is often “half water, half fire”. Is there a way to shorten this process so that the front end can develop independently of the back-end services?

architecture

In view of the current situation, after the front and back ends are separated, it is natural to think of a way for the server to provide services directly to the various ends. The advantage of this approach is simplicity and directness, but the disadvantage is not flexible enough. Therefore, consider inserting an intermediate layer between the front end and the back end to act as a bridge between the front and back ends for increased flexibility. One name for this middle layer is “gateway layer or access layer”, which can be confused with the existing gateway and access layer in the background. The alternative is BFF(Backend for Frontends), which is relatively accurate and does not cause confusion.

  • Gateway layer or access layer


image.png

  • BFF(Backend for Frontends)


image.png

The solution

  • For “one cloud multi-terminal”, you can do adaptation at the BFF layer. Consider the MVVM Model, where the data from the server is used as a Model and the BFF provides different viewModels for various ends. If the data changes, just change the Model. If you want to add an end, you just add a ViewModel. Centralized modification here can liberate the format conversion work of each terminal.

  • After “front and back end separation”, various ends can be fused into a “big front end”, and the window for talking to the back end is BFF. For the back end, just meet the data requirements of the BFF, and let the “big front end” take care of the rest internally.


image.png

  • The API interface designed by the server is for general service, and does not need to be uI-oriented. The BFF layer is responsible for adaptation of UI differences of various terminals. This allows the back end to focus more on business logic and data services without having to worry about the differences between the various ends.

  • The entire development process is too long, resulting in waiting and waste. To address this, consider splitting the development process into two parts at the BFF layer. The “big front end” is an independent development department, one release cycle ahead of the back end. In the case of a new business, Mock data is generated in the BFF layer, which for various ends means that the back-end service is ready for syndication without waiting. This eliminates front-end data dependence on back-end data and makes it more flexible.

The structure of the organization

The “big front end” technology architecture mentioned above requires a corresponding “big front end” organizational structure.

Classification of thinking

  • The “big front end” is for the entire back end, so this layer is divided by function

  • Under the “big front end,” is there still a functional breakdown? IOS development, Android development, H5 development, etc. This is possible, but not very profitable. This is just a combination of small departments into a relatively large department, the degree of integration is not very high. Another, more integrated approach is to divide the “big front end” into “basic services” and “business development”.


image.png

  • The primary responsibility of “basic services” is to provide common services, common components, peripheral facilities and so on for the whole “big front end” department. It can be divided into “architecture”, “tools”, “components” and other groups according to the needs and actual situation

  • The main responsibility of “business development” is to fulfill the needs of the business unit. According to the business development, according to the specific business groups.

personnel

According to the idea of professional division of labor, at least 2 people for each role to prevent single point of risk, the personnel requirements are as follows: iOS development: 2 people for Android development: 2 people for H5 development: 4 people for Node or Java development (BFF) : 2 people

management

The management mode is adapted to the organizational structure, and the combination of functional management and agile management is adopted.

Functions of management

The “big front end” is divided according to the function. Corresponding to the back end, it is a sub-department under the technology department, which is unified under the functional management mode.

Agile management

  • Inside the “big front end”, it is mainly grouped according to business, and due to the introduction of BFF, a closed loop of development can be formed inside the “big front end”, so agile management can be considered.
  • Agile management requires product and test support. Virtual teams of related products, design, testing, and development (the “big front end”) are organized according to the business.

process

Corresponding to the management mode, waterfall model and agile model are combined.

The waterfall model

A waterfall development process is appropriate for a functional organization. Product department, technology department, test department are generally related to product development, in accordance with the waterfall model. Consider the development pattern of front and back end separation, where the “big front end” can complete the development loop independently, even though the BFF layer data is Mock. In addition, the development of large front-end versions requires that they be at least one version ahead of the back-end, which also facilitates testing of back-end services. In short, it is to change the usual “back-end function driven” to “large front-end product driven”.

  • Product PRD – “Interaction /UI Design -” Big front-end development – “Big front-end testing -” big front-end internal release

  • Back-end service development – “back-end test -” docking large front-end suitable version (mainly BFF work, Mock data is changed to fetch data from back-end service) – “pre-release environment verification -” product launch

Agile model

Product, test, and large front ends can be considered for collaboration and development in accordance with agile models. The purpose is to break departmental walls and strengthen communication; Take business development as common goal, form resultant force.

  • The development cycle is 4 weeks, which is divided into 1 week of pre-research, 2 weeks of development and testing, and 1 week of reconstruction.

  • 1 week pre-research: The main task of this week is to fully communicate with each other on product, test and development, and reach a consensus on the business goals of this phase. The main job of the product is to explain requirements, prototyping, design, scenario-describing, prioritizing, and ensuring that team members have a correct understanding of the current business. The main work of testing is to write test cases, review test cases, and finally form executable Mock data from test case data in BFF layer through corresponding tools. The main work of development is to carry out technology pre-research, technology selection, technology design, task division, job evaluation and so on according to business requirements. Complete the “planning meeting” and assign development tasks to people.

  • 2 weeks development: Develop in an agile way and put the business on the ground. “Daily station meeting” to adhere to open, timely communication. The tests can be directly verified every time the development is completed, focusing on efficiency. Mock data is unified by the test, and the same set of data is used to develop the test to reduce misunderstanding. This session ends with a “review meeting” two weeks later, where the development test demonstrates the completed business scenario to the product.

  • Week 1 Refactoring: This week corresponds to the “review meeting” in Agile development, and is a week for product, test, and development communication. The product will be run in the company for a week, checked and accepted, and feedback will be collected to provide data support for the next phase of product design. On the one hand, development can fix bugs, and more importantly, process improvement and timely reconstruction of “technical debt” based on the content of the “review meeting”. Component development can also be carried out to improve future code reuse.

special

The Mock data

  • Previously Mock data was left to the developers themselves, either dead in code or with tools such as Charles. The Mock data is now the responsibility of the test, generated directly in the BFF layer.

  • Previous development to write self-test code, unit test code; After the test designs the use case data, it is typically required to develop self-tests through process tools, such as JIRA. The current pattern is that testing is dedicated to maintaining Mock data on the BFF, converting designed use cases into actual usable Mock data, developing tests using the same set of standards, and reducing process and communication wastage.

Internal version

  • “Big front end” development tests completed builds that are semi-finished and lack the actual support of the back end. After the internal version, in the internal test server trial run. The development version runs on the development server. The data needed to run the Mock is taken care of by the test.

  • This build can’t be handed over to actual users, but internal production, development, testing can be used to experiment, find bugs, etc.

  • For back-end development, it is also very convenient, after the service is developed, there is a ready-made product to test, can save a lot of trouble.

  • It’s also convenient to report to your boss, or to present to a client, with a real usable product to play with, even if the data is Mock. This is very different from looking at a Word document, a powerpoint presentation, a prototype, or a UI diagram.

  • The modification cost is small, and generally 70% of the work is developed in the background and 30% in the “big front” page. Problems, or requirements changes, discovered during the week of the internal trial can be easily completed in the next iteration. At this point, the development of back-end services has not yet begun, or is just beginning, and the change costs are minimal.

demand

  • Previously, when developing a feature, the first consideration was what the back-end logic was like. In many cases, the presentation of the page, the order of interaction, and so on need to be modified based on the existing logic in the back end. It’s a “back-end function-driven model”

  • The product, along with the “big front end,” is now at least one iteration ahead of the back end. At points where requirements change strongly, or where arguments are high, consider making builds run longer, such as two or three builds ahead. Such as the product to think clearly, basically stable, and then on the back end. In this way, the focus of product thinking shifts from the existing functionality of the back end to the actual needs of the customer. “Demand-driven development mode” liberates the thinking of products and makes it easier to design products that meet customer expectations.

  • The original model was that the back end pushed the front end, and now the model is that the product and the front end pull the back end, the thinking model is completely different.

  • “Big front-end demand-driven development” : You have a product that works, you figure out what users like, and then you plug in the back-end implementation.

  • “Back-end function-driven development” : Do requirements analysis, evaluate existing back-end functionality, and then figure out how to meet customer needs.

  • The question is: “Does the customer or user know what they want? Can requirements analysis be effective?” . It’s much easier for users to know what they want when there’s something available and it actually works. For example, “This color better change”, “this button here is an eyesore, better get rid of it”, “here I want to see more information, better add it”. Such as this

Steady rhythm

  • The functional organization and waterfall development model are conducive to risk control, but the disadvantage is that the time is too long. Generally, the project lasts at least one month, and the ability to face demand change is weak. It’s a plan-heavy model.

  • Agile development mode is conducive to team communication, and the time is generally short, generally 2 to 4 weeks. As for the risk, less consideration, is generally used to say, find the problem, the next cycle to change. It’s an experiential model.

  • By combining the two, the hope is to achieve a balance between risk and speed, forming a smooth rhythm. The agile model was expanded from a 4-hour planning and review meeting to a week to allow for more cross-departmental communication, more comprehensive product acceptance, and reduced risk.

  • Focus resources on “important, not urgent things.” Customer demand is important, but from idea to implementation, it is not that fast. Therefore, the flexible advantages of the “big front end” can be played, so that customers can see their ideas earlier and exceed their expectations.

  • “Demand change” is itself a potential customer requirement. A lot of times, customers don’t know what they want until they have something that actually works. Therefore, the use of two-stage delivery, with the total development cost of about 30% of the “big front-end” semi-finished products, mining potential needs of customers, can improve customer satisfaction.

  • “A usable product is better than a complete document”, although it is a semi-finished product. From the perspective of customers, it is more realistic and reliable than Word documents, prototypes, etc.

Attaches great importance to the refactoring

  • What about technical debt? Do you deal with it immediately or do you deal with it centrally when it has accumulated to a certain extent?

  • The opportunity to shut down your business and refactor exclusively is a rare one.

  • The problem of mounting technical debt is being addressed by extending a one-week refactoring phase from an agile retrospective meeting of less than four hours. Achieve “while flying, while changing engines” effect.

  • At this stage, the product and business do not stop, in the trial, in the experience, in the verification of the initial design concept is consistent with the reality. This creates a win-win situation for both products and technology.

Attaches great importance to the preparatory

  • This expands the agile “planning session” from 4 hours to 1 week.

  • There is an assumption in the introduction of agile model, that is, requirements determination, prototype design, UI resources, front and back end interface design and other resources are ready, related feasibility, that is, pre-research is completed, before the “planning meeting”.

  • In reality, none of the above conditions are ready or missing. In the middle of development, you often find that the interaction logic doesn’t fall into place and you need to change the prototype. Or discover that UI resources are missing, interfaces are poorly defined, and so on.

  • Especially in functional organizations with cross-departmental communication, this kind of information loss is more likely to happen.

  • Prior to formal development, it is very meaningful to spend a week on intensive communication, technical pre-research, and full preparation to find problems before the start of the project to reduce unnecessary rework.

Programming for BFF

  • The BFF becomes an abstract interface between the “big front end” and the back end

  • BFF needs to be fitted on both sides

  • Consider taking over some common services to achieve the goal of “light client”

  • Naturally “hot update”, BFF takes back-end technology and does “big front end” work. There is a modification, an update service, that goes into effect, a natural thermal update.

  • Inherently “cross-platform”, BFF is a place to change, all ends can work.

  • Increase control. BFF is maintained by the enterprise, while the various terminals are in the hands of the user. Moving business from various ends to BFF can significantly provide control of the enterprise. The boundary here is: “If it can be implemented on the server side (BFF), don’t put it on the client side unless you run into serious performance issues.”

  • Note the performance bottleneck, which is the key node, the point of contact between the front and back ends. Also note that after docking, the Mock data should be cleaned up to ensure that the production data comes from the real back end.

Attach equal importance to efficiency and safety

  • The “big front end” focuses on efficiency and responds quickly to changes in user needs.

  • The back end focuses on security and risk management according to waterfall model or iterative model.

  • The front and back ends run independently through BFF decoupling.

thinking

  • The “big front end” is a recent concept. Compared to the traditional front end, the “big front end” has two extensions. One is the diversity of terminals, such as the addition of iOS, Android, small programs, public accounts and so on. The other is the rise of back-end extensions, such as Node.js, which may not be as mature as Java for writing back-end services, but BFF is still competent.

  • The “big front end” is compared to the traditional front end, iOS, Android, H5 and other independent small teams. Promote team integration from two aspects of basic services and business support. Improve reuse and efficiency in architecture, tool chain, componentization and other aspects.

  • The “big front end” is gradually put forward with the trend of separation of the front and back ends, and is relative to the back end. Therefore, it is necessary to achieve the goal of mutual independence, reduced dependence, mutual cooperation and clear communication with the back end.

  • The concept of “big front end” was originally spread from Ali, and later ele. me is the most famous development, now many companies are using it, together with micro services, acceptance is also increasing, becoming a trend… .

  • “Big front end” in the concrete landing, there is no fixed mode, each scheme is not the same. There are success stories to refer to, but no mature models to replicate. Need according to own specific situation, grope forward.

Refer to the article

Using GraphQL to construct BFF front-end and back-end separated evolution under microservices: When we talk about the big front end, what are we talking about how to land and manage a “big front end” team? Li Yan, CTO of Marvel Geeks: The road to the big front End – How to use Web technology to unify three terminals (Web, Desktop and Mobile) development