Analysis of common debugging methods and common problems in web development

first, the basic principles of Web projects

Most Web projects are now developed and deployed independently of the front and back.

The front and back ends are developed independently, and are typically communicated through the Web interface (common restful and websocket) documents on the Frontend and backend. Front-end developers first more business needs and actual prototype UI programming implementation and event design, and through the Web interface for Business data deletion and modification. The backend developer implements the calculation and pruning of business data based on the defined interface documentation, and operates on persisted data (typically stored in a database).

Stand-alone deployment, front-end projects are html5/css/javascript/pictures and other static resources, only the Web server can be deployed to run. The common Web server has Apache and Nginx. Back-end developers only need to publish the interface service to the application server and properly connect to the database. Common Java application servers are Tomcat, jetty, and so on.

In this statement, the front end is not just the HTML page of the PC station, but also the micro-website, applet, app, etc.

Second, the general debugging method

According to the above division of labor, can be clearly encountered in web development problems are divided into: front-end implementation problems, interface call problems, interface implementation problems.

a) front-end implementation issues

The front-end implementation problem refers to the system user interaction exception caused by a business logic error or a program error after the front-end calls the interface or after calling the interface. For the unused front end, there are different debugging tools.

PC stations and micro sites can be debugged using chrome (recommended) or Firefox's developer tools.

Small programs and public numbers can be debugged using the official developer tools.

The app is debugged using a real-computer-linked development environment.

b) Interface call problem

Interface call problem, many for the front-end call interface error or the interface itself is caused by a bug, unable to get the expected return results of the front-end personnel.

In the development environment, you can use the tools described above for debugging. Troubleshooting in a production environment is where PC stations and micro sites can also perform fault analysis via a PC browser. But the public numbers, small programs, and apps need to be analyzed using the tools of the capture kit Charles.

If there is no packet called by the interface, there is a problem with the front-end program;

If there is an error in the request parameter and the request header information of the interface, the front-end calling interface uses the error;

If there is an error in the response parameters and the response header information of the interface, there is a problem with the interface implementation;

If the interface is called correctly, the front-end program has problems with data result processing.

c) Interface implementation issues

Interface implementation issues, many for back-end developers do not return the correct response results according to the correct request parameters. Many are caused by logical errors, data persistence processing errors, and system-level errors.

The line analysis can be traced through breakpoints at development time. The build environment needs to be analyzed by analyzing the system log or the log of the program.

third, the analysis of common problems

In the above major categories of problems, some are particularly prominent, the following detailed analysis.

a) browser compatibility issues

I. Compatibility issues with low-version browsers

Speaking of the low version of the browser, have to accuse IE9 and the following old man. These outdated browsers have been officially abandoned, but there are still a large number of user groups in China. And the "country" size of the browser is also allowed to use these kernels.

For this issue, try to negotiate with the customer, abandon the low version of the browser, when using a low-version browser to visit the site, the prompt is now a high-version browser, and provide.

IE9 and the following exist cross-domain access issues;

IE7 and the following problems exist in AJAX use;

IE7 and below also exist CSS3, JavaScript object missing and so on.

II. compatibility issues with new HTML5 features

Some of the new features of HTML5, such as WEBRTC and WebGL, have compatibility issues even in newer browsers. Response technology is not yet fully standardized, it is important to choose a reliable library.

b) Font Library cross-domain issues

Font cross-domain problem is that HTML pages and CSS files (the introduction of font libraries are configured in CSS) are not caused by the same domain.

The workaround is to modify the configuration of the Web server (Apache or nginx) to allow cross-domain access to the font library file. or all static files are accessed under one domain.

c) interface calls cross-domain issues

I. Common cross-domain issues

Cross-domain issues are particularly prominent because front-end files are deployed independently from the backend interface service. WebSocket interface is better, itself solves the problem of cross-domain access, restful use needs to handle the head information, allow cross-domain access (set the value of Access-control-allow-origin, if it is easy, can be set to *, but in order to prevent the interface is abused, It is recommended to configure specific domain rules).

Ii. pseudo-cross-domain issues

The so-called pseudo-cross-domain, refers to the backend framework has supported cross-domain access, but due to business code exceptions or application server exceptions, the returned response information does not meet the expected results, causing the browser to prompt cross-domain issues.

This problem, it is best to use the Grab Kit tool, analyze the response parameters and response header information is correct. and solve the problem of server or program in time.

Iii. cross-domain issues with low-version browsers

Well, it's also a low-version browser. IE9 and the following browsers, there is a cross-domain problem (itself does not support WebSocket). For this problem, the predecessor used is usually the JSONP way, but Jsonp uses the get way, obviously incompatible with the restful rule. If you use JSONP, you need to make some adjustments to the front and back end.

Just for a few master-level browsers, changing too much code is not worth it. Not a cross-domain? Then let them a domain. Web server (Apache or nginx) in addition to providing web services, there are powerful proxy functions, the other Domain Interface service path proxy to the same domain as the page is not a complex thing.

Analysis of common debugging methods and common problems in web development