From the author: Impressed head shared on GitChat. ”
Read the original“Look at what questions people shared with the author

Front-end architecture chatter

When writing a little regret opened such a big topic, the word “architecture” is slightly sacred for programmers, and the scope and meaning is very broad, may everyone each team for the understanding of it is also different, so today don’t delve into itself, but rather about our some of the practices in this aspect.

What exactly is architecture? What is the front-end architecture?

Let’s start with wikipedia’s definition of software architecture.

A software architecture is a sketch of a system. Software architecture describes objects that are abstract components that directly constitute a system.

The connections between components explicitly and in relative detail describe the communication between components. In the implementation phase, these abstract components are refined into actual components, such as concrete classes or objects.

In the object-oriented world, interfaces are often used to connect components.

Traditional architecture is understood slightly differently than front-end architecture, which will be discussed later, but let’s first look at the traditional definition of software architecture.

In these two sentences, several core terms can be summarized: abstraction, decoupling and combination. The actual work of architecture is to sort out and grasp these architectural methods and actual scenes.

At the actual project level, the senior architect is responsible for the overall breakdown of the system, service layering design, etc., while the intermediate architect is responsible for the “system analysis” of certain modules. In terms of project output, they are architecture diagram and system analysis diagram respectively.

The architecture diagram represents the modules of the entire large service and their operational relationships. System analysis, on the other hand, is the specific logic inside each service and how it interacts with external services.

Software engineers can take these analyses and use the framework to implement them according to the architect’s logic. This way of working, the system of large software can be decoupled and implemented properly.

As for software engineers, they do not need to care about how the whole system runs, but only need to realize part of their logic according to system analysis and design, and make large-scale software engineering.

This brings us to the focus of “front-end architecture”.

In fact, the front end is only a part of the whole software engineering, its positioning is more special, not an independent subsystem, but also across the domain between the whole system, and the most important characteristic is that its internal very decentralized.

This prevents us from defining the term “front-end architecture” in terms of traditional software architecture. In fact, what is commonly referred to as the “front-end architecture” in the overall software engineering plays a role under the architecture, above the code of a level, it is not concerned with the decoupling and combination of the whole system, but the horizontal surface of the development efficiency and consistency. (Very complex SPA application scenarios are excluded.)

In fact, many front-end students are very confused about the word “structure”. I don’t think it is necessary to make it into a fixed position or responsibility.

At the project level, or even at the page level, when you have complex interactions and data logic, you make an abstraction, you pull out the components, you design the parameters and internal states of the components, is that architecture? Is, of course! It’s the internal architecture of a tiny system.

The front end is a completely different realm from the server side, which may be viewed as a whole system, then abstracted, then layered, then composed, and at the detailed software level, some fixed composition logic.

As for the front end, there is no concept of the whole. The front end of a company is necessarily scattered between various business systems, although these business systems may also be a whole in the end.

But for the front end, they’re decentralized, and inside each front end, there’s a set of software engineering ideas that, as I said, decouple and abstract combinations of a page. So, we summarize the first meaning of front-end architecture: logical abstraction and composition within a system.

We continue to observe the characteristics of the front end system, also mentioned, in front of the front-end system is distributed, the dispersion is not only achieve the fragmented, even just mentioned abstract composition is distributed, even on the team is distributed, such distributed situation, how to be controlled so that the entire front-end development into an engineering work? This leads to the most important word in the front-end world: engineering.

In fact, this is what we want to summarize the second meaning of front-end architecture: front-end engineering that is central to and rooted in each system.

What is the core focus of engineering? Controllable, efficient!

In fact, everything that follows is all about these two points. From “control”, we have divided into “development framework”, “development specification”, and even some development constraints of “scaffolding”, as well as various “development process” and “development tools” safeguards such as Review mechanism and Eslint checking, online error alarm, etc.

From efficiency, we divide into “component library” to reuse cross-business components, “scaffolding” to encapsulate the whole process into a few fixed commands, and “mock” system to simulate data quickly.

How an architect works and what he does

With the above definition of architecture, let’s take a look at how architecture works on a daily basis. It is usually a reasonable structure for a mature front-end team to have a dedicated team of architects.

This group can be virtual, or it can be specialized and detached from the project, especially when the business development is long and the engineering needs to do a lot of things.

Let’s talk about the working mode of architects. First of all, we should abandon the traditional working thought. When I was in the business team, many things were arranged by special people (such as PM and PD), and then some technical things were often done hastily.

  1. After being separated from the business, the requirements for self-planning, self-task and time management become higher, and have a very strong sense of self-management.

  2. Technical output should have a strict process, because you produce a general solution, to ensure the quality of technical solution, at this time need a process, from problem discovery to research to preliminary solution to review and confirm feasibility to detailed architecture system analysis to start coding to promotion to documentation.

    The process that the whole project team did together may now fall on you, which seems tedious but is necessary because you are a professional architect.

