This article is written by the head of Product Development at Worktile@ xu haifeng gotshare

In the past decade or so, front-end engineering has gradually entered the field of vision, and more and more companies have begun to pay attention to front-end engineering. So what is the front-end engineering can reference shortly before I answer in a zhihu What is the front project, in the past two years the front-end engineering basic stable, every company precipitated its own set of engineering practices and tools, so this article is mainly to share Worktile from 2013 to 2020, the front end of the road engineering, Let’s take a look at the evolution of front-end engineering for a startup over the past eight years. Here’s a quick chart to look back over the past eight years:





The birth of 2013 Worktile

Back in 2013, I first heard of Hash routing as a server engineer starting out on the front end: The same year that Worktile was born, the main front-end engineering problem we faced as a team collaboration platform SaaS product was the selection of the front-end framework.

There were not many frameworks to choose from. Vue and React were not yet available, so we chose angular. js as the front-end development framework for the following reasons: Angular.js is suitable for SPA single-page Web App experience. It supports bi-directional data binding and data-driven development, avoiding manual Dom manipulation.

After choosing AngularJS, I explained the level of engineering in terms of development, build, and deployment.

  • Development: third-party dependencies are manually copied and maintained, directory structure is divided according to framework functions, and all states are stored in $rootScope;

  • Build: a Node script was compressed and merged by hand using uglip-js2, without using a build tool;

  • Deployment: ONE thing I remember being particularly impressed with was deployment, where every release the CEO had to go through Beyond Compare file by file, and then we looked at the changes together and decided whether to synchronize the updates to the server and then restart the service.





Now looking back at 2013, I feel that front-end engineering was basically in the primitive society at that time. The CEO and CTO of that year were also a development engineer, and one front-end was also responsible for UI design. This is basically the form of a start-up company, and the product can run quickly, no engineering is required.

LessChat was born in 2014-2015

In 2014-2015, I was working on LessChat, a Chinese version of Slack. (Later, based on LessChat, I added tasks, network disks, and calendar modules, which is now Worktile.) Based on past experience, it is necessary to reconsider the architecture design of the whole front-end. We also describe the engineering at that time from the three aspects of development, construction and deployment:

  • Development: Start to introduce package management tool Bower, divide directory structure according to module, module basically means a domain, avoid a component and a function scattered in different folders, at the same time introduce data layer Service as the management state, no longer all states exist in $rootScope. The rest is the introduction of some Lint tools;

  • Construction: Introduced Grunt and Gulp construction tools successively;

  • Deployment: One-click deployment using the Shell script of Zhonglian, no longer using Beyond Compare upload.





2016 Webpack + Modular

In 2016, the biggest change is the transformation of build tools and package management tools, from Gulp to Webpack, from Bower to NPM. In fact, the essence of the transformation of tools is: modular, the front end began to pay attention to modular development.





Webpack was a turning point in front end modularization, and Webpack’s support for the CommonJS specification made it possible for the front end to use the NPM ecosystem, and Bower was eliminated.

On the front end before introducing modularization, in order to avoid naming conflicts, generally USES the namespace and the method of executive function, named after introducing modularization conflict problems and solutions, as no longer packing a since the executive function, so in addition to solve the naming conflicts, the value of introducing modularization to bring far more than that.

  • Easy dependency management: No more manual maintenance of order issues introduced by Script

  • Improved performance: Webpack packaging tools can be used for consolidation, loading on demand, and more granular module partitioning with dynamic loading

  • Improve maintainability: according to the module division, each file single responsibility, clear and reasonable organizational structure, maintainability is greatly improved

  • Good for code reuse: Code reuse is not the ultimate goal of modularity, but an incidental value





The most important thing about using modularity and componentization is divide and conquer (divide and conquer). You can say that large and medium front-end projects are finally becoming maintainable. That’s what front-end engineering is about.

Since we use the Angular.js framework, we can basically say that modularity is not supported. You can get a sense of the modularity of Angular.js in the following figure.





Here, by the way, is a brief introduction to the development of modularity:

With the birth of Node.js in 2009, CommonJS came into our sight. CommonJS is a static modular specification of JavaScript, which is suitable for Node.js but not for browser environment. At the same time, CommonJS is synchronous blocking loading, can not achieve asynchronous loading on demand. In order to make modularity available to the browser environment, the AMD/CMD specification was born. Both CommonJS and AMD/CMD are products of the era of lack of language specifications, with single application scenarios, modules that cannot run across environments, different building tools, modules with different specifications that cannot be mixed, and low module reuse. It was not until 2015 that ES6 Modules dominated the world that front-end modularity finally stabilized.

2017 Front and rear ends separated

In 2017, Worktile front-end engineering did two things:

  • Full station modularization (after the introduction of modularization in 2016, it takes time to migrate historical modules, and the migration will be completed gradually within one year)

  • ** Front and back warehousing separation (** Before 2017, Worktile was both front and back in one warehouse, although SPA single page application, HTML was server-side rendering)

