SSR-only server functions?

[caligin]

Hi! I've been trying to put together an app which mainly renders HTML server side with SSR, with axum in an AWS lambda.
In my design I end up with some #[component]s that would call #[server] fns as part of their initialisation during SSR.
I plan for most of my components to only be rendered on the server (ideally in the default out-of-order streaming mode), and never need to call the same server fn from their hydrated client-side counterpart.

I understand though that all server fns get exposed as API endpoints - which also has the downside of extending the potential security attack surface of my application and requiring extra work to authenticate or protect in some other way.
While for sure this can be an ok tradeoff in most cases were you want in fact to interact with this endpoints, this is really not my case as I'd like these functions to not be exposed as APIs at all (also: I am aware that the random number at the end of an endpoint would make it very hard to find these endpoints and exploitation unlikely - but I'd still like to have more certainty).

Is this possible in any way? Perhaps not with the #[server] macro but with some other combination of #[cfg(feature = "ssr")] and something else? I couldn't quite figure it out.

Many thanks 🙏

[gbj]

Maybe I'm confused but a server function that can't be called from the client is just a function.

Is the question "How do I mark a function so it's not compiled for the browser because it has dependencies that can't be compiled to WASM?"

[caligin]

haha yes, good point - the way you rephrased makes more sense, although I'd all a bit at the end: "...and I get to call that function from inside a #[component] without incurring in compilation issues?"

[gbj]

Yes just #[cfg(feature = "ssr")] I would think.

[caligin]

I tried to put together an example to better illustrate what I have in mind, in particular these lines https://github.com/caligin/leptos-playground/blob/acc44fd92a5d8fbc6a3391032fafe6f6189e2261/entirely-ssr-fns/src/app.rs#L59-L120 .

the component in the example is a form that should display in fields some initial data if it exists stored on the server, or just start blank otherwise. the data can be loaded server side entirely to get some benefits of SSR, thus load_fields_vanilla_fn has no reason to be exposed as an API endpoint.
the component also has some reactivity to display validation feedback to the user - so I'd like to also hydrate it rather than making the whole component entirely ssr.
If I mark the function loading as

#[cfg(feature = "ssr")]
let initial_data = create_resource(|| (), |_| async move { load_fields_vanilla_fn().await });

of course the wasm side of compilation will fail lamenting that initial_data does not exist. the way I found to make it work is to simply add a "stub" resource for wasm, such as

#[cfg(not(feature = "ssr"))]
let initial_data = create_resource(|| (), |_| async move { Ok(None::<StructForDbStorage>) });

and this works - but is this really the way to go? did I miss a simpler/more idiomatic way to do it?

[gbj]

That looks pretty straightforward to me. It's pretty rare that you want the data simply not to be accessible if you are navigating from another page, but if that's what you want, that's what you want!

i.e., taking a glance at this application, you are using server-side rendering and client-side hydration including the router. When you only have one page it doesn't matter because this one page is the only starting point. If you add another page like /foo, then if you load /foo and then click a link in the browser to /, it will give you the None version of the data even though it does exist on the server, because subsequent page navigations are rendered in the browser.

If that's what you want then yes, this is the way to do it.

[caligin]

and client-side hydration including the router
ah yes, of course! I somehow forgot that the router is hydrated too 🤦
thanks for confirming though. I still have the feeling that doing this can be handy in some places/situations, although I can't quite picture a clear case yet.