Here I want to emphasize the transformation of thinking, the programmer is generally dislike the things on the process, like just dig in the research on code, but in fact the most simple thing for programmers is to knock the code, if you have always wanted to knock the code do not want to do design/planning/promotion, that is mentally lazy.

What’s the challenge? It’s designing, designing data structures, designing components, designing solutions. The challenge is to make these designs perfect, universal, and landing.

Architecture is not only have been doing so, do interesting things, at the bottom of the research, the realization of the code is just one part of an important measure of the standard is only up to 20% of working time is written in the code, and the less the better, as mentioned above, your job is to design the ground perfect general scheme, solve the specific problem, Instead of digging holes for the team with new technology.

After switching roles, let’s talk about the responsibilities of architecture.

  1. Macroscopically, control the technology selection, technology stack and technology development direction of the whole team. This may seem like a one-time job, but it needs to be optimized over time.

    For example, to promote the transformation of the whole company to Vue or React and to promote the implementation of ReactNative, architects need to have a deep understanding of these technology stacks, be able to correctly weigh and choose, assess risks, and provide practical solutions.

  2. The technical system of each technology stack. Technical system of business development, including scaffolding, development framework, development specification, component library, supporting tools, etc.

    In detail, it’s a huge undertaking, and each part can be developed into a topic. Scaffolding, for example, manages specifications or simplifies the entire process (usually with a lot of customization) of a business project from creation to development to debugging to testing to release.

    For example, the development framework, apart from the underlying MVVM framework, the upper layer needs to do encapsulation, some difficult concepts or cumbersome writing things encapsulated, combined with some mandatory development specifications, and is through the framework layer to avoid the risk points in the development of problems (such as data type conversion and so on).

    Each point mentioned here may be a big project, and there may be several systems, such as the Vue system at our front end, the React Native system at the client end, and the React system at the server interface.

    Some of these systems even need to write the front end instead of the front end. I’ll talk about that later, but the packaging, specification, and tools need to be simple and powerful.

  3. Unified environment management, development and release process formulation, etc. Develop a unified front-end development method/process for the company. Some tools may be needed to improve the development efficiency and promote how these tools are integrated into the process to be accepted.

    There are also front-end development needs of testing, pre-delivery, online environmental resource management methods, permissions, etc. For example, on our team, the rollout of RN’s release integration process is quite complicated (for version locking).

    But business development can be as simple as one or two steps, and this maintenance translates into the final integration result, wrapping complex solutions into a minimalist approach to use, which is one of the key responsibilities of architecture.

  4. Providing special solutions, such as server rendering, may not be difficult in principle, but a dedicated person is required to build a unified service cluster with low intrusion, high performance, high reliability, and high reliability. Services can be accessed at a very low cost without any problems related to operation and maintenance, availability, and performance.

    Others, such as data statistics, cross-end call, need to do some unified encapsulation processing, so that business parties can use.

  5. Special tools and systems such as performance collection, error collection, mock systems, online debugging, visual editing, short chain management, etc.

  6. In addition to THE UI components, the common part of the business is refined and maintained independently, which is called the business SDK. For example, the finance-related wallet business, data business, chat business, panorama business and so on will serve other businesses as an independent business system.

Search vehicle front-end development system

· Front-end development system

Thanks to the fast iterative business, the front-end technology stack of car search is Vue2.0, from mobile terminal to PC terminal, from B-terminal business to C-terminal business to marketing business, so the whole system is developed around Vue2.0. Outline the components of the system.

  • Scaffolding, customized from the official, integration of project management specifications, version management specifications, configuration management, development and release processes, etc.

  • At present, the development framework and specifications are relatively weak. In the future, we will do some deep encapsulation and hierarchical constraints, even request methods and data mapping, mainly to reduce the uncertain risks in business projects and simplify the development process.

  • Component library, including both ends of the UI component library, function library, and some components independent of the component library (such as picture reference library, will automatically switch webP according to the environment, and can optimize the size of the picture, automatic delay loading).

    In this aspect, we have invested more energy, we have component access specifications (to regulate the designer’s design), component development specifications (to regulate the development process of components, to ensure quality and consistency) see the attached picture.

  • Development tools, Mock system (automatic generation of random mock data from back-end interface definitions, Easy Mock), error collection system (Sentry collection for all ends if necessary), external link management (a short chain service).

  • Cross-terminal call, Tower.js + client SDK, can use various Native functions in all apps, such as photos, videos, user information, screenshots, sharing, view stack management and so on.

  • Server side rendering solution, can be low-cost access to any project, with special monitoring operation and maintenance performance optimization.

  • Static resource hosting service, a static resource service based on Nodejs that supports some dynamic functions, some services will be directly hosted through Nginx. In addition, static resource service release mode, authority management and other related scripts and systems.

