Get rid of OPLA_BACKEND_DOMAIN

[licarth]

What is the purpose of this env variable / config entry in default.json ?

It apparently tells the frontend where our backend api sits. From experience, this leads to hell in deployments configurations, etc.

Alternative : just use the relative api/ in frontends. We will take care of routing that properly.

[mikbry]

But if the backend is on another machine ?

[licarth]

So, I tend to agree with you, but : The underlying problem is that we currently use OPLA_BACKEND_DOMAIN for 2 things

1. to register the app against the backend through opla init on a private network (not open to the public, otherwise anybody can register theirs).
2. to tell the frontend where the public api sits.

2 things about that :

1. They are not necessarily the same. A web client will need, let's say api.opla.ai to operate their bots (public but secure). But in order to configure the application (privately, from backend to backend), we will probably use different dns, or IPs).
2. If we split this into 2 env variables, which I thought about doing (e.g. OPLA_API_DOMAIN and OPLA_BACKEND_HOST), then, we will need to inject different values of OPLA_API_DOMAIN, one per environment for instance, and if we go for prefixes per customer, for instance, then we will have a lot of those. Why should we do that when we can just tell the frontend :"whichever domain there is in the address bar, there will be an API on the api/ relative path."

It doesn't have to be on the same machine, we can do reverse proxying with nginx (that we already do), or use ingress in Kubernetes to point api/* to the right services.

Also, having api.opla.ai and front.opla.ai means 2 certificates, more complexity. I don't see the advantages of having 2 domains.

WDYT

[mikbry]

Ok I see your point of view. Let's see how long it could take and work on it later.

[mikbry]

done?

[licarth]

Closing, irrelevant now.