Inconsistent Configuration Fetching for SciCat Frontend

[Ingvord]

Issue Name

Inconsistent Configuration Fetching for SciCat Frontend

Summary

Currently, there is an inconsistency in how the SciCat frontend fetches its configuration. The frontend supports fetching configuration both locally (from a static file) and remotely (from the backend), leading to unnecessary complexity and potential confusion.

Steps to Reproduce

2. Start the SciCat frontend application.
3. Observe how the configuration is fetched: First, it attempts to fetch configuration from the backend at /backend/api/v3/admin/config.
   If the backend configuration is unavailable, it falls back to fetching local configuration from /scicat/assets/config.json.
4. Analyze the code behavior and handling in case of errors or missing configurations.

Current Behaviour

The frontend uses a nested try-catch structure to manage configuration fetching, which is an anti-pattern for flow control.

This approach introduces confusion and tightly couples frontend behavior to backend configuration, violating separation of concerns.

try {  
  const config = await this.http  
    .get("/backend/api/v3/admin/config")  
    .pipe(timeout(2000))  
    .toPromise();  
  this.appConfig = Object.assign({}, this.appConfig, config);  
} catch (err) {  
  console.log("No config available in backend, trying with local config.");  
  try {  
    const config = await this.http.get("/scicat/assets/config.json").toPromise();  
    this.appConfig = Object.assign({}, this.appConfig, config);  
  } catch (err) {  
    console.error("No config provided.");  
  }  
}  

Expected Behaviour

The backend should not be responsible for providing frontend configurations.

The frontend configuration should be purely local to the frontend to avoid unnecessary dependencies.

Error handling should avoid the use of try-catch for flow control and instead use a cleaner and more modular approach.

Extra Details

Refactor the configuration fetching logic to remove the backend dependency for frontend configuration.

Ensure error handling is clean and adheres to best practices.

If remote configuration is unavoidable, establish a clear distinction between backend and frontend configuration responsibilities.

[bpedersen2]

This has been done in this way on purpose:

For a production deployment everything is served on one hostname,
and the FE can fetch its config from the corresponding backend. You can then use one frontend-deployment to serve different backends on different hostnames.

The FE-local version is only suitable for dev setups without a proxy included, as there is no way to find where the backend should be. Maybe we should skip this option and just require dev setups with proxy.

[Ingvord]

Thank you for your clarification! I can see the intent behind the current design, but I believe rethinking deployment strategies can provide a more modular and maintainable solution.

For a production deployment everything is served on one hostname,
and the FE can fetch its config from the corresponding backend. You can then use one frontend-deployment to serve different backends on different hostnames.

From this I take you actually need multiple customized FEs. Because this implies that different BE provide different FE config... This will be achieved much better with localized configs, especially if we talk K8s i.e. ConfigMaps. So there will be one BE deployment and multiple FE. This will also reduce coupling between two.

The FE-local version is only suitable for dev setups without a proxy included, as there is no way to find where the backend should be. Maybe we should skip this option and just require dev setups with proxy.

Not necessarily, I have dev setup with proxy and still there is no benefit in keeping FE config on the BE. In fact I completely got rid off it, by removing corresponding code lines.

[nitrosx]

A while back, the community discussed the issue and decided to serve the FE config from a BE endpoint.
We at ESS like this solution as we have only one place where to update configurations for SciCat. Also if in the future, we decide to provide an admin interface that allows configuration on the fly, we will need to move configuration to the database and, to avoid setting up a separate service, a BE dedicated endpoint for the FE configuration does the job.

That said, I see your point to decouple FE and BE and, I agree with you, that the code can improve.

I propose the following solution which should allow all use cases:
create a run time configuration option that dictate how to load the configuration.
Possible options:

• local. The configuration should be provided locally with app. No call to an external URL. The official FE release comes with the default one. You can customized it but it will require a rebuild of the app.
• remote. The configuration is fetched from an arbitrary URL provided in configuration. It can be the current BE URL or another one that is compatible and more suitable with the local infrastructure where SciCat is installed. If the instance admin decides to use the BE endpoint (which I would like to rename it), the functionalities stays as they are. Fall back will use the local FE config shipped with the FE.

Thoughts? Also would you like to work on such feature?

[Ingvord]

H-hm, an interesting case, indeed.

How will you force the clients to fetch the new configuration once it's changed?

What if the configuration scheme has to be updated with some incompatible changes?