Build and save precomposed component

[itowlson]

This was requested by @tschneidereit.

The idea is to have a spin build option that would, as well as building, compose on all dependencies, and save the result, giving you a fully composed Wasm binary that you could use in any host with a suitable set of APIs. Till's specific interest is WASI components being hosted in the browser.

At heart this is pretty easy - we do something similar as part of spin registry push, and as part of target env checking - but it turns out there are... complications. OF COURSE IT DOES THERE ARE ALWAYS COMPLICATIONS AARGH

We need to define:

• What happens if the app contains more than one component? I guess the output location is a directory rather than a file? And the output Wasm files are named for their... parent files? their component IDs? (Spoiler alert: whatever your initial thought, it is not that easy, because middleware.)
• What happens if a component declares permissions? Till has some far-future ideas about encoding that information in the Wasm but that's out of scope for this issue, so in the interim: warn? error? let it be and they will find out soon enough?
  • A specific consideration here is files. When we publish an app we include its files in the OCI artefact. We can't do that in a bare Wasm file. (Yes, I know about virtualisation, out of scope, out of scope, out of scope.)
• What happens if an app trigger contains middleware? Middleware throws off the cosy "we are building components" model, because now hey we are actually building trigger handlers, how about that. For example, the same component might appear at different routes with different middlewares: we are no longer building one component once, and we are no longer outputting it only once. But if the saved composition doesn't include middleware, then the developer is only getting half the story.
  • A plausible starting point is to say "trigger dependencies are an error" because Till's initial browser use case doesn't seem to have triggers in play. But longer term (if I understand correctly) Till wants Spin to be an attractive build tool for other Wasm/WASI hosts, including HTTP ones, so that would be only a temporary stepping stone.
• Probably a bunch of other stuff I will only think of as I start implementing

[itowlson]

In the light of #3697 we should assess whether it's meaningful to have this option on app build, because really what Till is asking for sits better as "what Michelle said, plus deps."

(ETA: I guess it depends on the timing of Michelle's feature)

[michelleN]

What happens if the app contains more than one component? I guess the output location is a directory rather than a file? And the output Wasm files are named for their... parent files? their component IDs? (Spoiler alert: whatever your initial thought, it is not that easy, because middleware.)

yeah directory makes sense. Maybe some default naming conventions like <component-id>-composed.wasm but yeah middleware really throws a wrench into things. Can we add an optional trigger ID field to each trigger and then use a naming convention <trigger-id>-composed.wasm?

What happens if a component declares permissions? Till has some far-future ideas about encoding that information in the Wasm but that's out of scope for this issue, so in the interim: warn? error? let it be and they will find out soon enough?
A specific consideration here is files. When we publish an app we include its files in the OCI artefact. We can't do that in a bare Wasm file. (Yes, I know about virtualisation, out of scope, out of scope, out of scope.)

We have some convo around this going on in the PR. Wonder if that is enough or even a decent start at the far-future ideas about encoding that information in the Wasm. Feedback welcome on PR.

What happens if an app trigger contains middleware? Middleware throws off the cosy "we are building components" model, because now hey we are actually building trigger handlers, how about that. For example, the same component might appear at different routes with different middlewares: we are no longer building one component once, and we are no longer outputting it only once. But if the saved composition doesn't include middleware, then the developer is only getting half the story.
A plausible starting point is to say "trigger dependencies are an error" because Till's initial browser use case doesn't seem to have triggers in play. But longer term (if I understand correctly) Till wants Spin to be an attractive build tool for other Wasm/WASI hosts, including HTTP ones, so that would be only a temporary stepping stone.

Maybe we don't add this convenience for triggers? Maybe you go the component manifest route from #3697 ?

In the light of #3697 we should assess whether it's meaningful to have this option on app build, because really what Till is asking for sits better as "what Michelle said, plus deps."

I guess only @tschneidereit can answer this question and I'm curious. The spin app is where you're building the final bits and are testing things out (at the moment) so I can see this option on app build as being pretty convenient.

[itowlson]

Can we add an optional trigger ID field to each trigger

This already exists but is almost never set.