This article was shared by Xu Haifeng, Head of Product Development at Worktile

In the past ten years, the front-end community has been labeled as the entertainment industry, which is hard to learn. That is, in this decade or so, front-end engineering has gradually entered everyone’s 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 in a startup over the last 8 years. Here’s a simple chart that looks back at the last 8 years:

The birth of 2013 Worktile

Back in 2013, I first heard about Hash routing when I started working as a server-side engineer on the front end: The whole page did not refresh after the browser URL was changed. That year was also the year of the birth of Worktile. For a team collaboration platform SaaS product, the main front-end engineering problem we faced was: front-end frame selection.

At that time, there were not many frameworks to choose from. Vue and React were not yet available. Finally, we chose angular.js as the front-end development framework for the following reasons: Angular. Js is a SPA single-page App for the Web App experience, supporting two-way binding of data, data-driven development, and avoiding manual DOM manipulation.

After choosing AngularJS, I explained the engineering level at that time from three aspects: development, construction and deployment.

  • Development: Third-party dependency packages are manually copied and maintained, the directory structure is divided according to framework functions, and all states are stored in $rootScope;
  • Build: handwritten Node script compression merge via uglify-js2, without using build tools;
  • Deployment: One of the things I remember being particularly impressed by was deployment. Every time the CEO needed to Compare one file by one through Beyond Compare, and then we would look at the changes together, decide whether to synchronize the updates to the server, and then restart the service.

Looking back at 2013, I feel that front-end engineering at that time was basically in a primitive society. The CEO and CTO in that year were also a development engineer, with a total of four people. One front-end was also responsible for UI design, which was basically the form of a newly established start-up company.

In 2014-2015, LessChat was born

From 2014 to 2015, I wanted to make a Chinese version of Slack, LessChat (on the basis of which tasks, network disk and calendar module were added later, which is now called Worktile). Because it was a new product, Based on the past experience, the architecture design of the whole front end must be reconsidered. We also explain the engineering at that time from the aspects of development, construction and deployment:

  • Development: Starting to introduce the package management tool Bower, divide the directory structure according to the module, the module basically means a domain, avoid a component and a function scattered in different folders, at the same time, the front-end introduces the data layer Service as the management state, not all the state exists in the $rootScope anymore. The rest was the introduction of some Lint tools;
  • Build: Introduced Grunt and Gulp build tools successively;
  • Deployment: One-click deployment using mid-transfer Shell scripts instead of Beyond Compare uploads.

2016 Webpack + Modularity

In 2016, one of the biggest changes was the shift in build tools and package management tools, from Gulp to Webpack, from Bower to NPM. In fact, the reason for the shift in tools is modularity, and the front-end is starting to focus on modularity.

Webpack was the turning point for front-end modularity, and Webpack’s support for the CommonJS specification made it possible for the front-end to use the NPM ecology, making Bower obsolete.

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: You no longer have to manually maintain the order that scripts introduce
  • Good for performance optimization: It can be good for Webpack packaging tools to achieve merging, on-demand loading, and more fine-grained module partition and dynamic loading
  • Improved maintainability: According to the module division, each file has a single responsibility, the organization structure is clear and reasonable, and the maintainability is greatly improved
  • Good code reuse:Code reuse is not the ultimate goal of modularity, but rather an incidental value

The most important significance of using modularization and componentization is to divide and conquer (divide and conquer). It can be said that medium and large front end projects finally become maintainable, which is also the meaning of front end engineering. If the front end is not becoming more and more important and heavier, there will be no front end engineering.

Since we’re using the angular. js framework, we basically don’t support modularity. You can get a feel for modularity in angular. js by looking at the figure below.

Here incidentally introduces the development course of modularization:

With the birth of Node.js in 2009, CommonJS came into the public eye. CommonJS is a static modular specification of JavaScript, suitable for Node.js but not suitable for the browser environment, front-end resources in addition to JS also include CSS, images, etc. At the same time CommonJS is synchronous blocking loading, can not achieve asynchronous loading on demand. The AMD/CMD specification was born to enable modularization in browser environments. Whether CommonJS or AMD/CMD, they are the products in the era of lack of language specifications, application scenarios are single, modules can not run across the environment, the building tools are not unified, modules of different specifications can not be mixed, module reuse is not high. Until 2015, ES6 Module dominated the world, front-end modular finally tended to be stable.

