In recent years, the separation of front-end and back-end has become the best practice in the development of medium and large software projects.
At the technical level, front-end and back-end separation means that in the same Web system, the front-end server and the back-end server use different technology stacks and use standard Web API to complete collaborative work. In this "mixed development" mode where the front and back ends are separated, the front and back ends are usually deployed on different servers, even if they are deployed on the same machine, because the host programs (such as Tomcat for the back end and nginx for the front end) are different, and the port numbers are also different. It is difficult to unify.
(picture source network)
This means that a page located in domain A (such as https://foo:80/website ) needs to call the WebAPI of domain B (such as https://bar:8080/webservice ), which is a typical cross-domain access, browsing By default, the browser will determine that this operation is a security risk. If no processing is performed, the WebAPI call will be rejected and a corresponding error will be prompted.
(Error caused by cross-domain request)
How to solve the cross-domain problem now? There are currently 4 mainstream technical solutions:
JSONP
If you only need to handle GET requests, consider JSONP.
The principle of JSONP is to take advantage of the fact that the \<script\> tag has no cross-domain restrictions, and send a GET request with a callback parameter through the \<script\> tag src attribute, and the server will piece together the data returned by the interface into the callback In the function, it is returned to the browser, and the browser parses and executes, so that the front end gets the data returned by the callback function.
(JSONP calling process)
This approach is common, but you need to provide a JSONP response for the front end, and other terminal calls provide a response without JSONP, so it will bring additional development and testing workload.
iFrame
Usually, the cross-domain access brought by the separation of front-end and back-end is limited to different subdomains of the same main domain (such as a.foo.com and b.foo.com). So, you can use an iFrame to load a page located in the domain where the called WebAPI is located, and then set the document.domain of the two pages to the main domain name (such as foo.com), and then request the WebAPI through the subpage in the iFrame.
(picture source network)
This approach is rather troublesome. We need to develop a page that acts as a relay for WebAPI, but it still has a lot of development workload for developers.
CORS
Compared with the first two schemes, CORS (Cross-Origin Resource Sharing) is a "once and for all" scheme.
We do not need to do additional processing for each WebAPI, but need to add some processing work when the backend program starts. The mainstream back-end services all have class libraries for handling CORS, so I won't introduce them here.
The core principle of this scheme is to send an HTTP request with an OPTIONS verb before initiating a formal request, asking whether the page that initiates the request has the authority to call the domain service; if the backend says OK, the browser continues the request, otherwise prompt error.
The development workload using this solution is small, and if the mature class library is used directly, the development and testing workload can even be ignored. However, because each cross-domain request will trigger an outgoing OPTIONS request, it will cause additional overhead and pressure on the server.
reverse proxy
The reverse proxy mechanism combines the front-end A domain and the back-end B domain into a C domain, which fundamentally solves the cross-domain problem.
This solution only needs to be configured, and there is no intrusion on the front-end and back-end programs; at the same time, the reverse proxy in the intranet usually does not bring additional performance overhead.
(picture source network)
Generally speaking, in the era of coding development, the above four schemes have applicable application scenarios, each with its own advantages and disadvantages. After entering the era of low-code development, the front-end and back-end separated applications are more widely used, such as using JavaScript coding to develop front-end, back-end built with low-code, or using Java to develop back-end for front-end calls built with low-code.
(Separation of front-end and back-end in the low-code era, from the low-code salon)
The core value of low-code development is to save development investment and improve development efficiency. Therefore, scheme 1 (JSONP) and scheme 2 (iFrame) have rarely been used in the field of low-code hybrid development. Compared with scheme 3 (CORS), scheme 4 (reverse proxy) has more application scenarios because of its lower performance overhead.
Next, we will take movable type + nginx as an example to introduce the specific method of using nginx to solve cross-domain problems and realize the separation of front and back ends.
(schematic diagram of reverse proxy)
Use nginx to solve cross-domain problems
- Before starting the configuration, we use movable type to develop two applications, the frontend that only contains the front-end page and the backend that contains the back-end WebAPI (server command), and publish them to the physical machine or cloud host respectively. The port of the application is set to 8081 and 8080. We can access both apps at the following addresses:
- Backend: http://host\_name:8080/backend
- Frontend: http://host\_name\_2:8081/frontend
- Install nginx, and configure the front-end and back-end servers on the HTTP node in the configuration file /conf/nginx.conf, that is, the upstream node:
upstream backend {
server host\_name:8080;
}
upstream frontend {
server host\_name\_2:8081;
}
- On the server node under the HTTP node, configure the listening port and forwarding strategy, so that http://host \_name:8080/backend can be mapped to http://proxy \_name:8000/backend , http://host \ _name\_2:8081/frontend maps to http://proxy\_name:8000/frontend
listen 8000;
server\_name proxy\_name;
location /frontend {
proxy\_pass http://frontend/frontend ;
}
location /backend {
proxy\_pass http://backend/backend ;
}
- After the above operations, the domain name accessed by the user is unified to http://proxy\_name:8000 , and the cross-domain problem is solved. But don't worry. The movable type will enable the Http Referer authentication mechanism by default, and does not allow cross-domain calls to built-in services. Therefore, you also need to open the management console of the server where the front-end application is located http://host\_name\_2:22345/UserService/ManagementPage/WebSecurity
Add the address of the nginx proxy server in the HTTP Referrer allow list (that is, the address actually used by the user, remember to add a * to adapt).
- After the configuration is complete, you can call the back-end WebAPI through [Send HTTP Request Command] on the front-end page.
(Call the back-end WebAPI on the front-end and display the returned result in a pop-up window)
Special Note: If you need to deploy the frontend, backend and nginx on the same machine, you can uniformly replace the above proxy\_name, host\_name, host\_name\_2 with your machine name or IP address.
As a powerful reverse proxy and web server, nginx has a wide range of uses. This article only uses its reverse proxy function. In addition, nginx also has excellent performance for load balancing solutions. We will give you a more in-depth introduction in the follow-up content.
If you want to learn more about how to use low-code to develop enterprise-level applications with separate front and back ends, and quickly transform into full-stack engineers, you can check:
In addition, if you are interested in more low-code industry status and development trends, you can check:
https://help.grapecity.com.cn/pages/viewpage.action?pageId=67969931
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。