#[perseus::engine_main] and #[perseus::browser_main]

[ghost]

How to write code under #[perseus::engine_main] and #[perseus::browser_main]?

[arctic-hen7]

You've stumbled across a currently undocumented feature, which will be properly documented before v0.4.x is released! In general, you shouldn't use these, since this is a very advanced feature that you shouldn't need unless you have a very advanced use case for tinkering with the deep internals of Perseus.

That said, if you really want to play with this, #[browser_main] is the entrypoint to your app in the browser, and should call perseus::run_client(fn), where fn is the function that returns your PerseusApp. As for #[engine_main], that's the entrypoint to your app on the engine (i.e. the server-side, and at build-time), the contents of which usually look like this:

// Get the operation the user wishes to run from environment variables
let op = perseus::engine::get_op().unwrap();
// Run the default engine with `fn` being the same as it was for the browser main, and `server_fn` being a function that returns your server (see `examples/core/custom_server` for what this could be, it's also the argument to `#[perseus::main(server_fn)]` when you use that)
let exit_code = perseus::engine::run_dflt_engine(op, fn, server_fn).await;
// Terminate the process with whatever exit code we got, so that the user gets some sensible error messages if required
std::process::exit(exit_code);

Note that you must have both if you choose to use these!

[ghost]

Is it possible to send arbitrary data from users' browsers to engine-side, then the engine-side save that data to hard disk, without using #[perseus::engine_main] and #[perseus::browser_main]?

[lukechu10]

Is it possible to send arbitrary data from users' browsers to engine-side, then the engine-side save that data to hard disk, without using #[perseus::engine_main] and #[perseus::browser_main]?

Yes definitely. As @arctic-hen7 said, these two attributes are very niche and you will probably never need to use them. just look at the custom server example where you can set up API routes just like a regular backend server.

[arctic-hen7]

Also @auts2022 remember to run perseus snoop build before perseus snoop serve, as documented, since snooping bypasses the regular build process for debugging.

[ghost]

Can we use #[cfg(not(target_arch = "wasm32"))] and #[cfg(target_arch = "wasm32")] instead of #[perseus::engine_main] and #[perseus::browser_main]?

[arctic-hen7]

@auts2022 no, those are completely different. I would strongly suggest you read the Rust book, since Perseus assumes a fairly robust knowledge of the language. The cfg macro is designed to only compile the annotated code on a certain target, while the main attributes are from Perseus, and define the entrypoints to your app.