How to upload large static assets to heroku dyno?

[Boscop]

Thanks for creating the buildpack and this example :)

I'm using Rust also for my frontend, which I'm compiling to wasm with cargo web deploy.
I need the generated files on my heroku dyno but I'd prefer to not include them in my git repo (same for other large assets like static images).
What's the best way to upload them so that I can serve them from my dyno's file system?
Basically the equivalent of scp'ing the files inside target/deploy/*.

[Boscop]

Or what would be the steps to install cargo-web in addition to this buildpack, and then run it via release: in the Procfile?

[emk]

This is a very good question, but I don't know the answer!

You might try using a build.rs script to download the images at build time, and include them directly into your binary with include_bytes! (see the cargo and Rust docs). Or you might try looking into Heroku's multiple build pack support.

Good luck, and let me know what you figure out!

[emk]

Hmm, now that I've had a change to think about this more, this might be something we want to consider supporting directly somehow. But I mostly use wasm-bindgen instead of cargo web, so I don't really know the best way to proceed. I'm definitely open to a proposal, especially if it doesn't tie the buildpack too closely to cargo web.

[Boscop]

Because building the frontend takes a long time, ideally it should also benefit from the build cache.
I think it can be supported by this buildpack by allowing users to specify a config var such as CARGO_WEB_FRONTEND which will have the name of the subdir (crate) in the workspace that contains the frontend that can be built using cargo-web.
So the buildpack would check if that config var is set, and if so, it would install cargo-web after installing rustup and before building the backend it would build the frontend: cd into $CARGO_WEB_FRONTEND and run cargo web deploy (which will use the same $CARGO_TARGET_DIR for the build artifacts and then generate the frontend files into $CARGO_TARGET_DIR/deploy. These will then be copied to target/deploy.

The reason why the frontend should be built before the backend (and why the files have to be copied to target/deploy) is so that the backend can choose to embed the frontend files (e.g. with rust-embed):

#[derive(RustEmbed)]
#[folder = "target/deploy/"] // not possible to use $CARGO_TARGET_DIR/deploy here
struct Assets;

I think the frontend building functionality could also be provided by a separate buildpack that runs before this, but it would have to be 95% identical with this one because it would also need to install rustup if it's not already installed, and use the build cache etc.
Whereas when this functionality is added to this existing buildpack, it would be ~5 lines max.

The advantage of having the frontend building functionality in a buildpack instead of downloading the files at build time is that when using a shared crate for the API types, it always stays in sync between backend and frontend (just one deploy step), and there are fewer complications & expenses because everything runs on heroku instead of requiring another hosting provider.