feat: allow support for a root path

[jordanrfrazier]

Adds support for adding a root_path, so users can execute on a relative path.

[ogabrielluiz]

Thanks, Jordan! Tejas will appreciate this work for sure.

[ogabrielluiz]

I think this is fixed at build time. We have an endpoint that sends config from the backend to the UI at runtime (api/v1/config).

[jordanrfrazier]

Do you mind explaining this a bit more? I was following the pattern I saw in the vite config - https://github.com/langflow-ai/langflow/blob/support-base-path/src/frontend/vite.config.mts#L43.

Do you mean that we should rather access the value from the backend config? If so, wouldn't that require the BE be up before a FE can come up?

[anovazzi1]

I believe that if we always set the env on the backend and pass it through a config endpoint is better than using decentralized env variables.

[ogabrielluiz]

The Backend serves the Frontend. Also, that variable won't be available at runtime. When the frontend is built it will grab that and fix the value to whatever it was at the build time.

[jordanrfrazier]

@ogabrielluiz I talked to @anovazzi1 about this and he believes that this is the correct solution. If we want the frontend to be available at a specific root path, does it not need to be available at build time?

@anovazzi1 can likely explain it better.

[jordanrfrazier]

What this doesn't do is allow a separate root path for the frontend and the backend, but I think that's okay for now

[ogabrielluiz]

I think using useGetConfig to get this puts this PR in a good state. I'd advise adding a Docker compose example on how to use/test this.

[anovazzi1]

Basically putting this on getConfig is not really useful, because this change needs to be done before the frontend builds, that way makes sense reading directly from the env instead of making a request

[ogabrielluiz]

Adds support for adding a root_path, so users can execute on a relative path.

TODO

• Noticed that curls without the root path still work. Unsure why
  e.g.

curl -s http://localhost:7860/custompath/api/v1/all
and 
curl -s http://localhost:7860/api/v1/all

are both served.

Could be related to this: https://fastapi.tiangolo.com/advanced/behind-a-proxy/#about-root_path

Did you use uvicorn (i.e. make backend) or langflow run?

[jordanrfrazier]

Adds support for adding a root_path, so users can execute on a relative path.
TODO

• Noticed that curls without the root path still work. Unsure why
  e.g.

curl -s http://localhost:7860/custompath/api/v1/all
and 
curl -s http://localhost:7860/api/v1/all

are both served.

Could be related to this: https://fastapi.tiangolo.com/advanced/behind-a-proxy/#about-root_path

Did you use uvicorn (i.e. make backend) or langflow run?

Ah, yes, that must be what this is. That seems like intended behavior - do you see any issue in this then? (And I was running with make backend / make frontend)

[anovazzi1]

I believe the root_path variable should be retrieved on the config endpoint:

[ogabrielluiz]

Adds support for adding a root_path, so users can execute on a relative path.
TODO

• Noticed that curls without the root path still work. Unsure why
  e.g.

curl -s http://localhost:7860/custompath/api/v1/all
and 
curl -s http://localhost:7860/api/v1/all

are both served.

Could be related to this: fastapi.tiangolo.com/advanced/behind-a-proxy#about-root_path
Did you use uvicorn (i.e. make backend) or langflow run?

Ah, yes, that must be what this is. That seems like intended behavior - do you see any issue in this then? (And I was running with make backend / make frontend)

langflow run uses Gunicorn instead of Uvicorn. Maybe that can have a different behaviour.

[ogabrielluiz]

I think using useGetConfig to get this puts this PR in a good state. I'd advise adding a Docker compose example on how to use/test this.