preface
In August 2016, I started my first front-end job. Until now, almost three years later, there are more and more things that I can’t get off my chest. The front end of the third year changes quickly, so I feel I should re-recognize the direction of the future, sort out the work income of the third year, and make plans for the next three years. In my three years of front-end career, but also the three years of front-end architecture evolution, I personally experienced these changes, can be said to be very lucky. I have grown from a front-end rookie to a front-end veteran who can be independently responsible for and lead the gateway team, and I have a clear understanding of how a start-up company evolves from a zero-based front-end ecosystem to a relatively complete front-end ecosystem. At the same time, many problems have been found in this process of evolution, and these problems will inevitably remain until they are completely solved.
In this paper, I reach the process of front-end evolution as the main line, with some of the feelings I want to say.
This post was posted on Doumi’s blog
1, point me up to three years of evolution process
The diagram above briefly describes some of the important nodes in the evolution, from the very beginning when the front and back end were tightly coupled to nodeJS for the first time, to the introduction of microservitization, when the front end took over the development and maintenance of the gateway, reminding us that the front-end can do more and more work
Let’s talk about each evolution in detail
1.1 Primitive Chaos State (2016)
When we first came to the company (mid-2016), the front end was packaged with Java, and there was a sense of “we live and die together” in both development and release, so we followed the trend of The Times and started a radical transformation to introduce Nodejs.
1.2. First Taste of Nodejs(late 2016)
At the time (late 2016) there was not much insight into Nodejs, just a taste of the company’s website. The backend data involved is requested at the Nodejs layer using HTTP to the Java side. This is the first time that development and release are decoupled from the server, and the first time that “separation is good for both” is true. The front end doesn’t tie you down too much, and you can get in touch with operations, so why not?
1.3. Start using Nodejs on a large scale (early 2017)
When we first started working with Nodejs, it was obvious how efficient the development was, so we started using Nodejs for all new projects, and all midstage systems started using Nodejs as a gateway. This is when the concept of gateway BFF began to appear in our work. Although the development efficiency is improved, there are still many problems in the front and back end development coordination. After all, with HTTP interfaces, the gateway layer is not aware of Java side interface changes. However, this problem was solved as the overall structure of the company changed.
1.4. Fully introduce microservices and start to use DuBBo protocol (mid-2017)
The introduction of microservices (early 2017) was a huge undertaking, and all Java projects needed a makeover, including the front-end gateway. In addition to having a Dubbo client, the front-end gateway needs to address the collaboration issues encountered during the above phase, so parsing Javadoc becomes a part of all subsequent projects. In the later evolution, we can automatically download and parse Javadoc documents into JS or TS syntax files. Especially with TS, all methods and parameters can be automatically prompted, which can be said to liberate a lot of productivity.
1.5. Traditional Express Gateway abandoned in favor of container concept and AOP model (early 2018)
In the traditional Express gateway model, many shortcomings were found (after all, inexperience), such as weak JS typing, unreasonable code structure, too much redundant code, no decoupling between business and framework, etc. So we started the transformation, using Inversify to build the container, AOP to simplify all the intermediate processes, and all that was left for development was pure business extension. In this new gateway framework, we all use typescript. With the strong typing features of TS, we can do a lot of things that were difficult or impossible to do before, such as the automation of API documents, such as the unification of front-end and back-end types, etc.
1.6. Re-optimization of gateway ecosystem and front-end development process (throughout 2018)
Life pentium more than, toss more than. With nodeJS in use today, maintaining a sustainable ecosystem is a top priority. So we continue to strengthen our foundation as we develop our business. From server performance monitoring to server alarm log monitoring, to business data chart display, user behavior tracking (not done), all reflect our determination to do a good job in the front-end gateway layer.
1.7. Challenge of High Concurrency – Long Connection Gateway (end of 2018)
Finally we went with the flow of history and, after extensive testing in mid-2018, began introducing long-link gateways to challenge the pressure of having 100,000 riders online at the same time. History has shown that we were able to handle up to 400QPS of messages from rocketMq and 100,000 riders online with just four regular servers, thanks to nodejs’ excellent concurrency, and we solved many of the problems we encountered with redis.
1.8. The future is predictable
In the future, we expect to do more construction on the gateway ecology. What we are currently doing is introducing Kong to solve the huge problem of the project, and there are still more problems to be solved
2, point me to the gateway ecology
The front-end ecosystem on the server side is not as complete as Java’s, and a lot of things are still being explored. After so many years of polishing, there is a certain overall model of gateway. The following schematic diagram is the model of gateway ecology, which is what we are doing now and what we will do in the future
The following is a broad gateway architecture diagram:
In the current version of the implementation, the detailed ecology should not only have sustainable business capabilities, but also have a stable and efficient foundation, while providing a wide range of capabilities for development:
3. Click on the development process of the Gateway
In other words, the accumulation of technology is inseparable from the development of business, there is no actual combat of the actual project, everything is an armchair strategist. Therefore, a sound development process can not only improve the development experience, but also ensure the quality of the project. Over the years, in order to achieve the above two objectives, we have continuously optimized the development process, and will continue to optimize in the future. The following figure is the entire process of technical development for reference only:
The technical development process is inseparable from a variety of reviews, such as the code review mentioned above. From the perspective of PM, this process may look like this:
4. Mobile technology stack
The mobile terminal here includes Hybrid H5 and gateway. This technology stack contains major skill points, and each skill point has corresponding knowledge base to be shared internally. The technology stack is fine-tuned as the business evolves and iterates. Although most of it is gateway development, we also undertake the development of mobile TERMINAL H5 page. At present, many H5 pages are still embedded in the driver side and the merchant side. If you are interested, you can download the H5 page and try it out.
5. Team management
This is the first time I’ve talked about team management. I didn’t have much experience before, but after I took charge of mobile gateway from the beginning of 2018, I often reflected on how to take charge of mobile gateway. Although there is no clear title, there has been a great change in my thinking. Making demands is no longer just making demands. I will consider the rationality of demands and the correlation and conflict between demands and demands of the same period. With each requirement scheduling, consider who the requirement fits into the development, and how to manage everyone’s tasks. When it comes to big projects, there are more things to consider, compatibility, release process, and technical solution options, which are discussed with the developers and reviewed before going live.
Some might say, isn’t that micromanaging? Is there time to develop it? In fact, these things because there is a set of perfect development process, a lot of things are solved in the process, will not spend too much time. After all, technology is still my first choice. In the past two years, I have not only paid attention to these things, but also found problems, solved problems and built wheels with others. We start from scratch and continue to contribute to front-end development
5.1. Analyze the problems encountered by the team and current development
I was lucky to know a lot about the team members and the project because I didn’t come into the team out of thin air. Then, in addition to analyzing everyone’s skill points, we looked for issues that affected everyone’s development experience, resulting in this diagram:
Every quarter, we update the problems we encountered during the quarter again. Which ones have been solved? Which ones are solved but not perfect? What are the new issues? In order to give everyone a “all for one, one for all” positive attitude. Let everyone know each other about the development of our team and have a sense of ownership to work. After more than a year of improvement, the changes are still obvious:
5.2. Output unified goals
After taking charge of the gateway, I put forward in the announcement that the core goal of the team is to “build a reliable and efficient front-end gateway team”, and we have been pursuing such a pace. Without reliable quality assurance, all is lost. Therefore, we have implanted many links in the development process to ensure that this goal can be achieved in an orderly manner, such as joining the technical solution review, eliminating risky problem points in the early stage of the project, conducting code review in the branch test to check whether there are problems with code specifications and logic, and in the grey test phase, Use A/B testing to check for additional problems with the project, and layer upon layer to deliver A satisfactory answer for each requirement.
While ensuring quality, we also hope to improve the efficiency of development, and never do anything that can be done by machines. This includes checking, automated testing, and so on, so that we can feel the smoothness of development and have time to do things we want to do, not just business.
In this way, the two positive cycle, complementary and mutually beneficial, can bring great energy to the team.
5.3. Standardize the development process
The standardized development process is the process from getting a requirement to getting it live, as illustrated in the figure above. There have been failures where bugs have been reported online because of missing parts of the process, so it is necessary to ensure a standardized development process.
5.4 Output and maintain the knowledge base shared by the team
Collaboration has become much smoother since the Notion software was introduced across the group. Box-sizing: border-box! Important; word-wrap: break-word! Important; “> < span style =” max-width: 100%; box-sizing: border-box! Important; In addition to these, we also maintain various front-end specifications, introductory manuals, project introductions and other information here, which is not only convenient for team members to check, but also can help new members quickly integrate into the team and start the project. As shown in the figure:
5.5 Encourage team technology and business innovation
In addition to normal business iteration requirements, there are often new systems that need to be developed internally. In the development of new projects, we encourage you to use the latest technology, such as the use of small programs, GraphQL and so on. For projects that are normally iterative, some modules can be upgraded and optimized. On the business side, you can have your own domain model to help the product better plan the refactoring of requirements and so on. After all, the team does not exist independently, we need to cooperate with many third parties, with our own set of new technology foundation, we can choose the best solution in the face of demand.
5.6. Regularly motivate the team
Front-end knowledge changes so quickly that standards are iterated once a year. Therefore, in order to grow faster, we need to constantly update the old and new knowledge, so we regularly organize everyone to have exams. Yes, you heard that right, it’s a test like in school days. Each person can gather questions from various sources and form a comprehensive paper that is closely aligned with the existing technology stack and can be very basic or very open. Each exam question will be maintained and sorted so that you can refer to it at your leisure. In every meeting, I say something like, “If you really want to leave the team and go to a better place, this might help you pass the interview instead of having to memorize all the questions, because we interview every day.”
6, the last
Ok, so much chatter, finally welcome to my personal blog: The blog of Dummy