This article discusses why you choose Node from a business scenario, and the shortcomings you need to address when writing back-end code from the front end.

These days I have been experimenting with Node, and more or less I have received strange looks from people around me and even questions from people behind me, which makes me think about why I am doing Node. Do a web search for “Why Use Node” and you’ll find a lot of articles about Node in terms of its inherent features: concurrency, event-driven, non-blocking I/O, single-threading, streaming, community ecology… And so on, very little about business scenarios. I’m a pragmatist and have said that talking about architecture outside of a business scenario is a hooligan. Since I started from the front-line business, after several years of thinking about business, I think I can explain why Node is more suitable for our business from the perspective of business scenarios.

Start with the business scenario

Nowadays, our business modularization is becoming more and more common. Few businesses are pure and can only be solved by linking to a database. There are often N more API services to support the front desk business. For example, the following two situations are common in our actual development:

  1. The data required for a page comes from two or more interfaces, and the two interfaces come from different teams/departments. For example, user information comes from the account department and UGC data comes from the business department
  2. A page has interface dependence, so interface A needs to be called first, and interface B needs to be retrieved according to the data of interface A. For example, personalized recommendation usually requires the recommendation system to obtain the ID of the recommendation data according to certain dimensions, and the content needs to obtain the ID of the specific metadata according to the needs of the page

In the above two cases, from the perspective of background development, our business modules should be separated and independent, while from the perspective of the front end, these data are needed by a page, and the front end hopes to be an interface to return to me. It’s a start.

Of course, backend developers, such as PHP, also have solutions for concurrent requests, and a good backend engineer will help consolidate requests in the background into a single piece of data or interface, and then throw it to the page. In real development, for example, our front-end would write (and maintain) a template.class.php (I’d say 80% of our backend engineers have never seen this code). View layer, and then in the Action to pass data to the View layer for rendering, the following code:

$this->render('xxx/xx.tpl'.$tplData);
Copy the code

This increases the communication cost and reduces the development efficiency. For a page, the front end needs to communicate the data format of the page with the background according to the data the page wants, and then the background engineer looks for the API module behind them to ask for data and process data. There will be some “gray areas” in this process, and it is not clear who is more appropriate to do it.

This is often done in a variety of ways. For example, introduce backend templates (such as Smarty) and then agree on the data format. The front end writes Mock interfaces based on the data format. A little more Low team, will take the front end to do a good job of the page thrown to the background engineers “set of pages”, such as: PHP code to write HTML, various
< p style =” max-width: 100%; clear: both;

Another way is to simply turn the background into a “proxy server”. When I receive the request, I forward it to the API behind, and when I get the data, I return it to the front page, making it a “cross-domain” interface, so it becomes a lot of WebApps.

In addition, from the perspective of the personal development of background engineers, maybe they think that the repetitive work of “package interface” has nothing to do with their promotion and technical development.

At this point, some people must be thinking: this is your big company only have problems, our small company does not have such problems! Let me turn to the technical side.

Start with technology

Explain why the front end is better at doing what the front end does in three of the most common aspects of development: performance optimization, engineering, and solutions.

Performance optimization

The front-end page is an important carrier, and problems or poor page experience will cause direct harm to users (we are all bad guys). Page performance is obviously a top priority on the front end, but how much of a concern are these things to the backend engineers? When you find that the optimized projects have been optimized, the remaining optimization projects need to be optimized together with the background engineers, and then push the background engineers to participate in the front-end optimization project.

Engineering scheme

In addition to the front-end page performance optimization projects, there will also be some engineering work to help improve the front-end development efficiency and experience, but in fact, only the front-end is not able to handle, such as:

  1. According to the resourcemap done by the packaging tool, realize the CDN address combo output and separate output of static resources on the page (debugging stage)
  2. Extend Smarty syntax to realize template componentization
  3. Simulated background data interface, output fake data rendered pages

These engineering work itself front-end understand very clearly, but the background engineers will have how much understanding? How is it impossible to involve backend engineers who don’t know the front end? It takes a lot of time to explain what to do.

The solution

As for the solution, if we want to make the page chunked, separate dynamic and static data, and display data that doesn’t depend on interface data first (such as the Nav on the front screen), then we also rely on the code of the background engineer. A little bigger, we last similar Bigpipe scheme, so the dependence and transformation of the background is greater.

What about technology?

There are two solutions to the above appeals: the front end of their own sleeves, they either write directly like PHP to implement, or write non-existent Smarty extension code; Another is to appoint a “technical product manager”, specialized projects to do these projects, by the “technical product manager” to coordinate the needs of the two sides, to avoid “chicken talking with duck”. However, the pressure of business department projects is very great, and there are few such projects, and the technical team, it is difficult to go deep into the business, often too high, work out things are not practical, or too high new cutting-edge, resulting in accusers to the environment, forced to push up, the business team sad. I have also said that any structure that is detached from the business is a rogue.

