Including resources/assets in the built Compute package

Hello,
Currently building a package creates two files :
bin/main.wasm
fastly.toml

Question is : Is there any way to add a custom file, such as another toml or json, that the Wasm binary would load/read at the runtime?

The usecase is to provide a package with customizeable settings that the user can easily change himself & redeploy, without having to rebuild the wasm.

I’ve tried Cargo’s include instruction, but it doesn’t seem to work. And the docs of compute build don’t mention any option for that.

I know the usecase above could be achieved with Dictionnaries/Config Stores, but I’m asking in a more general sense (for example what if a resource is a binary file)

Hi Artem,

Thanks for reaching out!

I don’t know the answer off the top of my head, so I’ll reach out to our Compute platform team to find out more for you, but in the mean time there are a couple of things you could try.

The first thing is the compute build command has a --include-source flag which includes your entire project source code inside of the package .tar.gz but I’m not sure that would help as I believe the Wasm binary is deployed in isolation.

So with that in mind, it might be better to try embedding content inside the binary. If you’re using Rust then the language provides two separate macros for this (include_bytes! and include_str!) or if you’re using Go you can try the embed package.

I’ll drop some feedback here once I hear back from our Compute team.

Thanks!

EDIT: Actually, I would imagine embedding to be the way to go because that’s what our Rust starter kit currently does: https://github.com/fastly/compute-starter-kit-rust-default/blob/main/src/main.rs#L65-L67 (it loads a HTML file from the same directory as the src code https://github.com/fastly/compute-starter-kit-rust-default/tree/main/src using the include_str! macro).

Thank you for the suggestions !
--include-source is interesting indeed, however if possible I’d like to provide a single file (also it wouldn’t be used at the runtime, only as reference - requiring a rebuild if the user wants to change something)
I’ve also looked into include macros, however these work exclusively with static strings/bytes, as they are resolved at the compile time (as if the data had been hardcoded in the binary) - requiring a rebuild in case of resource update, so that wouldn’t work with a resource that I’d like to be loaded at runtime

Understood, thanks for clarifying :+1:

I’ll still reach out to our Compute team about this.

Thanks!

In the meantime, you mentioned not wanting to use Fastly’s Config Store is this because the thing you wanted to load might be a binary file? If so would Fastly’s KV Store be a suitable alternative?

One comment received so far was possibly having an origin server (i.e. backend) that the Compute service could call. The origin would be able to serve the file and the Compute service would cache it, but I guess it depends on your use case and if you even have an origin to call out to.

1 Like

Yes, I’m thinking about resources in general which include binary ones. KV store looks like a suitable solution
It is also a sound alternative to make the resources available on a separate server, although if private some kind of auth would be needed.

Then if there is no way to directly package&read resources at runtime, I will go with KV store alternative. Thank you for your support

1 Like

Hi Artem,

The Compute team have explained that they are aware of the need to support these types of workflows and this is something they are tracking/thinking about. For now, the recommendation is to use a KV Store :+1:

Thanks again for reaching out on the forum and sharing your use case.

1 Like