agera-edc / DataDashboard

Downstream fork of DataDashboard Eclipse-DataspaceConnector Repo
Apache License 2.0
0 stars 1 forks source link

EDC Data Dashboard local setup #17

Closed marcgs closed 2 years ago

marcgs commented 2 years ago

Description

The EDC Data Dashboard has a local development setup that allows to run the application against an MVD backend with npm run start. The application uses the app.config.json file at runtime to configure the MVD backend and API key, but currently the backend is hardcoded to a test backend instance http://ageramvd2-consumer.northeurope.azurecontainer.io:8182. This configuration has only impact on local setups as it gets overriden when deploying the web application to the cloud. Currently the app.config.json needs to be adapted manually on each dev machine with the correct configuration, always remembering not to push it into the repo, which is suboptimal.

A suggestion how to improve this could be to empty the pushed app.config.json file (which will be replaced during deployment time with the correct settings) and extend AppConfigService to fall back to using the corresponding environment files if no configuration is found in the app.config.json file. Sensitive vars like API_KEY must not be commited to the environment files by either:

Acceptance Criteria

paullatzelsperger commented 2 years ago

@marcgs how about using the environment.ts files for this? We could provide the following files out of the box:

we could then use file replacements to switch between the environments at build time, and developers can even add their own environment.

We wouldn't even have to document much, since all this is an standard Angular feature (see official docs).

marcgs commented 2 years ago

@marcgs how about using the environment.ts files for this? We could provide the following files out of the box:

  • environment.ts: default, serves variables for local deployment
  • environment.stage.ts: serves variables for some fixed MVD installation

we could then use file replacements to switch between the environments at build time, and developers can even add their own environment.

We wouldn't even have to document much, since all this is an standard Angular feature (see official docs).

@paullatzelsperger Yes, this is indeed the standard Angular feature to support multiple environments. Normally these files are commited to git though, which I would try to avoid to prevent having a URL of the MVD backend together with the API KEY to access it publicly accessible in the git repository. Perhaps we would add a environment.local.ts that is ignored by git, and that developers have to setup manually.

The mechanism to load config in AppConfigService would need to fallback to environment.local.ts if no info is present in the app.config.json file.

paullatzelsperger commented 2 years ago

@marcgs we can commit the files, but leave out the API key and use a placeholder? I wouldn't regard API Urls and storage account names as sensitive information.

marcgs commented 2 years ago

@paullatzelsperger How would be the placeholder replaced? I would try to avoid having to modify the files in source control, it is very easy to commit changes by error. Ideally we should find a solution similar to .env files that contain sensitive that gets picked up when running locally but are not pushed into the repo.

paullatzelsperger commented 2 years ago

would it hurt to commit a environment.local.ts that contains:

{
  "apiKey": "x-edc-showcase-x",
  "catalogUrl": "http://localhost:8181/api/federatedcatalog",
  "dataManagementApiUrl": "http://localhost:8182/api/v1/data",
  "storageAccount": "edcshowcasegpstorage"
}

As to the suggestion with .env: just found this which uses dotenv. We could then just read sensitive information from the .env file

marcgs commented 2 years ago

would it hurt to commit a environment.local.ts that contains:

{
  "apiKey": "x-edc-showcase-x",
  "catalogUrl": "http://localhost:8181/api/federatedcatalog",
  "dataManagementApiUrl": "http://localhost:8182/api/v1/data",
  "storageAccount": "edcshowcasegpstorage"
}

As to the suggestion with .env: just found this which uses dotenv. We could then just read sensitive information from the .env file

Something along these lines would be perfect. I will update the story accordingly

paullatzelsperger commented 2 years ago

after some discussions, and after reviewing a few options, it was decided that the best and simplest way is to just have one app.config.json, which is in the git index, and every developer should run git update-index --assume-unchanged src/assets/config/app.config.json to avoid committing unwanted changes.