Speaking of front and back end separation, here are two modes of front and back end separation

All static project

For projects with an all-static front end, caching of HTML files is not mandatory after deployment. Nginx needs to configure try_files to point to index.html.





HTML templates are server-side renderings

There are two submodes for server rendering HTML templates:

  • The first is that the HTML template is the responsibility of the server team. This mode of engineering needs to solve the problem of how to inform the server to update resources after the front-end construction.

  • The second seed model is the big front end, where the front end team uses Node.js to render HTML templates and even maintains them in a warehouse with the front end project.

2018 First year of front-end engineering

2018, I think, is the first year that Worktile started front-end engineering. We were using Angular.js until 2018, and although we had made architectural changes in the past, including modularity, there was no doubt that Angular.js was the obsolete front-end framework. There were several reasons for the bold upgrade to Angular:

  • In 2018, Worktile is planning 8.0, a highly configurable project management module, with a dramatic increase in complexity

  • We wanted to start building our own component library, and it didn’t feel like there was a lot of passion and motivation for angular.js

  • Continuing to use Angular.js will also be difficult to recruit, as will talent development

  • The Angular framework is stable and ready for production after release

  • As for why we didn’t choose Vue and React, we are more in line with Angular philosophy, which solves all our pain points in a big way. There are fewer people and no energy to toss around

For these reasons, I started to read through the Official Angular documentation, and got a feel for the Angular + Angular.js hybrid solution. Then I did a technical share. Angular also introduced TypeScript and RxJS together.

In addition to upgrading Angular, we made the following major engineering improvements in 2018:

  1. Built an internal component library: NGX-Tethys (it was unthinkable for us to build an internal component library with a development team of about 10 people in front and back considering the size of our team and business pressures at the time);

  2. LESS migrates SASS, bootstrap3 upgrades to Bootstrap4 (style sinkhole also needs to be filled in, but it is all stepped over);

  3. Using RxJS for state management encapsulates a lightweight state management library suitable for our business. For more details, see Does Angular really need state management?

Upgrading Angular hybrid apps also presents some problems:

  • The first is performance. Angular zone. js integration into legacy systems has a high probability of performance problems, requiring all binding events that affect performance to be changed to runOutsideAngular.

  • Angular.js and Angular routing still have some conflicts, synchronous routing, etc., which requires constant attempts to write code that will never be understood. Angular.js uses a UI-router, not an official route.

  • Although services and components between Angular.js and Angular are callable to each other, the mechanism for popping up modal boxes is different. Angular.js uses UI-Bootstrap, Angular uses CDK, so hierarchy conflicts can be tricky. Fork Bootstrap component library modifies source code to resolve modal box conflicts.

Back in 2018, because the technology upgrading and new business does bring a lot of pressure, we have a lot of technology selection is increased the burden of you, but it is very worth it, because the technology upgrading for the front-end team brought great motivation and ability of ascension, a lot of friends in this year can master TypeScript. It also has the ability to independently build components, which may have been unimaginable in the past. Upgrading and migration of such a complex system have come over, and what else can not pass? (I’ll always remember when the front end started using any of TS)





The birth of 2019 PingCode

In 2019, we started to develop a research and development management tool (PingCode was independent in October 2020), which is a new cross-era product. I said before that technological changes are often closely related to products. In the past eight years, I have experienced four major product changes. The front-end engineering basically changed along with these four product changes. For this year, breakthroughs were made in development, construction and deployment.





The development of

In addition to continuing to choose the Angular framework, the most important thing for development is the introduction of the micro front end, which I shared earlier: ToB enterprise applications that use Angular to build a micro front end architecture

  • I developed the NGX-Planet micro-front-end framework by myself, and all sub-products were stored and deployed independently

  • Because of independent storage, it is necessary to build a business component library and extract business common components

  • Unit testing became important, the base libraries mandated unit testing, and the component libraries of the past supplemented testing

  • The wT-Cronus tool was introduced to clone, update, install and start multiple applications with one click to solve the problem of difficult storage management

  • The front end is a fully static SPA single page application

At this point you must ask: why not Monorepo? Finally, I’ll go into a little bit more detail about why we adopted a micro front end.

build

In 2019, Jenkins was introduced to the front and back end for continuous integration. Since the front end uses a micro front end, the build uses angular-Builders extension builders based on the Angular CLI, which takes advantage of the convenience of the Angular CLI. The configuration of Webpack can be flexibly adapted to the framework of the micro front end.

The deployment of

Like construction, Jenkins was used for continuous deployment in front and back ends in 2019. Docker container was used for deployment of all services, and Kubernetes was used for deployment, expansion and management of containers, which fully realized automated operation and maintenance.

Specifications and processes

