how to tell where app is running: dev vs. deployed

WEB TMS WEB Core
1

How can I tell where the WEB Core app is running so I know which server to connect to?

I do my dev work inside of a VM and the server is running there as well.

But when the app has been deployed, I want to connect to the server in a public place, maybe even to a different port for testing.

In a VCL app, I'd look at something like;

if fileexists( '..\..\myproj.dpr' ) then ...

but it looks like fileexists doesn't exist for WEB Core.

What are some ways of managing that?

#web-core
#deployment

2

A few ideas for you.

First, window.location.hostname will return the browser-supplied hostname from the URL. You can also use window.location.href if you wanted the entire URL for whatever reason. Using this, you could set your parameters like so.

// Running in development environment
if window.location.hostname = 'localhost' then
begin
  ...
end
// Running in production environment
else
begin
 ....
end;

Sometimes it is helpful to know where the application is running, globally. Perhaps you have more than one supporting server (XData for example) and you want to connect to the closest one. Or you have some kind of country-specific restrictions. You can try and get a bunch of this data from an
external source. Getting the local IP is non-trivial, but you can instead use something like this.

There's also the question about what data to supply for the alternate information. My habit of late has been to code the default values to point at the development environment and then supply a configuration.json file of some sort that overrides those to point at the production values. This configuration file is then loaded when the app starts.

For example, the JSON configuration would contain the server and port information for XData. When the app starts, it checks for this file. If it finds it, it uses that for the connection. If the file is not found, then it uses whatever the development environment defaults are. An example of what this might look like code-wise can be found in the Initialization section of this blog post.

The benefit here is that you can adjust the configuration JSON file to point wherever you like. Sometimes you might want the development code to point at a production server, for example, so you can just change the configuration, reload the page, and then be on your way.

1 Like
3

Thanks, I'll add that bit of code at the top for initial detection and see if it helps. What I did in the meantime was set it up to connect to the remote host, which as worked fine since I got the server issues worked out. Then I added a checkbox to switch it to localhost if needed.

(I need to add an SSL cert to the remote host so I can access it vis https. The hosting provider isn't being very helpful. They've got a big list of options you can get help for, and if yours isn't in the list, it's hard to reach them. Not sure why adding an SSL cert isn't there while simple stuff like "how to restart my server" is.)

4

I always call a json config file as very much the first thing I do in a WebCore app. That provides all the info needed, such as the XData server URL, whether the app is local or remote. Also, I always build in debug mode for localhost and release mode for the remote servers, so I can use

{$IFDEF DEBUG}
AppLocation := Local;
{$ELSE}...
AppLocation := Remote;
{$ENDIF}
2 Likes