· React Native development system

The most important goal of the TEAM’s RN development system is to make the client barrier-free to develop RN business. In fact, most of the RN business of the whole team is developed by the students of the client.

Therefore, it is more challenging in engineering. It is necessary to make clients who do not know React, mobx, Flexbox layout, or EVEN JS get started quickly. They can develop business by following the same model, and retain all flexibility.

To accomplish this goal, there are several core points:

  1. The encapsulation of cross-platform differences is one of the problems RN is criticized for. We have made our own encapsulation of the differences of a UI component. The encapsulation mainly consists of two parts, one is Native component, and we have realized some cross-platform lightweight and business-level components by ourselves.

    For example, toast, time selection, picture selection, etc. The other part is encapsulation at the level of RN JS code, such as the encapsulation of navigation and scrollView.

  2. Component libraries, in addition to the usual component libraries (theme colors, forms, tabbars, tabLists, etc.), there are some wrapper components that encapsulate the complexity of the original component to reduce confusion and compatibility issues when using components.

  3. Scaffolding, the scaffolding is more complex than the front-end scaffolding, in addition to the official made a deep customization (directly change the source code), but also do a lot of development process on the function. Deep customizations, such as unpacking logic, analyze the entire dependency tree and weed out common code.

    Development process, from project creation to debugging mode (scan code offline debugging) to release, compile and upload package, automatically upgrade version, tag, request Node server to record version and package information.

    Finally, js bundle is compiled into Maven package for Android and POD package for ios for client development to rely on directly in the project. The whole process is very hidden to the developer, just a few fixed commands, but a lot of work goes on behind the scenes.

  4. Development framework. Because client developers do not know the composition and principles of the React project, to make them write robust applications, they need to fix the project layers and the definition and composition of each layer, which is constrained by the development framework.

    For example, pages can only be defined under Pages (inherited from basePage, which then has some fixed way of defining page properties), child components can only be defined in components, viewModels can be defined under stores, model entities can be defined under Models, Router is automatically managed (generated according to Pages scan). Combined with MOBx, the development mode of the whole application is very fixed, and the structure is simple and clear.

    Further encapsulation is planned, with reference to some server-side framework encapsulation ideas.

  5. Development/sample/template project project, these things are also very important, at the time of project initialization, the project will exist a lot of code, which every step code has detailed notes, basic also can have two sample page, comments are detailed document links, new projects using the template, can quickly understand the meaning of each part.

    In addition, there will be another example folder in the project, which demonstrates the data definition and page writing of some common scenarios. Plus extensive specification documentation, very friendly for beginners.

  6. Function of encapsulation, page jump, network request, cache, global events and other operations encapsulation can library, simplify the use, do a variety of pretreatment.

  7. Strictly control the hot update ability and strictly manage the dependency of RN version and APP version. In fact, we plan to completely close the hot update of RN next month and completely rely on and integrate RN business as a native business. This has two advantages: first, control risks (forced release of version process and version locking). The second is to reduce the confusion when native development integrates and releases RN services.

· Background system page development scheme

All the systems in our team that are not for third party users are developed on the Java server side. In order to achieve this goal, we need to select a UI library (Ant-Design) with high enough encapsulation for the Java server side.

They were then given a way to develop React using traditional Java code and JSP template rendering. So that was the original idea of this scheme, internally known as SAD, actually React for Java.

The details are not detailed, it is the use of the front and back end of the continuous synchronization state to achieve data sharing. As a result, the React component is used entirely as a template engine, with data definition and manipulation logic, and even action logic, done on the Java side.

  1. Provide a complete development framework, front-end packaging + back-end packaging, is a few base classes + some annotations, there are some error handling, form validation packaging.

  2. Provides a visual tool for dragging and dropping JSX code. In fact, most pages do not need to write JSX themselves, but can be dragged out using the tool.

  3. Provides secondary packaging of Ant-Design components and business component packaging to minimize the amount of JSX code that needs to be written for development.

  4. A large number of common scenario processing demos for development reference.

· NodeJS development system

In addition to providing its own infrastructure to support the business, NodeJS also needs to export tools and solutions to the team. Just a quick introduction.

  1. Its own Node development framework, the convention of a variety of layered interface definition verification, its own ORM, there are some internal protocol adaptation, queue system, scheduled tasks, etc..

  2. Some common front-end solutions, such as server-side rendering, painless access to front-end business, do a good job in operation and maintenance alarm performance optimization, etc. There are short chain this system, for the front-end open out of the link to do packet data management and so on.

conclusion

A good architect must have their own sets of work habits, clearly know their responsibilities, know oneself should be the focus, using his experience and methods to control risk, simplify the development, improve efficiency, I hope everyone can become a cow force of the architect, of course it’s all based on the breadth and depth of technology first dig.

“Read the transcript” to view the Chat transcript