Provider Overview
There are three large categories of providers:
and up to three flavors within each category:
All of these different types of providers can be used as elements of a series or workflow, but they all have slightly different characteristics. For an in-depth explanation of the differences between them, you can look at the intro section for Callbacks and Maps, but the table on this page provides a quick overview to help remind you at a glance.
| Advantage | Caveat | Providers | |
|---|---|---|---|
| Blocking | No thread-switching overhead Instant access to all data in the Bevy ECS world Sequences of blocking providers finish in a single flush | While running, block progress of all series, workflows, and scheduled systems in the app (these do not block async providers) | ✅ Service ✅ Callback ✅ Map |
| Async | Executed in parallel in the async thread pool Can query and modify the world asynchronously from the threadpool Can use .await | Query and modifications of the world take time to flush Moving data between threads and spawning async tasks has non-zero overhead | ✅ Service ✅ Callback ✅ Map |
| Continuous | Run every system schedule update cycle, making them good for incremental actions Run in parallel with other Bevy systems in the schedule Instant access to all data in the Bevy ECS world | They wake up every system schedule update cycle, even if there are no requests queued for them | ✅ Service ❌ Callback ❌ Map |
Service
- Stored in the Bevy ECS and referenced via
Servicehandles. - Support delivery instructions and continuous services.
- Must be spawned via
Commands. - Can be used as a Bevy system.
Callbacks
- Stored in a
Callbackobject—not stored in the Bevy ECS. - Can be passed around as an object and cloned.
- Drops when no longer used anywhere.
- Can be used as a Bevy system.
Maps
- Minimal execution overhead.
- Cannot be used as a Bevy system.
All
- Can support output streams