From 9458fe787703827ed742df3543fdfc889e366d8b Mon Sep 17 00:00:00 2001 From: Jesse Hoobergs Date: Wed, 11 Sep 2024 12:17:34 +0200 Subject: [PATCH] Update 25_server_functions.md Add note on Number sizes --- src/server/25_server_functions.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/server/25_server_functions.md b/src/server/25_server_functions.md index 54fec37..8e04521 100644 --- a/src/server/25_server_functions.md +++ b/src/server/25_server_functions.md @@ -135,6 +135,11 @@ will generate a server function endpoint at `/api/hello` that accepts a POST req Server functions are a cool technology, but it’s very important to remember. **Server functions are not magic; they’re syntax sugar for defining a public API.** The _body_ of a server function is never made public; it’s just part of your server binary. But the server function is a publicly accessible API endpoint, and its return value is just a JSON or similar blob. Do not return information from a server function unless it is public, or you've implemented proper security procedures. These procedures might include authenticating incoming requests, ensuring proper encryption, rate limiting access, and more. +## An Important Note on Number Sizes + +When using Server functions, one should not use pointer-sized integer types such as `isize` and `usize` as the pointer-size of the server will probably be 64 bit, while the pointer-size in Wasm is 32 bit. +This will lead to a deserialization error when the server sends a number which does not fit in 32 bits. Use fixed size types such as `i32` or `i64` to mitigate this problem. + ## Integrating Server Functions with Leptos So far, everything I’ve said is actually framework agnostic. (And in fact, the Leptos server function crate has been integrated into Dioxus as well!) Server functions are simply a way of defining a function-like RPC call that leans on Web standards like HTTP requests and URL encoding.