Right now, frontend is using "hardcoded hosts" where both the scientific REST and graphQL services, as well as the links to the legacy instances, are predetermined by external variables. As we are going to have an ever growing number of deployments (test-oeb1 , preprod, etc...), this can increase the number of custom setups.
With this issue I'm proposing you to change the internal logic, so some of the defaults depend on the document.location when the right conditions are met. For instance, if the frontend is reached through https://test-oeb2.openebench.bsc.es , the scientific API should be at https://test-oeb2.openebench.bsc.es/api/scientific , and if the same frontend is reached through https://blah.openebench.bsc.es , it automatically detects that in runtime and the used prefix would be https://blah.openebench.bsc.es/api/scientific .
But, my proposal is that this new logic should only happen when the hostname ends with openebench.bsc.es.
What do you think about this?
Right now, frontend is using "hardcoded hosts" where both the scientific REST and graphQL services, as well as the links to the legacy instances, are predetermined by external variables. As we are going to have an ever growing number of deployments (test-oeb1 , preprod, etc...), this can increase the number of custom setups.
With this issue I'm proposing you to change the internal logic, so some of the defaults depend on the document.location when the right conditions are met. For instance, if the frontend is reached through https://test-oeb2.openebench.bsc.es , the scientific API should be at https://test-oeb2.openebench.bsc.es/api/scientific , and if the same frontend is reached through https://blah.openebench.bsc.es , it automatically detects that in runtime and the used prefix would be https://blah.openebench.bsc.es/api/scientific .
But, my proposal is that this new logic should only happen when the hostname ends with
openebench.bsc.es.What do you think about this?