2017 Front and rear end separation

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

  • Modularization of the whole station (it takes time for historical modules to be migrated after the introduction of modularization in 2016, and they are all migrated successively in one year)
  • (Prior to 2017, the front and back ends of the Worktile were all in one repository, although it was a SPA single page application and the HTML was rendered on the server side.)

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

Fully static project

For projects with a static front end, HTML files cannot be forced to be cached after deployment. Nginx needs to configure try_files to point to index.html.

HTML templates are server-side renderings

There are two sub-modes for server-side rendering of HTML templates:

  • The first is that the HTML template is in the charge of the server team. The engineering of this mode needs to solve the problem of how to inform the server to update the resources after the front-end construction.
  • The second seed is the big front end, where the front end team uses Node.js to render HTML templates and even maintains them in the same repository as the front end project.

2018 is the first year of front-end engineering

2018, I think, was the year Worktile started front-end engineering. We’ve been using angular. js since 2018, and although there have been architectural changes in the past, introducing modularity, etc., there’s no denying that angular. js is a dead end front-end framework. So I decided to upgrade to Angular for the following reasons:

  • In 2018, the Worktile product is scheduled to launch 8.0, a highly configured project management module with dramatically increased complexity
  • We wanted to start building our own component library, and it didn’t feel like there was a lot of passion or motivation to build based on angular.js
  • Continued use of angular.js will also face recruitment difficulties, as will talent development
  • The Angular framework is now stable enough to be ready for production
  • As for why we did not choose Vue and React, the main reason is that we are more in line with the philosophy of Angular, which solves all our pain points in a large and comprehensive way, with fewer people and no energy to do so

For these reasons, I started reading through the Angular documentation, getting a handle on the hybrid Angular + angular.js solution, and then did a technology sharing session, where we were enthusiastic about introducing Angular directly. It’s also because Angular introduced TypeScript and RxJS together.

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

  1. Built internal component library: NGX-Tethys (considering the size of our team and the business pressure at that time, I couldn’t imagine that a development team with about 10 people in the front and back ends had built an internal component library);
  2. LESS migration of SASS, bootstrap3 upgrade to bootstrap4 (style of sinkhole also need to fill, but all this stepped over);
  3. Using RxJS for state management encapsulates a lightweight state management library for our business. For more details, see Does Angular really need state management?

There are also some problems with upgrading Angular hybrid apps:

  • The first is performance. Integrating Angular zone.js into legacy systems is likely to cause performance problems, and you need to change all binding events that affect performancerunOutsideAngular​ ；
  • Angular. Js uses UI-Router, not the official route. Angular uses UI-Router, not the official route.
  • Although angular. js uses UI-bootstrap and Angular uses CDK, the mechanism for pop-up modal boxes is different between services and components that can be invoked between Angular and Angular. Fork Bootstrap’s component library modifies the source code to solve the modal box conflict problem.

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 build components independently, which may have been unthinkable in the past. With the upgrading and migration of such a complex system coming, what else can’t be surpassed? (I’ll always remember the various ANY’s from the front end when TS was first used)

The birth of 2019 PingCode

In 2019, we started to develop the R&D management tool (independently become Pingcode in October 2020), which is another new epoch-making product. As I said before, technological changes are often closely related to products. In the past 8 years in Worktile, we basically experienced four major product changes. Front-end engineering is basically changed along with the four product changes. Breakthrough changes have been made in development, construction and deployment in this year.

The development of

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

  • Developed the NGX-Planet micro-front-end framework by myself, and all sub-products are stored and deployed independently
  • Because of independent storage, it is necessary to build a business component library and extract common business components
  • The emphasis on unit testing began, with the base libraries forcing unit tests, and the component libraries of the past supplementing the tests
  • The WT-Cronus tool is introduced to clone, update, install and start multiple applications with one key to solve the problem that multiple warehouses are difficult to manage
  • 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 more detail about why micro front ends were used.

build

Jenkins has been introduced for continuous integration since around 2019. Since the front end uses a micro front end, the build uses the Angular CLI based angular-builders extension builder that takes advantage of the Angular CLI. Also flexible to extend the Webpack configuration to fit the micro front – end framework.

