The front group

In fact, inside we call big front end, the company name is not reported, mother said to low-key, MMM!

system

Different companies define boundaries differently. We divide the boundary mainly into whether it affects the user’s interactive and operational experience, and the efficiency needs to be high (PS: poor!).

Our definition of a front end is an efficient implementation of interactive and high-quality products. So our overall support system is as follows:

  • application
  • specification
  • tool
  • team

application

Ultimately, the front end is responsible for front-end development (your job) and server-side development (application logic).

In order to ensure the high availability of the service and provide a reliable user experience, we mainly did four things in the whole application area:

Experience.

The experience section mainly communicates with the design team. The design team is mainly responsible for: visual specification, interactive specification and interface design. The front-end team is mainly responsible for component abstraction, visual restoration, and interactive restoration.

In the aspect of componentization, we investigated various schemes (in fact, there are many mature schemes in the industry) and finally, combined with various surveys and our own business scenarios, we came to the following conclusions:

  1. We are a data-driven business, so we model our components based on data models
  2. High cohesion solves file management problems and can be quickly stripped and replaced
  3. Unified API
  4. Independent operation
  5. Service consistency

Based on the above conclusions, we encapsulated the first batch of components, but found that the overall granularity was relatively coarse and UI consistency was difficult to be guaranteed. Therefore, we removed a layer of UI components from this layer to ensure UI consistency.

Namespaces are managed as folders, and each component is accessed via index.js.

A state group exists within each component to control the internal logic.

Front end separation

The front and back ends are divided into two parts. Due to the large amount of business data, the speed of a single interface will be very slow. If the scheme of straight out of the back end is adopted to render the page, the page will be blank for a long time. So we use front end SPA and back end self-built service (based on Node.js).

  • spa

    • When choosing the framework, I mainly investigated the following aspects: community, whether it is data-driven, whether it is produced by a major manufacturer, whether it supports IE8 (or whether it can be easily adapted through modification), the overall learning and learning cost of the team (some students are weak), and the scope of the framework is actually quite obvious. React builds large applications that require too many third-party packages to manage state, so the final decision was Angular1.4.7 (with minimal change cost).

    • Vue was the team’s favorite framework (not compatible with IE8 /~), so we tried it on the move, preferring its simplicity to React’s JSX

    • On the PC side, our products are very heavy data products, so the single file in the front end will be relatively large, and the file will be very large after merging through the construction tool. Therefore, we introduced the method of code split to split files by route, and preloaded some scripts (JS and CSS were compressed in one file) after rendering on the main page to optimize the overall experience.

  • The service side

    • Node.js is the main service. Some old systems have Python and PHP. Why choose Node.js?
      1. The whole team is a front-end team, and the overall technology stack is mainly JS. There are only 1-2 students in Python and PHP
      2. The business is relatively uncomplicated, and some of the logic on the front and back ends can be shared
      3. The framework is relatively easy to get started after encapsulation
      4. People are very enthusiastic about this area
      5. One-way communication is relatively easier and more efficient. Ps: The main salary is higher
    • The business is divided into two parts
      1. Mainly responsible for the application research and development of the company’s two product lines
      2. Self-developed products (wechat early warning, wechat Daily, mail service, internal project management platform construction, front-end monitoring buried point, etc.)

monitoring

Monitoring is divided into three parts:

  • The front-end monitoring

    • Because our customers are mainly hotel, encounter problems after their internal on the remote debugging is very difficult to do, but sometimes there will be a user has a problem, through our own account to repetition is hard to found the problem, according to the above situation, we implemented a front-end monitoring system, to capture the user’s operation path and js abnormal level.

    • It mainly realizes two functions:

      1. Operation path capture, after each user comes in, each click of the user is recorded, and the operation process of the user is judged according to the time and elements.
      2. Catch window.error and hijack handleError methods in ng and Vue
  • Service monitoring

    • Monitoring at the process and hardware level is rudimentary
      1. The process guards pM2
      2. Port scanning
      3. If exceptions occur on CPU, memory, or hard disk monitoring, the alarm service is invoked and sent to the corresponding user
    • Deploy special burial points in the business code to monitor specific scenarios
  • warning

    • Middleware services, currently only implemented in two parts:
      1. WeChat warning
      2. Email alert

    The API is used to receive users’ early warning information, and is currently used to send corresponding reports to customers

engineering

In terms of engineering, we provide corresponding tool support, as well as standard operating procedures and documents for each link of project review, development, joint investigation, testing, launching and operation, so as to ensure the output quality and efficiency of each link and smooth transition between each link.

  • The review. Including requirements review, design review, test review.
  • Development. Including style verification, front-end debugging, server debugging.
  • Alignment. Generate mock data automatically according to the API.
  • The test. Provides code compilation, deployment, and simulation of the simulation environment (gray scale).
  • Online. Same as above

specification

Canonicalization is where tools like ESLint and CSSLint ensure that code is styled, and we produce our own code specification (it should be different from team to team, so no shame). The overall quality is guaranteed by the leader of each group, who will review the code of the project regularly (mainly busy, every two weeks iteration, can only spare time to do).

tool

Frameworks are wrapped in familiar frameworks (Front-end Angular, back-end Express),

  • The front end mainly implements namespace control, routing control, codesplit for files according to routing, resource preloading, general interface and method encapsulation.
  • The back-end is self-developed based on Express, simplified API, added automatic route generation, database sub-database sub-table support, multi-person collaboration, port automatic allocation, NGINx configuration generation, business hierarchical processing and other functions

In addition to our usual tools such as compression, merge such as, based on our project we developed the project automatic construction, configuration automatic construction and so on

team

  • share

    • Within the team
      • There will be a sharing meeting once a week, and the theme will be decided by the participants themselves.
      • The content can be project tips, personal feelings, new technology, etc. (there is no moral code, there is nothing limited)
    • The corporate level
      • I organized the sharing meeting at the company level across business divisions, and the effect was quite good. I borrowed the name of FEDAY and wore my own logo shirt. Of course, I would like to thank the boss for his support and the enthusiasm of my partners.
  • Research/self-research

    • People build wheels or develop new things on their own
    • New technology on the radar
      1. Looking at GraphQL, it feels like API is the next big thing, ready to be introduced in the next project.
      2. It is said that the app project will come back to us. Recently I have been watching RN, and of course I have also learned a little OC and JAVA
      3. Others will also understand a little, but depending on the scene, may forget in a few days.
  • conclusion

    • The project. At the end of each project, participants share their thoughts on the current project.
    • The year-end. Each year, everyone reviews the gains and losses of the previous year.

Ps: Hiring? [email protected] front-end, big data, crawler ~~