Why Node

Using Node has the following advantages:

  1. Natural event drivers can be used to handle concurrency
  2. Reduce front-end and back-end collaboration costs and improve development efficiency
  3. Clear-cut responsibilities, front-end er is responsible for front-end problems and solve them by himself
  4. The front and back ends are homogeneous, and the front end solution is synchronized to the Server side
  5. It is beneficial to the personal development of the students at the front and back end

What business scenarios use Node

In the meantime, figure out what business scenarios to use Node for:

  1. Page requirements are high, and there are iterations from style to performance
  2. Rich back-end interface, page data resource side
  3. Pure rendering, low requirements for security, no computing power
  4. In the end, the most important thing is the ability of the team (I’ve also said that any structure that leaves the team is a bully).

Questions about Node

When it comes to “We’re going to use Node”, it’s often met with the following specific criticisms:

  1. Stability: Mainly single-threaded exception handling
  2. Asynchronous callbacks increase program complexity and are not conducive to debugging
  3. Interconnection capability with background interfaces
  4. Workflow: code deployment, online
  5. O&m support: access, capacity management, logs, and monitoring
  6. Node version upgrade too fast, is NPM package reliable?

Let’s start with the first three questions: 


  1. Stability: Choose a Node framework that is exception friendly, process waiting packages like Forever/pM2 to help us, and it has matured, and Node is getting better and more stable
  2. Debugging: Ides with front-end processes are now easy to debug
  3. If the background interface communication protocol is too complicated, it can be solved by the Node module of C, isn’t PHP the same?

The latter two problems are mainly related to the company’s operation and maintenance ability:

  1. Work flow: At present, baidu’s internal work flow is very good, from code submission to package compilation and online is a complete set of solutions, and each link only needs to be input and output according to the agreement
  2. Internal ORP operations: baidu is a very good PaaS solution, provides the virtualization of instances, the Node code deployment on instance, through a unified nginx distributed to different port instance handle reverse proxy, elastic support resources scheduling, log only need to put in a folder in accordance with the contract, you can configure the acquisition task, collection and monitoring

Therefore, our factory has already made preparations for large-scale use of Node in terms of process and operation and maintenance.

Finally, let’s talk about the ecosystem of Node. It’s true that the version of Node will be upgraded very quickly, but we will only focus on the LTS version and we will follow up with the update after some time. For framework and business code used by NPM package, can do version specified, can also do automatic testing, run through the case is submitted to master, with the next version of the return online.

What are the problems with front-end writing background code?

Regardless, using Node has become a natural progression, but we need to be aware of our limitations and broaden our horizons.

First is the background thought, in the front-end development, our code is running in each user’s own browser, between the code is isolated, so no matter your code is good or bad, as long as it is said in the past, there will not be a big problem, such as: occasionally memory leak, it seems to have little impact. But server code is permanent, not released when the user walks away, so a small memory leak can cause a big problem over time. Such as: You can occasionally use global variables in browser JS, but if the Node code places user-specific data in global, then the next request will come in and the code will not be able to process the current request, which will cause it to use data other than the current user. You can only pass on layers of personalized data. There is also a lack of awareness or over-optimization, not using caching when it should be used, and misusing it when it shouldn’t.

For another case, look at the following code:

module.exports = function (ip) {
  var ipfinder = require('ipfinder');
  ipfinder.loadData('ip.data');
  return ipfinder.findSync(ip);
}
Copy the code

This is a similar code for the Data Real-time Analysis project, ipfinder is an IP finder library I wrote, ipfinder.loadData(‘ip.data ‘); Module. Exports is loaded every time it executes module. Outside of Module. Exports, the CPU of the application drops from 99% to 5%….

The second is security awareness. The code defects of Proxy. js mentioned in “Vue Project Reconstruction” are caused by the lack of security awareness. Front-end writing background programs, because of the lack of security awareness, often make mistakes in interface design, page fragment splicing and other aspects, such as: the interface design is too simple, lack of verification, easy to lead to CSRF attack, if there is a database operation, manual splicing SQL statements easy to lead to SQL injection.

Finally the operational knowledge, front-end engineer write Node services, not easy to be responsible for the browser, but also should be responsible for the server, the server stability, a variety of monitoring indicators should be to understand somewhat, for computer configuration, resource allocation, operational architecture, service architecture should be familiar to heart, avoid accident his online also don’t know where screening embarrassment.

Sure, you may say that it’s okay to make mistakes in the beginning, but know this: technical adjustments should not harm the product or service. The above three content need to just turn to Node development of front-end engineers pay attention to strengthen learning, the greater the responsibility of the greater the ability! At the beginning, you may make mistakes and make mistakes, but if you ask for advice, you can light up new skill points over time

@Sanshuiqing Please do not reprint without permission.