In addition to several improvements in development, build, and deployment, 2019 saw the introduction of the Commit Message Commit Specification, branch Management Specification (similar to GitFlow), and Code Review.

  • With the introduction of the Commit Message specification, Changelog can be generated automatically for library projects, Git Commit records can be better tracked for applications, and PingCode Agile user stories can be bidirectionally associated.

  • Branch management with automatic deployment and release process, make version management and automatic deployment more standard and process;

  • At the beginning, I was worried about the introduction of Code Review: whether it would increase the workload of everyone. According to the actual effect, the benefits of Code Review far outweigh the disadvantages. Not only has the Code quality of everyone been improved, but also the ability to read and understand others’ Code has been improved.

Why micro front end?

The reason for selecting the core of any technology is still determined by business requirements. If the engineering problems encountered by the company can be solved without introducing a micro front end, it is better not to introduce a micro front end. Then why did we not adopt Monorepo and adopt a micro front end architecture at that time?

  • Compatible legacy systems: When I first started working on PingCode, I planned to integrate it with Worktile, which is a huge Angular + Angular.js hybrid app. On one hand, the compilation and packaging speed is very slow. It would have been easier to adopt a new architectural design (the product eventually went standalone and did not integrate Worktiles before launch);

  • Team more children products: at first, it includes four subsystems products, each product is independent of the Scrum team is responsible for, and in the future is expected to have more team do more for the product, so far include private and rolled off the production line of products, a total of eight, team management and warehouse management must be separate ideal;

  • Applications market: early in the product planning, our goal is to want to make like jira rich application market, is in addition to loading officials of the products will be loaded application market of embedded application, even after there will be a third party to develop embedded applications, the current “to do” and “gantt chart” two embedded application is to do our internal application.

Of course, although the choice of micro front-end solves many pain points, it also brings a series of engineering problems:

  • A business component library must be built after a standalone repository

  • Is the business component library getting bigger and slower to package and deliver?

  • True independent development is not supported, as local development starts multiple services such as Portal

  • Local development of sub-applications requires manual page refresh and does not support LiveReload and HMR

  • The whole system is so complex that understanding the overall architecture becomes more difficult

  • There is no style isolation and Portal deployment is also required for sub-product deployments

Problems are not terrible and can be solved one by one. If I had chosen Monorepo, I believe I would have encountered other engineering problems.

2020 Standardization & process

With a series of engineering problems brought by the micro front-end, we have entered the year 2020, which is mainly to solve this series of problems:

  • The sub-products are truly independently developed without the need to start multiple services such as Portal

  • LiveReload and HMR are gradually supported after truly independent development

  • Style isolation schemes are identified and implemented, and each sub-product is deployed completely independently

  • The internal DevKit toolset is complete, and the release process is simplified through WPM release and WPM Publish





Component document

In the past two years, we have built component libraries and business component libraries, but the documentation of component libraries is still rough. Another important work in 2020 is to improve the documentation. In order to improve the documentation, we developed a document generation tool docgeni-Angular out-of-the-box component library document generation tool (which will be officially open source later). Based on Docgeni we migrated and refactored the documentation of the component library and business component library.





Test coverage

Component library and business component library of test coverage rate to 70%, because of the debts of the past too much, for our service has been higher than the front end test coverage requirement, the service side of normal product unit test coverage is more than 80%, basic supplement test is a persistent engineering problems, but also defines the test coverage indicators of the company.





Develop specifications & process systems

In addition to the above, I think that 2020 is the year when Worktile begins to standardize and streamline. WTC (Technical Committee) released 16 development specifications and 16 process rules.





2021 and the future

Above is Worktile engineering over the past eight years, as a startup, it is not easy, because there is no too many resources, we have to ensure product high speed of iteration at the same time improve the front-end engineering, development tools, or component library are joint efforts among all the members of the business team front end as a result, may be giant and horizontal comparison, We’re still way behind, but it’s not easy for a business with a front end team of less than 20 people.

The year 2021 has just begun, and we will continue to do better front-end engineering and improve ourselves step by step. In 2021 and the future, I think we will continue to make efforts from two aspects of pragmatism and platform.

For pragmatism: In the past, we have built component libraries, microfront ends, Docgeni, Devkit and other infrastructure. In the future, we will continue to improve our testing and documentation. Secondly, we will introduce more automation tools to simplify our work process. In the past, we have opened source ngX-Planet, a micro front-end, and we will open source more of our front-end tools and libraries to the community, including this blog post. I hope that more people can learn about Worktile’s front-end engineering path, and maybe you can refer to it and help you as a startup.

** Platform: ** on a pragmatic basis, if energy and resources allow will introduce some platform tools, such as: front-end monitoring platform, grayscale publishing system and so on.





Write in the last

I have witnessed the progress of Worktile’s front-end engineering step by step, and it takes courage to share our heart process. I have never been to a big factory, and I am not very clear about the status of a particularly excellent enterprise with front-end engineering. If you have any ideas about this, please share them with us (especially domestic companies using the Angular framework). Finally, an advertisement: We are making PingCode, a research and development management tool that is better than Jira. Welcome to register and learn about it!

Intelligent r&d management tool PingCode-官网