The deployment of

As with the construction, Jenkins is used for continuous deployment around 2019, Docker container is used for deployment of all services, and Kubernetes is used for container deployment, expansion and management, which fully realizes automatic operation and maintenance.

Specifications and processes

In addition to the development, build and deployment improvements, 2019 began with the introduction of the Commit Message Commit specification, the branch management specification (similar to Gitflow) and Code Review.

  • With the introduction of Commit Message specification, ChangeLog can be generated automatically for class library projects, and Git Commit records can be tracked better for applications, as well as bi-directional association with Pingcode Agile user stories.
  • Branch management with automatic deployment and release process, make version management and automatic deployment more standardized and streamlined;
  • At the beginning, the problem I worried about when introducing Code Review was whether it would increase everyone’s workload. However, the actual effect shows that the benefits of Code Review far outweigh the disadvantages. Not only has the quality of everyone’s Code been improved, but the ability to read and understand other people’s Code has also been improved.

Why micro front end?

The reason for choosing the core of any technology still depends on the business needs. If the engineering problems encountered by the company can be solved by not introducing the micro front end, then it is better not to introduce the micro front end. Then why did we adopt the micro front end architecture instead of Monorepo at that time?

  • Compatible with legacy systems: When I started to do PingCode, I planned to integrate it with Worktile, which is a huge Angular + angular.js hybrid application. First, the compilation and packaging speed is very slow; second, many engineering things are not standard and it is difficult to modify. It would have been easier to adopt a new architecture (the product eventually chose standalone rather than Worktile integration before launching);
  • 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, the choice of micro front end solves a lot of pain points, but it also brings a series of engineering problems:

  • A business component library must be built after independent warehousing
  • Is the business component library getting bigger and slower to package and publish?
  • True standalone development is not supported; local development starts multiple services such as Portal
  • Local development of child applications requires manual page refresh and does not support Livereload and HMR
  • The system is so complex that it becomes more difficult to understand the overall architecture
  • Without style isolation, subproduct deployments also need to deploy Portal

It is not terrible to encounter problems, and we can solve them one by one. If we had chosen Monorepo, I believe we would also encounter other engineering problems.

2020 Standardization & Process

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

  • Subproducts are truly developed independently, without the need to start multiple services such as Portal
  • Truly independent development of the Livereload and HMR is also gradually supported
  • The determination and implementation of style isolation scheme, each sub-product completely independent deployment
  • The internal devkit toolset is perfect throughwpm release​ 和 wpm publishSimplify the release process

Component document

In the past two years, we have built the component library and the business component library, so the document of the component library is still rough. Another important work in 2020 is to improve the document. In order to improve the document, we have developed a document generation tool, DocGeni-Angular out of the box, which will be officially open source later. Based on DocGeni, we migrated and refactored the documentation for both the component library and the 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.

Development specification & process system

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

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 are still lagging behind, but it is not easy for an enterprise whose front-end team size is less than 20 people.

The year of 2021 has just begun. We will continue to do better front-end engineering and improve ourselves step by step. In 2021 and in 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 the component library, micro front end, Docgeni, DevKit and other infrastructure, so in the future, we need continuous improvement, continuous improvement of testing and documentation. Secondly, we will introduce more automated tools to simplify our workflow, and finally, open source and give back to the community. In the past, we open source the micro front end NGX-Planet, and later we will open source more of our front-end tools and class libraries to give back to the community. This blog I wrote also hopes to let more people know about the road of front-end engineering of Worktile, which may be some reference and help for you who are also a start-up company.

Platform: on the basis of pragmatism, if energy and resources allow, some platform tools will be introduced, such as front-end monitoring platform, grayscale release system, etc.

Write in the last

I have witnessed the progress of front-end engineering of Worktile step by step. It takes courage to share our experience with others. I have never been to Dachang, and I am not very clear about the status of an excellent enterprise with front-end engineering. If you have any ideas about this, please share them with us (especially in domestic enterprises that use the Angular framework). We are working on a new R&D management tool, Pingcode, which is better than JIRA. Welcome to register and learn more about it!

Intelligent R&D management tool Pingcode – official website