Because the system is distributed and has multiple domain names, it often involves getting URLs. This is the system framework level need to provide the ability, otherwise each module needs to find a way to obtain IP, it will be very chaotic, on-line also prone to bug
There are several major issues to be addressed:
1, can automatically distinguish the development environment and production environment. For example, the deployment line, the URL may be Http://www.xxx.com/svc/hello, and in the local development should be http://127.0.0.1/svc/hello. And can't write dead, otherwise development and deployment will change, very troublesome
2, can according to different service, distinguishes the URL. For example, the service that obtains the verification code, should call Http://www.xxx.com/svc/getCode, 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 a corresponding configuration file, which shows that the development mode, or the production mode to start. and leave URLs separated, such as authentication-related URLs, related URLs, General Service-related URLs, 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, if it is started in the development mode, the load is Topo-dev.json, where the configured URL is 127.0.0.1
3, when starting, load this profile, and put the key information under the GLOBAL._G_ENV global variable, the runtime can easily get to the environment and URL information
Server-side Fetch URL
Server code is also running in the node environment, so to get the URL is very simple, 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 as well. However, Static JS has no way to obtain the server environment information and URLs, etc., so need to obtain this information from the service side, a feasible 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 it is a JS script in fact. On the front page, use the script tag to load it
<script src= "/svc/portal/setting" ></script>
So when the browser gets the response, it will be executed as a JS script, and a global variable is placed on the window with the environment information and the URL information
At the same time, the URL contains only 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
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