feat(composition): Adding an example that shows composition of isolated components

[ritesh089]

This PR contains an example where component can be written and built separately in different languages and then composed together.

[itowlson]

Thanks for this @ritesh089! I'm afraid I'm not quite getting how this connects up to the book at the moment. For example, is the reason for it to illustrate something that needs to be added to the book? Or is it intended as a new example to illustrate existing book content? Once we understand that we can figure out the best way to move forward with it. Thanks!

[ritesh089]

The components are usually written in separate repositories and the great thing about the component model is reuse. The example currently shown in the docs uses a single wit and doesn't really show how to use the interfaces defined in separate packages.
Also for the tinygo reference, there is no example component that the developers can just clone and run immediately.
I had to create a separate repo with this example for my team to clearly understand how to use the component model and it helped.
I think this example will supplement the existing ones and help enrich the documentation. I was planning to make some documentation update PR's once this one is merged.Let me know your thoughts. @itowlson
.Thanks.

[itowlson]

Thanks @ritesh089 - I see what you mean about showing how this works across multiple packages and repos. What I'd suggest is making those documentation changes as part of this PR, so that the example is explained in context rather than merely existing unlinked in the examples directory. We can also maybe have a look at how we can structure the examples to ease maintenance of all this (a particular concern as we are likely to move to wac for composition in the not-too-distant future).

@kate-goldenring Does this sound appropriate to you, or do you feel it's outside the remit of the book (or would work better as a separate piece of content that the book can link to)?

[kate-goldenring]

I've heard other feedback that one WIT is an oversimplification. Updating the example to have a separate WIT for each package (essentially just separating out add) would make sense to me as a change this PR could morph into. The changes should update the existing tutorial directory rather than create a new one, too. I worry slightly about the maintenance cost of maintaining two similar examples, otherwise.

[ritesh089]

Thanks @kate-goldenring ,
I will update the PR by updating the tutorial docs and overwrite the tutorial directory.
Do you think it makes sense to keep a go component (sub) as an example along with the add (written in rust)?

[kate-goldenring]

Thanks @ritesh089. I'd keep the changes minimal to start, so retaining just the add component with the separated WIT and updating the documentation. Then in a separate PR we can consider adding the sub component.

[FrankReh]

I found the original version this composition very valuable as a nice jumping off point. It uses several wit files that are at logically different levels, and it builds a main that still needs to be composed to be runnable, and it uses clap and it shows all the steps necessary (although I'll admit I changed 'sub' to be Rust) and it shows how to see it run. A very nice and tight starting point for checking out other ideas or understandings.

If it doesn't fit here, maybe there is another place in the bytecodealliance ecosystem for nice starter examples.

[ritesh089]

@FrankReh , I didnt understand this part :
although I'll admit I changed 'sub' to be Rust

I think i will change this PR to draft for reference and open a new PR just updating the add component and doc for now .

[FrankReh]

@FrankReh , I didnt understand this part : although I'll admit I changed 'sub' to be Rust

I think i will change this PR to draft for reference and open a new PR just updating the add component and doc for now .

I think the example used a sub component that was built from TinyGo. I didn't want to pull that dependency into the build chain for myself so I just redid the sub component as Rust, using the add component as a starting point.

[kate-goldenring]

I found the original version this composition very valuable as a nice jumping off point. It uses several wit files that are at logically different levels, and it builds a main that still needs to be composed to be runnable, and it uses clap and it shows all the steps necessary (although I'll admit I changed 'sub' to be Rust) and it shows how to see it run. A very nice and tight starting point for checking out other ideas or understandings.

If it doesn't fit here, maybe there is another place in the bytecodealliance ecosystem for nice starter examples.

@FrankReh just to clarify, the current example in main also uses clap and creates a final runnable component. I think the path forward we discuss above of separating out the wit should bring in the benefit of having "several wit files that are at logically different levels"

[FrankReh]

@kate-goldenring You are right. I probably wouldn't have added my two cents here if I had not read through the published book for the component-model as one of the first things I read about a month ago. Looking at the tutorial back then, everything was so new I couldn't grok everything that was being accomplished. After a month of learning, coming at the proposed composition example made a lot of sense to me, mostly because now I knew enough that it helped fill in a lot of questions.

Yes, splitting the WIT into separate pieces will do well in showing just how modular the building blocks are, and how the WIT files can be used to build on each other.

I just looked at the tutorial again. Two other differences I see from the composition example:
One is that the first compose step can take multiple -d arguments.
The other is one I just noticed and still have to educate myself on further: the "tutorial/calculator/src/lib.rs" uses

cargo_component_bindings::generate!();

while the "composition/calculator/src/lib.rs" uses

bindings::export!(Component with_types_in bindings);

Believe me, I know writing good documentation is hard. Kudos to the team doing this. The step mentioned above to split the WIT files sounds great.

Also I appreciate how the Wasm Component tools work and can be used is a moving target. WIT is changing. Composing is changing. Repos are being moved around. And does one document how WASI Preview 2 was at the time of its announcement or where it is now.

I still think the project could benefit from a repo that held little examples of how people solved different things. But I can't say I know how that should be organized or where one draws the line between being approachable for a new person versus someone who has been around for a few months versus someone who has been around a few years.

So thanks again. Sorry for being so long winded on this.