bevy
bevy copied to clipboard
Web request example using `ehttp`
Objective
- Currently there is no example how to perform web requests from bevy. This PR fixes that and maybe hopefully starts discussion about providing at least basic web request capabilities to the engine.
- Fixes https://github.com/bevyengine/bevy/issues/6903
Solution
- Provide example how to perform web request, greatly inspired by https://github.com/foxzool/bevy_http_client crate.
Changelog
Added
async_web_requestexample usingehttplibrary.
The generated examples/README.md is out of sync with the example metadata in Cargo.toml or the example readme template. Please run cargo run -p build-templated-pages -- update examples to update it, and commit the file change.
The generated examples/README.md is out of sync with the example metadata in Cargo.toml or the example readme template. Please run cargo run -p build-templated-pages -- update examples to update it, and commit the file change.
I'm in favor of adding this example: this is a tangible grounded example in a domain where we badly need more.
still not a fan of adding this as an example in Bevy, and as is it doesn't show anything new so it adds more maintenance
Thx for great feedback @SpecificProtagonist ! I've simplified code greatly and now it should be a lot easier to follow. Also thanks of pointing out wrong task pool for you and @mockersf .
still not a fan of adding this as an example in Bevy, and as is it doesn't show anything new so it adds more maintenance
TBH, I don't agree, as it can become a beginning in starting work on providing web request capabilities to the engine.
BTW, is there any issue created for discussing adding web request support to the engine besides the issue that I mentioned in PR description?
still not a fan of adding this as an example in Bevy, and as is it doesn't show anything new so it adds more maintenance
TBH, I don't agree, as it can become a beginning in starting work on providing web request capabilities to the engine.
BTW, is there any issue created for discussing adding web request support to the engine besides the issue that I mentioned in PR description?
No issue yet for adding that in Bevy, it hasn't come up very often.
Could you try to make the example work in wasm? That would be new and useful as a start.
The generated examples/README.md is out of sync with the example metadata in Cargo.toml or the example readme template. Please run cargo run -p build-templated-pages -- update examples to update it, and commit the file change.
The generated examples/README.md is out of sync with the example metadata in Cargo.toml or the example readme template. Please run cargo run -p build-templated-pages -- update examples to update it, and commit the file change.
still not a fan of adding this as an example in Bevy, and as is it doesn't show anything new so it adds more maintenance
TBH, I don't agree, as it can become a beginning in starting work on providing web request capabilities to the engine.
BTW, is there any issue created for discussing adding web request support to the engine besides the issue that I mentioned in PR description?
No issue yet for adding that in Bevy, it hasn't come up very often.
I will create one then later then. For someone with my background (mobile games before, now game dev tools with a lot networking) it's a must have in a game engine.
Could you try to make the example work in wasm? That would be new and useful as a start.
Isn't that the issue that tasks don't work on wasm now?
Could you try to make the example work in wasm? That would be new and useful as a start.
Isn't that the issue that tasks don't work on wasm now?
No, they work, but you can't get a result from them
Could you try to make the example work in wasm? That would be new and useful as a start.
Isn't that the issue that tasks don't work on wasm now?
No, they work, but you can't get a result from them
So is there a way to get that value? Using a Mutex or something else? Because right now I am not quite sure what do you expect from me- is it to implement the web requests other way than using task or using task differently to achieve that?
@mockersf @SpecificProtagonist @BD103 Example now should work on web as well.
You added a new example but didn't add metadata for it. Please update the root Cargo.toml file.
You added a new example but didn't add metadata for it. Please update the root Cargo.toml file.
You added a new example but didn't add metadata for it. Please update the root Cargo.toml file.
You added a new example but didn't add metadata for it. Please update the root Cargo.toml file.
To address @rlidwka is it not possible to just feature gate ehttp dep like so many other features in bevy?
@miketwenty1, this is not a feature, this is an example.
If you need 3rd party dependencies in examples, it might be worth considering to make them as separate crates (with their own cargo.toml) like axum does: https://github.com/tokio-rs/axum/tree/main/examples
@rlidwka Makes sense. Any discussions you know of, I can follow, in relation to adding async web requests natively within bevy without a 3rd party dep?
Any discussions you know of, I can follow, in relation to adding async web requests natively within bevy without a 3rd party dep?
None.
Imho, this is too rare of use-case to have in bevy core, and for those people who needs it, it's easy enough to implement using any of the 3rd party crates.
I've implemented this before myself a few times in my projects, which you can look at here: https://github.com/bevyengine/bevy/discussions/11108
(that being said, wasm support and other cross-platform concerns - like TLS - can be a compelling argument in favor of having small client in bevy)
I'm going to nominate this PR to be closed. I personally believe that networking is too game-specific and should be handled by 3rd party plugins. Even adding a networking library such as ehttp takes a step in this direction, a step that I'd rather not make.
- The work adds features or abstraction of limited value, especially in a way that could easily be recreated outside of the engine.
There's no SME for networking, so I'm going to leave this to the maintainers to make the final decision.
I think the energy required to come to a decision here would be better spent elsewhere unfortunately.