Add usage examples

[mxgrey]

To help folks that want to make practical use of bevy_impulse, we should provide some examples where the library is being applied to use cases that are substantial enough to be instructive while simple enough to be easily understood. The unit and integration tests can be referenced to see how the API works, but those demonstrations take a lot of imagination to translate to real-world use cases.

Anyone who has an idea for a specific example use case can open an issue ticket describing what kind of use case they would like to see.

[TanJunKiat]

I think everyone would benefit from having simple examples and maybe some basic documentations to help them implement, test, and develop this repository.

Maybe I can get it started first, and maybe list down some things we should be covering.

Examples

• Async services
• Blocking services
• Continuous services
• Services Discovery
• Spawning workflows

To make the example simplier, I am thinking of using some basic tools in bevy and maybe leverage on bevy_egui to allow users to interact and trigger services while keeping the code simple and clean.

[mxgrey]

The thing I've struggled with most and the reason I haven't written an example yet is I've found it very difficult to think of a concrete example which is both complex enough to serve as a useful reference point and simple enough that users won't feel immediately overwhelmed by the details.

In my mind a good example should have one or more of these elements:

• a REST API call inside of an async provider (e.g. to fetch a .png to use as a texture)
• loading a file/asset from disk using an async provider
• a continuous service that controls the motion of something in the scene
• a workflow that defines the behavior of some agent(s) in the scene, switching between different modes and being able to loop

Maybe the best way to achieve "simplicity" is to put the key workflow code inside main.rs and then hide the implementation details in other module (.rs) files. So if the example uses egui then any systems that implement UI-related logic can go into a ui.rs file while main.rs is reserved for only the application setup and workflow building.

[TanJunKiat]

I share the same thoughts.

The examples should be simple enough for people to understand the concept and usage.

I see there can be two approaches from our discussion:

Centralized approach

Having 1 main.rs file that writes out the different services. (similar to bevy_egui)

Decentralized approach

Having multiple example files, (e.g. async_service.rs) which contains just enough to showcase the service. (similar to zenoh)

Miscellaneous

Both ways should have all the code that the users do not need to see (e.g. struct definitions, ui) embedded in either main.rs or lib.rs in the src folder, maybe encapsulated by a bevy plugin.

We can also write a REST API server using the warp crate so users can call GET or PUT to trigger the services.