https://github.com/chillfish8/hyper-graphs
Some example diagrams to help understand the tokio/hyper ecosystem.
https://github.com/chillfish8/hyper-graphs
Last synced: about 24 hours ago
JSON representation
Some example diagrams to help understand the tokio/hyper ecosystem.
- Host: GitHub
- URL: https://github.com/chillfish8/hyper-graphs
- Owner: ChillFish8
- Created: 2022-01-04T22:24:12.000Z (about 4 years ago)
- Default Branch: main
- Last Pushed: 2022-01-04T22:39:22.000Z (about 4 years ago)
- Last Synced: 2025-02-01T14:32:16.881Z (11 months ago)
- Size: 2.93 KB
- Stars: 0
- Watchers: 2
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# hyper-graphs
Some example diagrams to help understand the tokio/hyper ecosystem.
# The most common case - Server
The most common case you'll see is Hyper running on the tokio runtime. Tower provides a set of utilities and a basic middleware-based framework on top of hyper's lower level design to make it easier to build frameworks around hyper and / or use tower as a framework itself.
That said alot of frameworks also just use hyper directly e.g. [poem](https://github.com/poem-web/poem) or [thruster](https://github.com/thruster-rs/Thruster)

# The most common case - Client
Hyper provides a client implementation which is reletively low level, this is because alot of the HTTP spec is shared by both client and server.
Reqwest is the only client I know built on hyper's client and it also provides it's own extensions like blocking / syncronous support. WASM I believe is completely seperate to hyper.

# Hyper on other runtimes
Because hyper and it's relevant crates are generally generic over key parts e.g. IO layer and runtime. You can infact swap out things like tokio with say `async-std` or in some cases like [Google fuchsia](https://fuchsia.dev/) where they implemented their own IO / runtime handler and ran hyper on top of that.
# Hyper's internals on a diagram
