Because the system is distributed deployment. And there are multiple domain names, so it often involves getting URLs.
This is a system-wide capability that needs to be provided at the framework level. Otherwise, every module needs to find its own way to obtain the IP, it will be very chaotic. On-line also easy to happen bug
There are several issues that need to be addressed:
1, you can proactively differentiate the development environment and production environment. For example, deploy on-line. The URL may be Http://www.xxx.com/svc/hello, and it should be http://127.0.0.1/svc/hello at the time of local development. and cannot write to die, otherwise development and deployment will change to change. Very troublesome
2, can be based on different services. Differentiate URLs. For example, a service that obtains a verification code. Http://www.xxx.com/svc/getCode should be called. And the related service, should call Http://wx.xxx.com/svc/xxx
This article summarizes the idea of sharing:
Configuration file
1, the application has the corresponding configuration file, which shows that the development mode, or the production mode to start. and leave the URL separated, such as the authentication-related URL, the relevant URL, the General Service-related URL, etc.
2, at the same time, the configuration file has many copies, for example Topo-dev.json. Topo-production.json,topo-image.json and so on. This separates the different environments, assuming that it is started in development mode and loaded with Topo-dev.json, where the configured URLs are 127.0.0.1
3. When starting, load this configuration file and place the key information below the GLOBAL._G_ENV global variable. The environment and URL information can be easily obtained at execution time.
Server-side Fetch URL
The code for the server is also running in the node environment. So to get the URL is very easy, through the _g_env.url, you can get the path in the configuration file
Front page Get URL
Front-end pages often also need to send AJAX requests. So you need to know the URL. However, Static JS has no way to get the server environment information and URLs. Therefore, it is necessary to obtain this information from the service side, one possible approach is:
First, the service side has a service, specifically to send this information:
function Clientsettingscript (req, res, next) { var script = "Window.global = {_g_server:{}}; \ n "+ "; global[\ "_g_server\"].staticurl=\ "" +global["_g_topo"].clientaccess.staticurl + "\" \ n "+" ; global[\ "_g_server\"].uploadurl=\ "+global[" _g_topo "].clientaccess.uploadurl +" \ "\ n" + "; global[\" _g_server\ "]. Authurl=\ "" +global["_g_topo"].clientaccess.authurl + "\" \ n "+" global[\ " _g_server\"].serviceurl=\ "" +global[" _g_topo "].clientaccess.serviceurl +" \ "\ n" + "; global[\" _g_server\ "].wxserviceurl=\" "+global[" _g_topo "]. Clientaccess.wxserviceurl + "\" \ n "+ "; global[\ "_g_server\"].nail_pc_url=\ "" +global["_g_topo"].connector.nail _pc_url + "\" \ n "+ "; global[\ "_g_env\"] =\ "" +global["_g_topo"].env+ "\"; \ n "; Res.end (script);}
This is an express General Service, but in fact it is a JS script. On the front page, load it with a script tag
<script src= "/svc/portal/setting" ></script>
So when the browser gets the response, it will run as a JS script. A global variable is placed on the window, with environmental information and URL information
At the same time, the URL only includes the domain name, the page according to the actual situation, assemble the complete URL, for example:
security_code_url:global["_g_server"].serviceurl + "/getcode/"
Summarize
The key to this approach is:
1, the URL and environment information in a separate configuration file, rather than write dead in the code. Isolate different profiles based on the development environment, production environment, and mirroring environment at the same time
2, server dedicated to write a service, these configuration information to the client page, the client page does not have to write dead
Multi-domain environment, a scheme for page fetching URL