Make writing a habit together! This is the fourth day of my participation in the “Gold Digging Day New Plan · April More text Challenge”. Click here for more details.

I. Recommended Scheme (dry goods)

We know that the front-end has cross-domain problems when sending requests to the back-end interface due to the same origin policy of the browser. There are several solutions available on the web, but here are two of the most popular solutions in development. No more talking and get straight to the work.

Recommended scheme:

What Is CORS?

CORS stands for Cross Origin Resource Sharing. This solution is not much work on the front end, no different from normal Ajax sending request writing, and it is mostly work on the back end (there is no work, just configuring some HTTP protocol).

Here is not a detailed explanation of the principle of CORS, I recommend two good articles hope to help understand it:

• MDN Cross-domain resource sharing
• Ruan Yifeng network log cross-domain resource sharing CORS details

Server proxy

There may be some backend developers who don’t want to configure CORS, but there is a solution for the pure front end.

In development mode, the proxy function of the development server can be used, such as vite-server.proxy of Vite.

However, this method is not available in a production environment. Production servers (such as Nginx, Apache, and so on) need to be configured in the production environment for reverse proxy. However, the principle of configuring proxies on both local and production services is the same, circumventing cross-domain problems by setting up a relay server to forward requests.

A quick illustration of the picture above will help you understand. Since the browser page directly to request service interface has the same origin policy limit, so we can think of a way: the browser page request local development server (server), development/production server to request again real interface service, so don’t bypass the browser same-origin policy limit? In other words, the development/production server is essentially a staging post, sending the data that the real interface responds to back to the client.

This can be done because the same origin policy is browser-specific and there are no cross-domain restrictions on requests from server to server.

Configure the server proxy in the Vite project

Let’s take the configuration of a VUE project created by Vite as an example. The initial project structure is as follows:

We’ll create request.js in the SRC /utils directory to send the Ajax request

Then we in the App. Introduce the request vue. Js and write a simple example of send the request to the http://localhost:4567/api/userInfo (note at this time has not yet been in vite. Config. Agent) that is configured in the js

Simply write a back-end service with Express and run Nodemon app.js to enable the service on port 4567

NPM run dev = NPM run dev = NPM run dev = NPM run dev

Reason is that there is no configuration agent before, the browser default is to develop server that is http://localhost:3000/api/userInfo sends the request, but there is no this interface development server, the real interface is on localhost: 4567, So you need to configure the proxy service in the vite.config.js file:

So when a browser sends a request, starting with/API will development server to the target (target address) to forward the request, and request address joining together for http://localhost:4567/api/userInfo, so you can normally receive real interface service request is sent back to:

Five, matters needing attention

The code part of this article is just a simple demonstration of proxy forwarding on the development server, but if the project to go online still need to configure the production server proxy, such as Nginx do reverse proxy, there is a need to learn can Google.