Config: Override backend locations on localhost

[janiemi]

Override backend locations (settings.korpBackendURL, settings.downloadCgiScript) to point to localhost locations when the frontend is running on localhost. This makes it possible to use the configuration file without modifications both in production and when testing locally.

A problem with this solution is that the exact localhost backend locations are those used by me (@janiemi): someone else might use different locations. However, I don’t know if someone else currently runs Korp locally, and this was the easiest solution I came up with to make it possible to use the configuration file also locally without modifications.

[janiemi]

@Traubert, @mmatthiesencsc, @aajarven: What do you think: is it ok to specify localhost backend locations in the frontend configuration like this, in particular as they are specific to my own local Korp installation?

[Traubert]

Personally I'd control this in the deployment process, rather than code, with eg. Jinja2 templates in Ansible. We could make an example of this / point you to something in Kielipankki-korp-ansible?

[janiemi]

@Traubert, I suppose that would in general be a better solution, although I don’t know exactly how it would be implemented in this case.

I mostly run Korp locally via webpack-dev-server (yarn dev), which automatically reloads on the browser when the code is changed, and I’d like to keep it working without extra steps. I also don’t know if you can call that a deployment process.

I’d like to be able to use the same code as in production without having to make temporary changes with a risk of accidentally committing to the production code. Maybe we could have for the locations a separate file that wouldn’t be version-controlled, but how would the information in it be read to or otherwise incorporated into config.js?

In any case, I wouldn’t like to make any significant modifications to this Korp version to support this kind of configuration, as it’ll have to be changed in the next version anyway.

[mmatthiesencsc]

Jyrki, I suggest to indeed have locations in a separate file and the production code checks for that file and reads the contents if present. That way I think we get the best of both worlds and are very flexible.

[janiemi]

@mmatthiesencsc, I agree in principle. However, it’s not obvious to me how you would do that in JavaScript, and I wouldn’t like to spend much time in trying to figure that out, so I’d be grateful for an example.

Maybe I’ll try to make do with modifying config.js for local use (and try to avoid committing that change or commit locally only) until we upgrade to a more recent Korp version.

[mmatthiesencsc]

yarn seems to have distinction between dev and prod:

$ cat webpack.dev.js 
const {merge} = require('webpack-merge');
const common = require('./webpack.common.js');


module.exports = merge(common, {
  devServer: {
    host: process.env.KORP_HOST || "localhost",
    port: process.env.KORP_PORT || 9111
  },
  devtool: 'inline-source-map',
  mode: 'development'
});

maybe add webpack.common-dev.js? My yarn knowledge is limited, so ymmv.