Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "how to efficiently develop web front-end and back-end collaboration". In the operation process of actual cases, many people will encounter such difficulties. Next, let Xiaobian lead you to learn how to deal with these situations! I hope you can read carefully and learn something!

1. front and rear separation

The separation of front-end and back-end can make front-end development break away from back-end development mode and have greater freedom, so that front-end engineering, component-based, single-page applications, etc. can be done.

2. Try to avoid back-end template rendering

The rendering methods of web applications are divided into server-side rendering and client-side rendering. At present, the recommended method is client-side rendering, and the data is interacted in an all-Ajax manner.

Unless in some cases where server-side rendering has to be used (such as portals, e-commerce, etc.), client-side rendering should be used as much as possible, because client-side rendering can better separate the front and back ends (project separation, code decoupling, collaboration separation, responsibility separation, etc.), and can also better do local interface simulation development to improve development efficiency.

That is, using server-side rendering, under the conditions of technical support, you can use the node middle layer (developed by front-end personnel) instead of traditional back-end template rendering, which can completely decouple the back-end from the front-end, and the back-end and the front-end only have data exchanges.

3. Try to avoid a lot of online debugging

Do a good job of local interface simulation development (including back-end template rendering), avoid a lot of online debugging, because online debugging is very inconvenient, but also very troublesome, and every time you update the code, you need to rebuild, and then synchronize to the server.

So do a good job of local interface simulation development, as long as the program runs locally is no problem, there will be no big problems on the general line, so that the debugging workload can be greatly reduced and the development efficiency can be improved.

4. Local Interface Simulation Development

Local interface emulation is to emulate a server-like environment locally, providing interfaces for data, error emulation, and so on.

The significance of local interface simulation development lies in the ability to complete almost all development and debugging locally, minimize online debugging, and improve development efficiency.

Some common libraries:

browser-sync(https://github.com/BrowserSync/browser-sync): enables browsers to respond quickly to file changes ( html, js, css, sass, less, etc.) in real time and automatically refresh pages, and can be debugged on PC, tablet, mobile phone and other devices at the same time.

webpack-dev-middleware(https://github.com/webpack/webpack-dev-middleware)：A development middleware for webpack。

webpack-hot-middleware

(https://github.com/webpack-contrib/webpack-hot-middleware): Hot-update local development browser service.

In addition, native interface emulation development requires that backend developers have standardized interface documentation.

5. Standard interface documentation

A very important way for front-end and back-end collaboration to improve development efficiency is to reduce communication: if you can form paper documents, don't communicate verbally; if you can write interface documents clearly, don't communicate verbally (parameters, data structures, field meanings, etc.); especially when collaborating online, face-to-face communication is very difficult.

A good interface document should have the following requirements and information:

Simple and clear format: API Blueprint(https://apiblueprint.org/) is recommended

Grouping: When there are many interfaces, grouping is necessary

Interface name, interface description, interface address

http methods, parameters, headers, serialize or not

http status code, response data

Interface documents can be managed by some document services or git; they can be written in markdown, YAML, JSON, etc.

It is recommended to use markdown mode to write documents and git to manage documents.

Reference:

Localization interface simulation, front-end parallel development

API Blueprint(https://apiblueprint.org/)

6. Decaching

The front-end needs to do a good job of caching the client to ensure that users are always using *** resources, and there will be no bugs due to caching problems.

Traditional de-caching is to add a version number or timestamp to a static resource url, but because of the advent of build tools and the fact that some browsers no longer support this method, this method is already in the past.

Now to cache is to hash the file name, as long as the file changes, the file name will be different, in order to completely cache. If webpack is used for packaging, all files are automatically hashed and named.

7. Do a good job of error handling

Both the front-end and the back-end need to do their own error handling, so that errors can be friendly prompts, and users can quickly and accurately locate the source and cause of errors when feedback.

Common front-end errors are divided into:

Script run error: js script error, find stack information, and then resolve

Interface error: server error, incorrect data return, no response data, timeout, etc.

The interface errors are divided into:

Status code error (status code not 2XX): server error, timeout, etc.

Data error: no response data, incorrect data format, incorrect data content

8. Run time capture js script errors

When the user is using the online program, how do you know if there is a bug; if there is a bug, what is wrong with the report; if js reports an error, how do you know which line runs wrong?

Therefore, it is necessary to catch js script errors while the program is running and report them to the server.

Here is how to use_window.onerror:

_window.onerror =(errorMessage,scriptURI, lineNumber,columnNumber, errorObj)=>{ const data ={ title:document . getElementsByTagName ( 'title' )[ 0 ]. innerText , errorMessage , scriptURI , lineNumber , columnNumber , detailMessage : ( errorObj &&errorObj . message ) || '' , stack : (errorObj && errorObj . stack )|| '' , userAgent :window . navigator . userAgent , locationHref : window . location . href , cookie: window . document . cookie , }; post ('url ' , data ); //Report to server };

The js scripts on the line are all compressed. You need to use the sourcemap file and source-map(https://github.com/mozilla/source-map) to view the original error stack information.

9. Mobile Remote Debugging, vConsole, TBS Studio

Because mobile development doesn't use Chrome's developer debugging tools the way PC development does, debugging mobile requires some extra skill.

Mobile applications generally run in WeChat browser, webview, mobile browser.

Remote Debugging

Remote Debugging is to map the web page of one device to another device through USB connection, port forwarding, proxy construction, etc., such as mapping the webview of mobile phone to pc, so as to achieve the purpose of debugging.

Mobile web application debugging problems have existed from the beginning, but later browser manufacturers basically launched their own Remote Debugging tools to solve this problem, including OperaMobile, iOSSafari, ChromeforAndroid, UC browser, etc., in addition to some third-party development of remote debugging tools, such as weinre(http://people.apache.org/~pmuellr/weinre/docs/1.x/1.5.0/) and so on.

Take Android as an example, you can map webview, Chrome for Android pages to ChromeDevTools on the PC side, and then you can debug mobile pages on the PC side.

vConsole

A lightweight, extensible, front-end developer debug panel for mobile web pages (a convenient implementation of chrome developer tools).

This is a convenient debugger embedded in the page, basically able to meet the general needs of Remote Debugging page.

github：https://github.com/Tencent/vConsole

demo：https://wechatfe.github.io/vconsole/demo.html

TBS Studio

Because WeChat browser is a customized browser, general Remote Debugging methods are not available, and specific tools, such as WeChat developer tools, are required.

TBS Studio is another powerful tool that can debug remote WeChat browser pages like Chrome.

10. front-end-post-parallel development

Under normal circumstances, after completing UI or component development, front-end development needs to wait for the backend to provide interface documents before continuing. If front-end parallel development can be achieved, development efficiency can also be improved.

Front-end parallel development, that is to say, front-end development can be carried out without waiting for the backend to provide interface documents, and after the backend provides interfaces, it can basically be launched after docking.

Under the implementation of localization interface simulation, front-end parallel development can be achieved, but Ajax needs to be encapsulated at the code level.

11. friendly communication

No matter how powerful the tool is, it is inevitable to communicate face to face many times. Friendly and calm communication is also very important!

The content of "How to efficiently develop web front-end and back-end collaboration" is introduced here. Thank you for reading. If you want to know more about industry-related knowledge, you can pay attention to the website. Xiaobian will output more high-quality practical articles for everyone!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.