The day before yesterday, several people from the front end team of our company went to dasouche to participate in the “Desouche Node Party” organized by Taro. This is my first offline node.js-related gathering, if you don’t count hangJS.

At the scene of the party

The theme of this party is all related to the current business and technology of Dasoche: Taro tells about the technical evolution and future prospects of Node.js in the team; Death Month analyzes several commonly used ORM features and amway’s own work; Plusman shared log monitoring scenarios and practices. (The presentation can be downloaded from taro’s summary.)

The whole game, although not enlightened, but for our team to do the next thing is more reference. In addition, the party gave me a lot of confidence, which made me think that after we accumulate some experience, we can also summarize it and share it with people from other companies.

Here, I’ll briefly talk about some of the scenarios in which our team uses Node.js. If you read it carefully from beginning to end, you can see where our technology is evolving and where it’s going.

Front-end engineering

Since its inception, Node.js has become a must-have skill for front-end engineers and is used more or less in development. It’s not that heavy, but we use Node.js on our team, mostly using command-line tools to deal with front-end engineering issues.

When I first came to the company, the business focus was still on the B2C parallel import car trading website to buy cars, and the front-end team’s work was mainly new function development and tinkering, and there were overwhelming activity pages.

At that time, there were two Git repositories: one was Webx, a full-stack framework for Java, whose HTML code was written using Velocity templates; The other is static resource files such as CSS, JS, and images that are used for all the project pages.

The front-end engineering problems in the project are serious, and the development comfort and efficiency are low.

Network proxy

Because static resource files are isolated from the backend framework, they cannot be referenced through the relative path of local files at development time. We debug using LivePool to proxy urls in templates that reference static resource files to local files.

Run the LivePool

This approach is used not only to support daily project development, but also to debug online bugs. While it’s nice to be able to solve online problems easily and quickly, development can be a pain in the ass.

Every new file needs to be uploaded to the test server before it can be mapped to the local, and every code change needs to open a new terminal window to run livePool… Do your fingers feel numb? You don’t ma? I ma!

Activities page

In those days, there were so many activity pages that I couldn’t count them. I had to do two copies of each activity, the desktop version and the mobile version. Sometimes, I had to do two activities a day, adding up to four pages.

The active page code is the same in many places, although it is a very timely page, but always copy and paste is not an option. Coders are creatures who hate doing repetitive, meaningless, unchallenging tasks, so they find ways to automate that part and free themselves!

To make your hands feel less numb, the foreman developed a scaffolding “generator-MHC-activity” for an activity page based on Yeoman. After I optimized it, I was able to generate both desktop and mobile versions of the active page frame by typing a simple command into the terminal.

An automated build

The build tool was already there when I arrived, using Gulp. At that time only used to merge, compress files, and did not give full play to its role; And the source code is written in a standard language, which doesn’t make it any more valuable.

As the company shifted its focus to business-to-business “Sell Good Cars,” we had the opportunity to experiment with new development approaches to improve comfort and efficiency.

In the new project, Sass and ES6 styles and scripts are used, together with image files, in the same Git repository with the backend framework. Compile them into the standard language using FIS3, and merge, compress, and fingerprint files at deployment time.

Image upload

Static resource files such as images in the project are stored on the CDN, and the new and changed files are uploaded using node.js scripts written by the worker before publication.

At that time, the script was relatively simple, neither configuration file nor variable can be passed in, each time to manually copy the file to be uploaded to the same directory, the script path to change to that directory to be able to upload, extremely troublesome! And did not do disaster recovery processing, can only be uploaded to the seven cattle, its survival directly affects us…… Unfortunately, this has happened twice already!

Later, I made a lot of optimizations to create RocketZ, a fully functional upload tool that can be configured to support multiple CDNS. With FIS3, you can easily switch from a static resource file to a back-up when you are rebuffed.

Team to customize

When you use more tools, you want a tool that can replace them, that is, contain all of their functionality. To do this, build a wheel based on the team’s needs. I think every front-end team needs its own wheel, and Bumblebee is for that.

Bumblebee is essentially a container that wraps Yeoman-Environment (the underlying layer of Yeoman) and RocketZ through subcommands. Scaffolding and photo uploads are easy to use and cost less memory, management, etc. Why not?

You’ll want to add plug-in installation and build functionality next, if you have the time and energy…

Front end separation

By May, Tuye had a new project to do something with Node.js on top of the existing project.

At first, there was no clear idea of what the project would be used for. I thought about rendering pages without dynamic data, and I also thought about replacing Java completely, but after a lot of thought, it was not very feasible, so I finally decided to use it for front and back end separation. However, for a variety of reasons and it was not necessary at the time, just put up a shelf and left it there. After more than two months, its importance is increasingly prominent, decided to pick up and do it well!

I’m sorry to the organization, please whip me hard…

What is?

The concept of “front and back end separation” is described in many articles on the Internet. In my words, it can be summarized as follows: the “front end” and “back end” should not be divided by devices and platforms, but by concerns and responsibilities — those related to human-computer interaction and data presentation are the “front end”, namely Controller layer and View layer; Everything related to business logic and data storage is the “back end,” the Model layer.

The front end engineer’s job is to put data on the page and provide a great user experience, just like any other client application engineer. So, separating the front end from the front end is exactly what the front end engineer was supposed to do — a return of responsibility.

Why is that?

In traditional Web development patterns, the “front end” simply refers to the View layer in the MVC architecture pattern. In this mode, the development and release schedule of the front end is held in check by the back-end framework and feels enslaved. Every time I have to wait for the back end to publish just a little bit of style change or copy, my heart silently sings —

Get up! People who don’t want to be slaves!

————- “March of the Volunteers”

Coupled to a back-end framework, development is inefficient and communication costs are high, and page changes are slow to release, which is both development and operational unfriendly. On the other hand, the release of a simple change should be a matter of minutes in the eyes of the operators, and if we wait until the evening to release with the back end, they will think that we front-end engineers are “useless”!

In any case, it is imperative to separate the front-end development and release process!

How to do?

In simple terms, the separation is to connect the two independent entities of the front and back end through THE API — the back end focuses on the business logic and outputs the data that needs to be presented through the API; The front-end focuses on data presentation, input and retrieval through apis.

However, the actual system architecture and environment are more complex and may not be as simple to implement as you think, and you need to consider not only how to develop, but also how to test and deploy for release.

At present, we need to solve the following problems: accessing the pages in Java framework and Node.js framework at the same time, and smoothly migrating the pages in Java framework to Node.js framework; Read and write data in different environments; Integrated into an internal one-click deployment publishing system.

Please check out future articles for more details on our team’s practice of separating the front and back ends. -)

Aside from the fact

Recently, I want to use Node.js for many things, such as the smart home system for my own use, the resource information management system of the company, and the intelligent hardware control through wechat robot…

Resource information management system

Ideas are always flowing, but you don’t have the time or energy to implement them.

Plus, I think “front end engineer” will disappear in a few years.


Author: Olay

Source: 51 cto