WebPrefix does not update API_URL

[openflagr]

WebPrefix does not update API_URL

[zhouzhuojie]

@lawrenceong How about #234?

[zhouzhuojie]

FLAGR_WEB_PREFIX is for the UI prefix route only, we currently don't have a configurable API prefix route. PRs are welcome to add it.

[lawrenceong]

Thanks @zhouzhuojie for the quick reply! We are using the following in nginx as a temporary workaround:

    set $flagr "http://flagr:18000";
    location /flagr {
        proxy_pass $flagr;
    }
    location /api/v1/flags {
        proxy_pass $flagr;
    }
    location /api/v1/evaluation {
        proxy_pass $flagr;
    }

Yes, I understand this does not include every possible endpoints, eg. /api/v1/health.

Will take a look at providing a PR when able.

[lawrenceong]

@zhouzhuojie regarding a PR to allow the API URL to have a prefix.

I believe the parameter FLAGR_WEB_PREFIX should change the API prefix as well. From what I understand, webpack pre-generate the js file that contains the parameter API_URL. This means the only way we can change API_URL is to use relative pathing as how you have done in #223 with the static assets.

If we make API_URL relative, it will immediately start going to /webprefix/api/v1/*. To me, this means the API path should just be updated to make use of FLAGR_WEB_PREFIX. What do you think?

[zhouzhuojie]

That is a breaking change. For example, people may have API runing at /api/v1 and web UI running at /ui, and then the change of reusing FLAGR_WEB_PREFIX for API will break their client SDK calls.

How about not setting FLAGR_WEB_PREFIX, and just proxy via nginx or any api-gateway with url strip (e.g. rewrite or proxy_pass), for example

example.com/webprefix/ => flagr.localhost:18000/, and you can get exactly what you want.

[lawrenceong]

example.com/webprefix/ => flagr.localhost:18000/, and you can get exactly what you want.

@zhouzhuojie That does not actually work because the reverse proxy mechanism will only modify the headers. It does not touch the body which is where API_URL is located (redirecting to a hardcoded /api/v1/*).

This is why I have to revert to the above method to make it work in Nginx. ie. 3 different paths. This is regardless of whether we use FLAGR_WEB_PREFIX or not.

[zhouzhuojie]

I see. We can make API_URL in the vue app as an environment variable when it's built, and then in Dockerfile, we pass that as a build arg. The downside is that you will have to build the docker image yourself.

[lawrenceong]

Yup, I took a look at that solution too, but it's not elegant due to the need to rebuild. Basically looking for a solution where we do not have to rebuild the docker image.

Is it bad to have FLAGR_WEB_PREFIX move API path as well? I understand that it can be a breaking change if someone sets FLAGR_WEB_PREFIX and wants the API to remain at /api/v1. What is the chance that someone needs this?

Based on #223 (that was fixed less than 6 days ago), it looks like FLAGR_WEB_PREFIX may not be in use extensively yet. Would you be willing to accept this breaking change and move API based on FLAGR_WEB_PREFIX as well? This would allow us to map the entire app to a different path using a reverse proxy easily.

[zhouzhuojie]

Yup, agreed, FLAGR_WEB_PREFIX was broken before #223

@SebastianOsuna, since you implemented #170, are you ok with using FLAGR_WEB_PREFIX to prefix both API and UI?

[SebastianOsuna]

I agree it's a better solution!

[lawrenceong]

So, I've been taking a look at submitting a PR for this and it looks like it's not all that simple. We generate the API using go-swagger and what's being generated does not allow us to overwrite the basePath. It looks like OpenAPI v3 allows us to override basePath, but that would mean an upgrade from v2 to v3 and go-swagger itself does not support v3.

• For the frontend, we can just change /api/v1 to api/v2 without the leading /
• For the backend, switch to another library to generate the API from swagger config?

[lawrenceong]

@zhouzhuojie Looks good to me. Thank you.