Access environment variables in CSR

[kerkmann]

Hi, I have a server side rendered and client side rendered application and I would like to read from std::env::var(...) once booting up. The idea behind that is, that urls aren't hard coded and can be loaded with an environment variable. For example deployment on a production and staging environment. Right now the only proper way to do ist is building two docker container and use the compile time macro std::env!. This isn't ideal, because you need to hardbake the endpoints to the docker container and build it twice. The idea would be to read the std::env::var on booting up and use that to serve it. In #[server] functions it's possible to access the std::env::var, but it's not possible to provide environment variables outside of server functions. Does someone have a good idea how we could access env variables inside the CSR functions?

[gbj]

If you are only using CSR, and serving static HTML/JS/WASM, the only Rust binary that is running for your application is running in the user's browser, and doesn't have access to environment variables (let alone environment variables on your server). Am I misunderstanding something about your situation?

[kerkmann]

Yes, this was maybe a little bit misleading from my side, let me explain it further. ^^"

There is this start-axum which is setting up a axum server with leptos (SSR and hybrid). We are using that for some SSR pages (in our case product pages). The #[server] functions it's fine to use environment variables (for example BACKEND_ENDPOINT). But that would only work from the server functions. We are not loading everything SSR. For example the products are getting fetched from the backend in SSR mode. The Navbar includes our authentication system which is using the CSR/hybrid mode (outside of the route, not in SSR). It's impossible right now to deploy a docker image where we could define our AUTH_ENDPOINT (which is used from the CSR). The only way to solve that problem is to use compile time environment variables and deploy it multiple times.

We tried to use Await with blocking, to first read from the env on backend side and the let the client render the other stuff on the client. But that didn't went well. ^^"

Do you have any ideas how we could deploy something like that easily?

In a react environment it would be possible to but up a node environment, which is then injecting the environment on the specified places. In leptos it's compiled once and then just served. There is no way to boot the SSR, which is on the fly compiling/settings the environment. That's what I meant with "it's only possible with static compiled environments". I hope it's clear now. ^^"

[gbj]

Sorry, it's even less clear to me now...

On the pages you're talking about, are you using CSR (client-side rendering, your code only running in the user's browser) or SSR (rendering HTML on the server)?

You write things like this that are confusing me:

There is no way to boot the SSR, which is on the fly compiling/settings the environment.

What is CSR/hybrid mode? I'm sorry, I just don't understand what you mean in most of this.

Let me ask this: For your CSR-mode pages, what is providing the HTML file that loads the JS/WASM for CSR?

[kerkmann]

Sorry, it's a little bit hard to explain, I am struggling with it, I'll show you code, how the things look like right now. ^^"

We have the following App:

struct AppConfig {
    backend_url: String,
}

#[must_use]
#[component]
pub fn App() -> impl IntoView {
    provide_meta_context();

    expect_context(AppConfig {
        // I would love to have that not statically in the wasm file. I would like to have this dynamically at runtime.
        backend_url: String::from("https://our.backend.api"),
    });

    view! {
            // Here are some routes with `component` and `server` functions.
    }
}

What we would like to do is provide that URL from the environment. In a server function we could write something like this:

#[server]
fn some_backend_call() -> ... {
    let backend_url = std::env::var!("BACKEND_URL").unwrap();
}

But it's impossible to provide something like that for our CSR app, or in the expect_context.

We tried to hack around on that by using the Await.

#[must_use]
#[component]
pub fn App() -> impl IntoView {
    provide_meta_context();

    view! {
    <Await
        future=|| fetch_backend_url()
        let:data
    >
        <p>{*data}
           // Here are some routes with `component` and `server` functions which takes 'data' as argument.
        </p>
    </Await>
    }
}

async fn fetch_backend_url() -> String {
    std::env::var!("BACKEND_URL").unwrap()
}

But the problem with that is, that one is destroying every client side function (#[component]). After that our create_local_resource is broken.

What we would like to have is the backend environment BACKEND_URL accessible to every #[component] and create_local_resource. The reason is to build one docker container, deploy it an multiple runner and just change the environment variable BACKEND_URL for every environment we have.

I hope it's a little bit more clear, sorry for the confusion. ^^"

[gbj]

What is serving the CSR version of your app? Is it capable of adding something like a <script> tag to the HTML file that's loading the JS/WASM? In that case you can just read the env var on the server and add it to the HTML. There are only two ways for the user's browser to have access to an env var on the server:

1. The server includes it in the HTML
2. The client makes a request to the server

You can do either of these.