background
As a startup, I was faced with a large number of active pages and MVP (Minimum Viable Product) projects during my growth. These types of projects, while not technically complex, give us a headache for several reasons:
-
The project development time is short and the on-line time is urgent;
-
Requirement changes tend to be frequent;
-
With a clear offline time, there is no opportunity for iterative optimization.
These characteristics of the project gave us a lot of pressure in the early stage. Non-stop online, frequent modifications, the growth of technology, etc., let us have some fatigue.
Later, after half a year of honing, we gradually accumulated some tools and experience to deal with this type of project calmly. First, let’s take a look at our overall technical architecture diagram:
Let’s take a closer look at the picture above.
Operation technology capability architecture interpretation
The first is the common requirements template, which has little to do with front-end technology, but has proven to be crucial in helping the product put together a requirements template. Because the project is in a hurry, it is always easy to omit or unclear requirements, if the later modification, the cost will be very high. In the early days, we often encountered requirements such as missing buried statistics and missing platform compatibility. These problems have improved radically since the introduction of fixed templates.
The UI parts
We used Photoshop as the main cutting tool and assisted Cutterman to improve the cutting efficiency with its quick layer and group operations.
Business Technology section
Most operational projects have a pattern, so we developed a component page generation system called “Rubik’s Cube”. This system can support the automatic generation of most of our operation pages. Operators can use the Rubik’s Cube to build personalized pages by themselves, so that the development cost can be directly reduced to 0. We will focus on this system later.
In addition to the relatively standard template page, we also encounter a lot of personalized operation page requirements, for this part of the demand, we made the following tools/libraries to ensure the rapid development of business:
-
Project scaffolding
-
The React UI library
-
Terminal API adaptation library
Scaffolding is a powerful tool for rapid development. Modern front-end development is becoming more and more complex, and the cost of building a project in the early stage is not low. A good project-seed can only focus on the core business during development, without being interfered by tedious configuration.
UI libraries are also a necessity, and companies often have their own business UI libraries. It may not be a perfect package, but it certainly solves most business problems.
The terminal API adapter library mainly addresses the interface unification issues of the page container, such as setting up sharing information. Wechat/Weibo/handq and our own APP are different, so we need a library to adapt.
In addition to the front-end page, we also used Nodejs to develop the back-end interface of some businesses. Practice found that for some businesses with weak back-end logic, using Noejs can greatly improve our efficiency, which will be discussed in detail later.
Componentized development platform
There is a general consensus in the industry that operational projects should use template generation first, and the only question that remains is how to develop a page template platform. The componentized development platform is shown in the figure below:
The UI is relatively rudimentary, but still functional. It is also very simple to operate. With components as the dimension, the operation personnel add/edit components, preview correctly, and finally publish the page. The server will build the page according to the information of operation configuration, and finally distribute the construction results to the corresponding server, thus realizing the publication of a page.
Under the tide of front-end componentization development, we developed this platform in terms of components.
In our view, a page is made up of components, a component is like a function that receives data and returns to the page. Operators select components on our platform, which is similar to importing a package, and then edit the configuration, which is passing data to the components. Once the components and data are identified, we can naturally render the components.
Once the pattern of the component is determined, the first issue that comes along is the storage form of the component. A component, should it be a JSX file? Or an NPM package? Or what? This is a question that we struggle with.
After much discussion, we finally decided to use an NPM package to express a component. NPM’s complete publish/pull and version control mechanism allows us to build the platform quickly with less extra work. Once this was confirmed, our entire development process was as follows:
-
Developers use our component scaffolding to develop components. A component usually consists of a UI display part and a configuration part. When the development is complete, the component can be published on our private server NPM.
-
Enter the Rubik’s Cube component management page and add this component. Thanks to the dynamic loading mechanism of Webpack, the operation personnel can use this component in the following page design.
-
Create a new page in the Rubik’s Cube, add the components we just updated, and then do a series of configurations.
-
After publishing this page, the background Server of rubik’s Cube will export a JSON file according to the configuration information, such as which components are used and the configuration of each component. From the JSON file, the script is invoked, and then the Webpack is used to build the page and distribute it to the server. Because the generated page is built on the server side, the process of pulling the interface of initial configuration information is saved when the user opens the page, and the white screen time is greatly reduced.
Finally, let’s take a look at the technical architecture of the Rubik’s Cube system, as shown below:
This is the current architecture diagram of our system, which supports part of our operation type page. Components are the core. On the one hand, components are connected with UI library, and on the other hand, part of the configuration export API can be provided for other terminals (small program, RN, client, etc.). Then rubik’s Cube platform pulls components through CNPM to provide a visual page editing platform for operators.
Rubik’s cube system we are still in constant iteration, it must have a lot of bad design, very welcome to discuss.
Nodejs middle tier
Nodejs is now being used by more and more companies for different purposes. We also use Nodejs, and one of the goals is to improve the development efficiency of personalized operations projects. For most of our operations, the need for the back end is not high. Usually it is to do some simple storage and call the underlying services, such as getting red packets, lottery, query goods and so on. These services have mature underlying interfaces, so there is very little logic at the application layer. If RD is used, the development may be completed in half a day, but more time will be spent in the stages of requirement review and communication, test launch and acceptance, which is a waste of time. If this part of logic is realized by FE using Nodejs, it can effectively reduce the time of communication and joint investigation, and more importantly, save manpower. We use JAVA at the back end of the project, so we create a Nodejs intermediate layer to realize the interoperability between Nodejs and JAVA.
We’ve written about how Nodejs interacts with Java before, but you might want to take a look at node.js in action: Playing with Java
The front-end monitoring
Operational projects strive for efficiency, which can easily lead to poor quality. In the early days, quality was all tied up in QA and developer skills, but in the long run, online page monitoring is also essential.
There are two main aspects of monitoring:
-
Performance monitoring
-
Abnormal monitoring
Performance monitoring can help us to check the performance of the page. The FE support team has developed a set of performance monitoring system. In the form of plug-ins, after the entry file is introduced, it will Hook the life cycle of the page component through the form of higher-order components. The Performance API is used to obtain the data of each stage, send the data to the background and display the data in buried mode.
The abnormal monitoring part, in the form of Webpack plug-in, adds the error monitoring SDK to the code when generating HTML, and formats the error information and sends it to the background for display. The principle is to use window.onerror to listen for errors on the page. There are also issues to deal with, such as cross-domain script error catching, compression code restoration using Sourcemap, etc.
Afterword.
These are our experiences in developing and operating activities efficiently. For mature companies, these systems may have been around for a long time and be very powerful. But for turning around, we need to improve everything step by step according to the actual business.
Efficiency is an eternal topic. In the next stage, we will find out their common points for more diversified pages (such as animation) and settle them down to improve our efficiency. We also welcome everyone to communicate with us.
About the author:
Huang Jiaxing, head of zhuan front-end operation group.