Front-end early chat conference, a new starting point for front-end growth, jointly held with the Nuggets. Add wechat Codingdreamer into the conference exclusive push group, win at the new starting line.
The 14th | front-end growth promotion, 8-29 will be broadcast live, 9 lecturer (ant gold suit/tax friends, etc.), point I get on the bus 👉 (registration address) :
- Team set up 3 years | small Jue landing – how to promote infrastructure projects
- Team set up 4 years | hall master – how to push the front team infrastructure
- Team was founded five years | how Scott – when people stretch thin project to promote infrastructure
- Team was founded six years | taro – how to implement infrastructure value breakthrough in big front team
- Team set up 12 years | chung chi – how to design large front team construction route
This is the written version of the first lecturer – Xiaojue’s lecture, which is titled “How to Promote the Landing of Infrastructure Projects”. Today’s PPT style is Gaoqiao style PPT which has been lost in the market for a long time, so you can see clearly. Please listen to his views and videos and PPT will be released on the official account of Jue in the future.
The text start
First, introduce yourself
To introduce myself first, I’m from sina mobile based front-end group Mr Fu, I named little Jue, if often zhihu on friends may be more familiar to me, not familiar with the friend also have no relation, I simply introduce my personal experience, the purpose is to let everyone know my previous background, let everybody better into the topic I want to do today.
I’ve actually been in front end development for about 11 years now, and for 15 years now, I don’t write a lot of business code, not not at all, but a lot less. I’ve led front-end teams for a while, and back-end teams for a while, and I’ve built front-end base groups with dashed or solid lines.
Objectively speaking, some of the products we have made may still be encountered online, such as some logos listed in PPT represent products. My two recent working experiences are Gome and Sina, both of whom are in charge of the front-end Team. Sina is now the Leader of the basic front-end Team. Today’s main content is also about my experience and experience of some infrastructure construction work in Sina.
Ii. Infrastructure experience
Next, I will talk about some of my infrastructure experience. In fact, I have been writing business for most of my time since 15 years ago. From PC to mobile era, I have caught up with it, from Nginx Combine service which is commonly used by everyone to Grunt or Gulp packaging. To SeaJS or CommonJS modularity, and finally back to webPack, Rollup. At every point in time, the front end had something to focus on and learn, and at first they were called front-end engineering, and then there was a time when they were called Front-end Unified Development environments, and there was a time when engineering environments for GUIs was very popular in the community. And now I have got the CI/CD server build package. In short, I have experienced and practiced all kinds of gameplay. Under the general theme of today’s sharing session, I understand that they are all part of the front-end infrastructure.
Actually, I started my journey by learning and translating SeaJS code. I made a small wheel for sina’s Team at that time. GitHub could search lithe.js, and then a set of Gulp build plug-ins and corresponding project scaffolding were created. In 2013, it was very fashionable at that time. Later, I remember that I used Gome for a while in 2015, and it was all replaced by Webpack in 2016.
When I returned to Sina in 17 to 20 years, I began to focus on front-end infrastructure construction, from node.js landing to surrounding infrastructure, to front-end monitoring, various system development of packaging and online process, and finally to container service and CI/CD combination. I have made practical attempts in basically all fields.
Iii. Team introduction
Finished the self-introduction, the following began to say about the introduction of our team, of course, more money, less live, close to home is joking, but Sina is really not how to work overtime is true. I’m not going to expand on that.
The team I am in is called Sina Mobile Technology team based below FE. The main Team is responsible for two products, one mobile sina.com and one Sina news App. The front end Team is also divided into two groups. One group is mainly responsible for business undertaking and development, while the other group, namely my side, is responsible for the development of internal system and front-end infrastructure.
There are nine people in our team now. You may be curious, especially for companies without infrastructure teams, about what we do every day, how we set KPI and how we get results. In fact, this is something we have been exploring. My Team was not originally called the infrastructure Team, it was also a business writing Team, but it changed its name this year.
Our main responsibility, in addition to maintaining the original long-term business, is to help develop and deal with some internal problems that cannot be solved by products.
I may be too abstract to say this, but concrete is that I have been here for more than two years, and I have not spent much time dealing with products. I have not done much development related to business, but mostly write some components and services that business needs to call.
Of course, it includes a variety of front-end and back-end services, including BFF layer, framework scaffolding, command line tools, unified monitoring log SDK, and often help business students to do log statistics, analysis and troubleshooting, solve bugs and so on. At the same time, some internal background system with deadline will be output regularly to help business better service development, operation and editing students. The biggest difference between us and the business team is that we do not connect with specific product requirements, because we do not understand the products, and our technical development is the product manager.
How to build an infrastructure team
Before I start talking about the actual case, LET me separate out this small topic to share with you my personal experience, namely how to build an infrastructure team. That’s because a lot of companies probably don’t have this type of team explicitly or specifically. I divided the whole into four parts:
- What kind of people are needed on the front-end infrastructure team.
- What the front-end infrastructure team needs to do.
- What skills the front-end infrastructure team needs to have.
- What personality is more suitable for the front-end infrastructure team?
If you want to set up an infrastructure group within your own company, these questions may help you get started.
1. What kind of person do you need?
First of all, to form a basic front team, choose the right employees is likely to be the first step in the successful start, first of all, he needs to be able to, in the usual business development process, the summarization and sharing, know what good code and bad code what kind, has a certain abstract ability, attention to new technology.
Many people may feel that this requirement and the common front end recruitment requirements as well, but otherwise, in addition to the above conditions, also need when they have a long business development experience, if the fixed number of year of some long, such as 3 years work experience, also can maintain for mentality, so the man must be very suitable for basic research and development of the front-end.
Do we have any graduates or interns in our team? Yes, we do. However, most members of the infrastructure team still need people with the above conditions, because after all, interns and fresh graduates have too little experience in business projects. They can do project implementation, but their ability to promote the implementation will be very difficult. Because they may not feel the real pain points and difficulties of business, and their communication skills may also be inadequate. After all, people are not as good as they say. And the most fatal is that the less experienced students may not understand why to do this abstract, rather than that abstract, without their own thinking process.
For example, we need to make an IM SDK. Experienced people will naturally decouple the message part from the business part, and the message part will be divided into multiple levels of abstract implementation, such as long connection, polling, Flash, WS, MQTT and other different adaptation layers. At least that’s how it starts, and then it expands, and people who don’t have a certain amount of years and experience don’t understand it. For example, many people know how to stop the flow and prevent the shaking, but in what scene to fall these details, students without certain work experience is not able to do, and the code may be finished, the overall scalability is insufficient.
2. What needs to be done?
So, with that said, let’s talk about what the infrastructure guys do on a daily basis.
I just gave an example of IM SDK. Actually, this is just a point. Many of the basic SDK of the front end are in charge of the basic team on my side. For example, buried statistics, performance statistics collection, error statistics collection and other basic libraries, a series of UI-related Vue Components, Hybrid encapsulated JSBridge and API development, joint tuning and so on. These are ammunition for the business team and need to be accompanied by tests, documentation, and Demo outputs, as well as regularly updated maintenance and presentations.
Beyond these basic components and SDKS, what else is there to do? For example, our engineering related construction, as mentioned in the beginning, includes code packaging and launching, CI /CD implementation and specification, automated testing and checking before the code is launched, and even Polyfill code injection during compilation. Finally, there are related different types of project scaffolding, Cli tool development and so on.
Is there anything else to do besides the above? Of course, there are also background systems we use internally, such as operation background, activity background and so on, as well as tool platforms developed by ourselves, such as APP Scheme management platform, Hybrid package delivery platform, Etcd pipe distribution platform, automatic test background and so on.
What else can we do besides maintain these platform jobs? For example, we have special students to follow us in the research of new technologies and tools, the development of new components, architecture design and performance optimization under new business scenarios. Bugfx for some of the underlying components in business iterations and so on.
Of course, finally, our team is capable of developing back-end services independently. We have accumulated a set of Node.js solutions corresponding to the Web framework, some self-built RPC system services, log services, online monitoring and so on, and will maintain part of the online API services. Service template page.
Of course, if business students are under great business pressure, the basic team will also help to write business or do job rotation. In short, it is what the basic team should do to serve business development and empower business technology.
What skills do you need to master?
First of all, people in the infrastructure team should not set limits on themselves, which can be divided into two levels:
First, the language level is not limited, such as Python, PHP, JS, Java, OC, C++, if you need to go on, you can quickly understand and write, at least follow the cat can start to work, this is my most direct request to my following people, we should first become a programmer, and then become a front-end programmer.
Second, there are no limits on the domain level, such as the front and back end and client side skills. We sometimes need to write the background service, then we may need to learn some knowledge of operations, the back-end language tools, and sometimes we need to do some real machine monitoring tools, that is about to learn Java or Python, to real machine operation phone instructions, to level have to intercept the client system, these skills are infrastructure team work need.
Only when there are no limits, can we broaden our horizon. Only when our horizon is wide, can we have more tools and better reflect the differences between our team and others. The growth rate will be faster, the pressure of learning is always the first KPI of the infrastructure construction team, to ensure that they can do what others cannot do.
Another thing is to develop in-house technical products for the r&d team. Everyone is required to have some basic product skills, such as drawing some simple UE interaction, making some design drafts by himself, sorting out requirements and dismantling them for implementation by himself, and I will deliberately exercise this ability in my team.
What kind of personality do you need?
I just said that the character of being restless is actually only a small aspect. When it comes to writing code, I think the most intuitive personality can be divided into two types: radicals and conservatives.
Radicals like to show off their skills in code, trying to use the latest API everywhere, FP, Ioc, OOP, TS, all kinds of tools, concepts, language features can be used, suitable or not suitable, all the same. Conservatives, on the other hand, prefer plain code, which is based on what you can do, and a happy hand.
Teams usually need both types of people, but which personality is needed more on an infrastructure team? I think there is no right or wrong question. If showboating can make performance better and maintainability better, I am all for it. If it is simple, OOP and simple module division can also make the code simple and beautiful to maintain.
What matters is how these two personalities work together and learn from each other. I’m actually a person who doesn’t like to follow code rules and write code, but that’s my personal opinion, and I have to follow it. But I’d prefer to have someone bump into you when you’re writing code, so the quality and logic of the code is better, and the progress is faster.
Therefore, from the above point of view, complementary personality, not aggressive, not troublesome, have the spirit of service to the students are more suitable for building infrastructure. Because in addition to coding, people without empathy can not do well in how to implement your products and make others prefer to use your tools. From designing an API to letting others access your system, you need people who are always working for the benefit of the team.
Fifth, the methodology of infrastructure project landing
Finished talking about how to build a basic front end team, I will talk about the landing tools and products, how to promote some skills.
Five points are summarized, and I will expand them one by one:
1. Thick skin
Let me give you a very practical example.
We developed a Scheme management system last year, which helps us maintain all scheme protocol paths and parameter configurations inside the client, and then can be directly made into a protocol generator, with functions such as re-test page and call up and landing page. Incidentally, even documents are directly supported.
But there is a problem, is the system developed, how to let the client team to use.
The first step must be data entry and maintenance, there are about 60 routing scenarios in our client, each route with 4 or 5 parameters are few, there are also general statistical parameters, public parameters, so the whole data source input, our front end can not do by ourselves, there is no primary material, easy to record mistakes, record lost.
But the client business is very busy, the previous wiki maintenance well, why use your system ah. And check the previous Scheme format and parameters one by one. Years ago after the development of the first version, after the system has not entered a few data.
In order to solve the problem, I did something very simple, in addition to soliciting presentations on the benefits of making wikis dynamic data, and proactively responding to some of the interaction needs of their input. I also used one of the most primitive and useful techniques, which was to hire a team of people to maintain data, and a boss. Then every morning at 10 o ‘clock on time remind, continuous remind for a week, no one to remind me every day I apologize smile remind, private chat remind, finally in my soft and hard under the data finally finished recording.
A lot of people say, is it because your system doesn’t work? In fact, it is not. When all the data is input, the feedback from the client is very positive. It is more convenient to develop and test your own call protocol. No longer need the front end to do the test page, the direct system can generate two-dimensional code, it is very convenient to see the effect, change parameters are more convenient and flexible. The overall feedback is very good, and I love using them, and I have a lot of suggestions for changes.
Therefore, thick skin is the top priority for infrastructure projects. I put it first. For other projects, no matter business or infrastructure, THE longest and best way I can use is to call you every day.
2. Pro-tillage strategy
Personally, if you are a facilitator of a project, especially one that requires teamwork. Each promoter must be familiar with and used, truly understand what problems this tool or system solves, stand in the perspective of the business side, personally use their own system and tools.
Personally feel and think about whether it really solves business problems and improves productivity. If you just think it’s going to be this or that, but in reality, the side effects may outweigh the benefits.
How can you avoid this before you even land a project? At the end of the day, we should actually participate in business development and summarize and refine the methodology and tool set from the perspective of business developers. I think pro-farming is a core competency for infrastructure people.
3, rotational
I talked about pro-farming, but the best kind of ideal is rotation.
By enabling business and architecture people to shift their work on a quarterly basis, they can have a good understanding of each other’s role.
For example, when I was transferred to a team for the first time, I was supposed to be responsible for improving r&d efficiency and optimizing existing packaging tools. But FACED with unfamiliar business, I had no idea where to improve, and I was at a loss.
Then my choice is to give me two actual business first, I experience the last month before. During this month, I will look at other colleagues’ codes and the organization form and structure of different projects. When I write, I will consider how to design and extend the existing structure more reasonably.
I will record efficiency problems and try to solve them. For example, the demo page developed at that time (early 2014) required us to manually upload FTP after building it. This place is very troublesome, but also the new students to install FTP tools, manual operation and so on. Later it was transformed into a scaffold in the configuration function, build after the completion of a parameter directly uploaded to the specified FTP directory (support configuration FTP information).
It is a very simple point, but it really improves the efficiency of debugging. It depends on whether someone finds it and does it. It is difficult to find it without rotation.
4. Dedication
If you have done operations and maintenance students must have this experience.
Basic operation and maintenance services should theoretically not have an accident, because you are basic services, but once an accident is a big deal. The students in the infrastructure group are behind everything they do. Usually if the leader is not particularly technical, although the dirty work has been done, but the outstanding business is always the business.
But the students who do infrastructure must have this mentality, the mentality of dedication. If no one does dirty work, tiring work, difficult work, and everyone does simple work, then your organizational structure must be unreasonable, the development efficiency must be poor, and finally everyone will fly in the mud. I think this is not what the company hopes to happen, so it is also a quality to be able to endure loneliness.
empathy
Empathy, which is a little bit easier to understand, is also a very important skill in getting things done in companies.
Almost everyone who has communicated with other departments has experienced such a situation. Your KPI is not someone else’s KPI… When I ask them to cooperate, they will lower their priority and even put it off.
This kind of situation is too long, so how to break the game, using empathy, if others come to you to do some code transformation, it is not good for their short-term, but will increase some risks and costs in the near future. So no matter what others say, it has nothing to do with me?
In this case, we can think of ourselves as business people and think about what we care more about. The answer is usually human cost, deadline and so on. So if your tools and systems can directly improve the KPI data of the other side or improve the real hard demand of the other side’s business, the project will be implemented naturally. Such as helping others develop automated Cli, such as helping others develop common business components, SDKS and other difficult and difficult things.
So technology works for the business, and architects really understand what the business needs. Then seek truth from facts to think for each other, so as to achieve a win-win.
6. Actual cases
What I said above are some methodology and my personal experience. Right and wrong are my own accumulation, and many people may be tired of listening to them.
Below are some actual cases of our team. Due to limited time, I selected 6 cases. In each case, I will try to explain clearly what it does, what effect it has on the business, and the benefits.
Node.js Web Framework
How to implement Node.js service in the front department? When I first came to Sina, there were only two people making Node.js including me, so it can be said that node.js service there was basically blank before I moved to Sina.
Later, we also started with some simple internal services, such as those internal management systems mentioned above. Frameworks also range from Expressjs to KOA to our own Daruk framework.
In addition to the internal system, we also undertake mobile wave in 18 years of high definition services and watch the services of the article landing page. The whole process is about half a year, from PHP to node. js, to gray scale, to full scale, pv of tens of millions every day.
So this process has been a very good opportunity for me to practice the evolution of Node.js from the inside to the outside, from a management system to an online heavy traffic service, and the first step is to choose a suitable Web framework.
When working on our internal system, I found that koA or Express services lacked a standard directory and development isolation structure, as well as some corresponding business class libraries and tools, and log related construction. So after finishing, we internally developed version 1.0 of the Daruk framework, which is our own internal KoA2-based Web framework.
It includes an enhanced framework for file directory isolation by function, automatic path routing from Controller files, scheduled task functionality, unified logging, middleware performance statistics, global error blocking, graceful shutdown, etc. Of course, 1.0 is not TS based.
Daruk, which we open-source later, was an upgrade to our internal version 1.0. A version developed based on pure TS and supplemented with scaffolding, common modules, and documentation.
There are many benefits to using TS and a separate Web framework, such as making our framework code and business code easier to maintain, simplifying business development, and eliminating more hidden bugs because of the mandatory use of TS development.
Because at the beginning of our development of online heavy traffic services, the most afraid is that we can not be found because of the low-level bugs caused by js compilation errors. We converted to TS development, because of the compile time will be checked, so greatly reduce the occurrence of such low-level bug probability, making the service more stable.
For Daruk, you can go directly to the documentation and source code, although 2.0 I haven’t finished writing, but also open source, if you want to do a TS Web framework, there should be a lot of reference.
For the sake of time, I will only add this diagram to briefly explain the two lifelines of the entire Web service. One is the horizontal request link. Our Web framework adds performance statistics, logging and some built-in global middleware to the context.
The other line is the vertical server initialization link, which includes loading and configuration of local directory modules, automatic initialization of built-in functions such as Timer and various Glues mounting and running, and finally mounting of local middleware and routes.
Of course, in addition to our own research on the Web framework, as I said before, other infrastructure construction at node.js level is also poor. Finally, after sorting out our service launching process and monitoring process, look at the order on the left. First, we go online through the CI driver code of the local warehouse to trigger the rolling and code updating of the Docker container for operation and maintenance. After the launch, we have a full link log system of our own. Through the implementation of Logger module in the framework, together with the relevant SDK and middleware, node.js business standard logs are directly forwarded from the container to the corresponding Kafka. Finally, use the unified monitoring platform of the company’s operation and maintenance department to check our online service logs. (Benefits of logging standardization)
Finally, let’s take a look at some of the services and data we run online using Daruk, some of which you can’t access because they are Intranet services. These back-end services are completely developed and supported by our front-end infrastructure team, which has helped the company solve many practical problems, as well as save online performance and servers due to the PHP switch.
2. Hybrid Release System
I have also talked about this system in my Zhihu Live, here we can take the students who have not heard of it once again.
First of all, in our APP, offline package is a set of offline package delivery process through which the APP pulls the offline package configuration, decompresses the package locally and then associates the service. It can be seen from the picture that when APP is started, it will pull a Hybrid configuration API of our PHP service and pass parameters such as env (environment), Version (APP version) and platform (APP system). Then our PHP configuration API will find the existing configuration from the cache. If a query fails with these three parameters, it will be demoted to our Node.js service, which is the pipe center. Query and cache establishment, and finally returned to the APP end.
This picture shows the content of our configuration API. We can take a look at it briefly. Data contains the offline package configuration for all requested APP versions, systems and environments. Each offline package configuration contains the name of HB, version of HB package, download address, MD5 value, download priority and patch information.
How to distinguish the version of each HB package from different APP package versions, environments and platforms depends on our Hybrid delivery platform, where we can see the configuration, operator, platform download address, environment and other information of each HB package we send. Then manually do APP version association by configuring this HB package, which is the main function of this platform.
Some students may not understand, but how did you get the configuration of these HB packages? How did you get their online address and operator information? In fact, the process is relatively simple. After locally developing an HB business, we package it through scaffolding, and then trigger the TAG of the package through GitLab CI, which drives our CI to carry out the on-line HB package, calculation of Patch information, verification and other steps. Then the information obtained during CI operation is pushed to an API of HB delivery platform through the interface for warehousing and preservation.
In this way, every time we hit TAG and Pipeline in CI, our push configuration can be found in HB delivery platform automatically.
Here I would like to tell you the method of calculating patch. The condition is that if the size of the calculated patch is half larger than the size of the newly generated patch package, and the newly generated patch package is less than 500KB, we will generate patch information. Bsdiff algorithm is used to restore and patch the client and the front end.
Then, the part that we manually associate supports the direct integration of information in an HB package, the quick selection of the whole APP version, and the use of expressions to check, which is very convenient. Meanwhile, it also supports the online audit function and permission management function.
3, Gitlab CI/CD
After the implementation and functions of HB background, you may be interested in our CI/CD process. Now let’s talk about how our GitLab CI/CD is realized. Simply speaking, the TAG triggers the GitLab assembly line, and then the assembly line supports the invocation of different tasks for different requirements. For example, we have different procedures for launching test and online, as well as H5 resources and HB resources.
Now I will talk about the simple implementation process and how to better manage their CI functions.
Since our CI is realized by ourselves, our CI Server is also built by ourselves. We associate our CI Server and CI Runner with our project through internal GitLab token, because we have applied for group token. Therefore, the projects of the whole group will automatically generate corresponding CI Runner, and only gitlab-ci. yML is needed to quickly use related tasks.
See the figure on the right, when we run a CI task, actually the execution code is basically the same. First, we install an internal NPM package, called Ci-runner -script, which contains all our CI task capabilities, or plugin set.
You can use the cli command in this package to pass in GIT environment variable information to determine which stages you need to perform.
Then read the source scaffolding configuration file, CI plug-in initialization and operation, such benefits are very obvious, the unified task function we maintain the architecture group, and the decision is not to use the scaffolding configuration file of each project.
This is actually what our CI command runtime does. We define our CI lifecycle by naming several methods in the RUN method and then instantiating all plugins. Each Plugin can define hook methods with different lifecycles. Each hook method will get the context that needs to be transmitted after the last Plugin is executed, so that information communication and data reversal between plugins can be realized. Finally, by developing different functional plugins, it is ok to do things in various life cycles of CI.
4. Scheme Data Center
This is a system about how to manage APP Scheme. I will not mention the implementation of this system. Daruk at the back end and Vue at the front end are not complicated in the overall project design. We need JSON Diff to identify the differences between different versions of Scheme submissions, a built-in short link system to generate Scheme test pages, and an internal set of dynamic table components that we have been using before. To drive the input of different parameters of different schemes and protocol generation functions.
This is the input interface of our Scheme route. We have divided several types of routes for unified management. During the input, the first-level page contains information such as routes and route function description, etc., while clicking on the second-level page can input parameters and complete documents for this route.
The left side of this diagram is our protocol generator. The whole form is cascled linkage between input parameters and protocols. Select a route and display all parameters of the route. It can be convenient for clients and testers to test, and a TWO-DIMENSIONAL code can be scanned, the real machine debugging function is very convenient.
The whole system is not complicated, and ordinary company schemes do not have so much and need not do so. We have several purposes. One is that the life cycle of our App is too long, so we need a set of standard documents to be exported to external and cooperative departments for dynamic and convenient management. Another purpose is to solve the front-end workload of testing and joint debugging, and finally to solve the problem of document loss caused by personnel flow. We can also export API through this system in the later stage, and provide it to the client side personnel for APP automatic testing.
5, FE Statistical
After experiencing a series of Node.js projects just mentioned, I changed from a front-end to a full stack. In fact, I personally have a big perception that the front-end infrastructure, especially the monitoring system, is too weak, so we later made a series of front-end monitoring SDK, and developed a set of transit system. You can collect logs of different types and front-end formats and then go to our ClickHouse store for secondary analysis and monitoring.
At the beginning, we did a lot of research on competing products, such as BadJS of Tencent, Sentry of open source, Fundebug of charge and other front-end SDK, absorbing some of their functions and features. Then, according to PageSpeed, Lighthouse, Indicators of performance analysis tools such as OneAPM are added to the front-end page to report and collect logs in a unified manner.
So let’s take a look at what happens with the logs we collect. First of all, we’re familiar with error collection as well as performance. We use the key metrics of Lighthouse to set up our own collection and reporting service, which is also an automated set of dynamically configured Node.js services. In fact, the most interesting should be the hijacking monitoring collection, this can go to Zhihu to check an article I wrote, in the face of front-end hijacking what we can do one answer, seems to be thousands of praise, detailed description of the implementation of this system.
Here I have listed the graphs of some performance indicators and error indicators corresponding to our HB and H5. With the help of open source Grafana and ClickHouse, we will have regular tasks to run SQL to do new aggregation every day for big data, and we will definitely meet the requirements for statistics.
This figure is the log dotting diagram of each of our HB business packages. What we want to say here is that these Grafana configurations of each of our HB packages are generated through a set of templates, which are automatically created by a Plugin in our previous CI/CD process. We have the corresponding database for each new HB package. If not, we will create a new monitoring panel, which is very convenient. This is also the advantage of dynamic data.
This page is about the benefits that the monitoring system brings to us. First of all, if there is no monitoring of performance, we cannot optimize and quantify the optimization performance and observe the performance trend. Then there is the error rate and peak drop can also be traced from the log, and finally there is some log accumulation against hijacking, because with your own log system, you can do things and statistical analysis of the function is too much.
There is a point here, how do we count the number of Scheme calls blocked? For those of you who may be curious, it’s actually quite simple. We found that the common hijacking method is to use the SRC of the iframe to drive Scheme creation. Then we changed the createElement method of the page. Then we count the format of SRC and report it if it is not a normal protocol.
Of course, there are many ways to bypass, I will not expand here to say, into the battle of attack and defense, you can think about it.
6, the Universal framework
Multi-end unification this thing, many teams have to do, I share here, how to achieve a set of code around JSBridge end HB page and end H5 page, generate a practical experience of adaptation at both ends.
This image is the front page of our JSBridge documentation, and we can see that the column on the left is the base API that we maintain, providing some capability implementations on the JS side. On the right, I intercept the part of how to write the differential code. In fact, it is very simple. Our scaffolding provides a compile-time variable, which can be changed by configuration, convenient for testing when developing different ends. When writing code, you can make conditional judgments directly based on the compile-time environment.
One big difference and benefit here is that we do syntax parsing at compile time, which removes redundant code from this judgment, leaving less logic at run time and no sense of business.
So how does our JSBridge smooth out this set of apis?
This diagram shows the architecture of our JSB implementation, and we only need to focus on the blue part. The blue part is our internal code implementation, decoupling and module partitioning, which we won’t expand here. For example, we support Mock debugging and save call queues when the JSB is not initialized. If the environment variable is APP at compile time, then our implementation will mount the message communication mode in the original JSBridge. If the environment variable is WAP side, In this layer, we will mount the WAP side and wipe out the layer API. Just like writing business code, compile time distinguishes runtime logic and reduces code volume.
Seven,
After a few brief examples above, I will summarize them again.
Our topic today is how to get the front-end infrastructure project off the ground, not how to implement the specific project. Due to the time, I won’t go into too much discussion, but the amount of space spent, especially in the front, might be more helpful for you to implement the infrastructure.
Finally, I would like to talk about three aspects of the discussion.
1. Necessary conditions for the landing of the front-end infrastructure
The necessary condition to fall to the ground or because business needs, if you don’t need business, done with no one, but sometimes we can’t be business by the nose, such as our offline package release system, the product manager won’t tube you how this thing done, people just need a flexible side internal update feature, as to how you release it, how to manage, Products can’t be thought out, architects need to think. Then we, as infrastructure developers, need to be able to help product and business development students solve practical problems at the system level.
2. The relationship between infrastructure and business
The relationship between infrastructure and business must be business first, but business cannot be separated from the support of infrastructure. How do you find your own positioning, or how do you find demands when no one gives you demands? In addition to the active pull will let everyone discuss the difficulties encountered in daily work, sort out and summarize, but also have a pair of good eyes to find problems, see more and participate in the business, closely cooperate with each other.
3. Team significance
Here are two big truths: when the boss, especially the boss of the technical Team, pk the year-end review with other teams, if your Team is all business output, no system output, this is a terrible thing.
One of the key reasons why big companies have infrastructure teams and small companies don’t is that technology teams in big companies not only keep their heads down but also keep their heads up. It is a must to sort out and summarize the internal service system to improve the efficiency of large team development. It is also a gauge for high-level bosses to inspect the ability of technical leaders below. I will not say more about those who have done rank promotion.
There is also a big truth is, let the team friend have a backbone, the infrastructure team is capable of others can not, let the team have a technical directions, eventually, of course, because of the large technical team, especially the multiple lines of business team, need a part of this focus on developing technical problems of a group of people within the team.
As for the rest, I’ve said enough before. Thank you for listening to me today.
More dynamics of Follow Xiaojue
People who are interested in the sharing of Jue or have questions about jue can visit Zhihu jue, who have followed up the developments of Jue in Zhihu, where they received many positive answers, which are particularly nutritious.
The third phase of 2020.3.28 live online, the theme of “front-end construction”, scan code to pay attention to the “front-end early chat” public account to participate in the registration:
