Basic introduction
Let’s start with an important concept “template”. Broadly speaking, a template in the web is a page that can generate a file after filling in data. Strictly speaking, the template engine should use files in a specific format and the data provided to compile and generate pages. Templates are roughly divided into front-end templates (such as ejs) and back-end templates (such as freemarker) compiled on the browser and server side respectively.
Since some students on the spot didn’t know much about node.js, here are some of the relevant knowledge of node.js. I won’t talk about the definitions of event-driven, asynchronous and so on the official website. Here I borrow a picture from Pu Lingshu to explain the structure of node.js. If you understand Java, you can understand it as a js version of jvm. Browsers generally include renderers and js script engines. Taking the chrome browser as an example, they use the webkit kernel renderer and V8 script engine, while node.js uses the v8 engine. In short, it is a js running environment, just like the browser's F12 debugging tool, but node.js does not have DOM and BOM.
This picture describes some information around node.js, such as npm, the excellent package manager, cnode community, and github, which have promoted the prosperity of node.js to a certain extent and provided technical guarantees.
Large companies are usually the weather vane of technology. For example, Google's angular and Facebook's react are very popular now. Only 3 large companies are listed here as examples. Needless to say, Taobao’s Midway architecture is, Pu Ling, the pioneer of domestic node.js, comes from Taobao. Qunar has also developed a technical framework that should be called "QTX". The 75 team led by Yueying launched a web server framework based on ES6/ES7 - thinkjs. At that time, our technical director was very optimistic, but because I didn’t have time to learn ES6 and the plug-ins were not rich enough, I still chose a more mature Express.
Back to the topic, this table lists three development methods for separation of front and back ends that I have been exposed to. The first is the most common backend language templates that use Java, which are SEO-friendly, and are better at cache utilization and reducing the browser rendering burden. The biggest problem is that the coupling degree of template files is too high. No one wants to solve the problem. Front-end personnel cannot see the data, back-end personnel do not understand the page, and template files are like a hot potato. The second is the current implementation solution of our project's mobile terminal, which uses the framework of angular (angular instructions can be regarded as front-end templates) and the reverse proxy server of nginx to completely decouple the front-end and back-end, and only interact with data through ajax. This solution is exactly the opposite of the advantages and disadvantages of the former. The performance of front-end templates is always a problem, especially on mobile devices, and more particularly on low-end mobile devices. The last one is the new project that uses node.js as a front-end server, which divides the front-end responsibilities from the browser to the template level, solving all the above problems, but there are indeed new problems, and this problem will be analyzed later.
Of course, full-stack development is also very suitable for small projects. For traditional jsp/php development, the communication cost of full-stack development is lower, and developers can more easily understand the entire functional module, thereby better restoring the product design. Especially the full-stack development based on the js language: meteor and MEAN technology that are now emerging makes front-end and back-end development directly handled in one language. With Mongodb, the data from the browser to the database is directly used without escaping, and there is no need to write SQL, which greatly reduces the development cost.
Some plugins used to build the node.js server this time. There is no need to introduce the famous express, the lightweight web server framework. It is also a coincidence to use the handlebars template engine, because express4 is it by default. handlebars is worthy of being the template engine of "weak logic". It advocates reducing template logic and trying to use only variables and paging. Based on its design concept, I have only expanded two helpers. Specific article: https://yalishizhude.github.io/2016/01/22/handlebars/superagent is still used because of express4. Because its test code uses supertest, supertest is based on superagent, so superagent is used to forward and initiate requests. Superagent is still too weak and can't be established for long connections. I still recommend the request plugin. There is nothing to introduce to restfuleAPI. The front-end server and browser, front-end server and back-end server all use this set of specifications. Basically, the URL points to resources, adds, deletes, modify and checks, and the specific request method is expressed, status codes represent results, etc. ~ Gulp packaging tool, webpack has been studying for a long time, and found that every page added requires modification of the configuration file. This is too painful, so I gave up.
Development Process
If this sharing mainly talks about how to use node.js as a front-end server to achieve front-end separation, then there is nothing to say, just look at the article on Taobao UED. The biggest problem with the separation of front and back ends is that it brings up communication costs, specifically the definition and debugging of interfaces. In the traditional development process in the figure above, the definition of the interface will be placed in the interface server, and then the front and back ends will conduct local debugging based on the interface document fraud data, and then conduct joint debugging. This link is when the front and back ends start to fight. This parameter is wrong and the return value is wrong. In short, it is a waste of time. Next, let’s see how this problem is solved in our project ~
The problem of interface fraying in the front and back ends has always existed. As a conservative, I believe in iterative development, so the first step is to add a mock server. The magic of this server is that it automatically generates fake data based on the interface document, implementing the interface, namely the API, and front-end students no longer have to write the data to death for testing. There is no way, who said I am a front-end developer? First of all, I think of my own people. Hehe~ Of course, this is only beneficial to front-end development to a certain extent. There will also be problems when the interfaces and documents of the back-end are inconsistent and are connected. what to do?
I accidentally saw an article by Lao Ma on the blog of the Blade Master, which specifically talks about the separation of front and back ends. One of the important concepts is contract testing, also called bilateral testing. The core concept is to solve the problem of remote joint debugging. Verify the parameters of the front and back ends and require everyone to develop according to the interface document. Inspired by it, the json-schema rule was added to realize the parameter verification of http requests, and whoever does not follow the rules will change it.
This redmine is our earliest interface document manager and has no other function except recording and viewing functions.
Swagger is known as the most popular interface document server in the world. It has a beautiful interface and many plug-ins. It can directly generate test code for back-end languages. However, I never understood it when deploying it, and the yaml format is not as good as JSON, so I gave up on it.
This is the document server and mock server used in our project, the server implemented based on MEAN technology, and the basic functions:
Using the mockjs plug-in, random data can be generated dynamically to perform checksum interface tests on interface parameters based on json-schema, and the test status and interface response time can be saved. The simple json editor has login verification function, and the interface debugging can be performed after logging in. The mock server responds to the request according to the API server, and it will be updated automatically when the interface is updated.
Some questions
node.js is the wings of front-end engineers, and should I become an angel or a demon with wings? This depends on whether the problems caused by using it can be solved.
First of all, the workload on the front end will undoubtedly increase, but the communication cost will be reduced. The server stability of node.js single thread is indeed not good enough, but the robustness of the code and the perfect log can be effectively avoided. Callback. There are too many solutions to this problem, including node.js' q/async module and ES6/ES7. node.js debugging. Although I have always rejected IDE, I have to admit that webstorm is indeed very convenient for debugging. The node-inspector I use is also quite good, the interface is similar to the chrome developer tool, and it looks quite familiar.
If you are a backend programmer, you should be more likely to be accommodating node.js. The work of interface integration is handed over to the front-end server for processing, and the coupling degree with the front-end is greatly reduced, and the workload and work efficiency are reduced.
There are two points to experience
Although the use of node.js has a certain learning cost, it is still very friendly to front-end developers. Moreover, if node.js is used in the front end, both the technical content and the workload will be improved, thus enhancing the importance of the job. Only when current developers can create more value are eligible to demand higher salaries. It is recommended to make less suggestions and give more feasibility plans at work, and conduct technical pre-research instead of writing a simple helloworld.
Summarize
Some people may say that the set of things you introduced is so complicated and it is too troublesome to use, so it is better to communicate face to face. For such doubts, I can only use an example mentioned by Tencent senior UI engineer Yu Guo in "Self-Cultivation of Web Full Stack Engineers". Once, when the front-end person in charge of a small company in Telephone asked him how to manage the code, the other party said that he would use ftp to upload it directly, and complained that his subordinates always updated the wrong code. He also asked him why he didn't use svn or git. He said that it would be easier to update manually. The truth of this story is my answer to the question~
ppt download address