Roadmap

Goal

Align current hyper to the hyper VISION.

The VISION outlines a decision-making framework, use-cases, and general shape of hyper. This roadmap describes the focus areas to continue to improve hyper to look more like what is in the VISION.

Focus Areas

While open source is not a company, open source can be guiding. We can focus attention to specific areas of improvement, which are based on conversations with users, and prioritized by frequency and impact.

To that end, the following 4 areas are current focus of the project:

1. Documentation
2. hyper-util
3. HTTP/3
4. Observability

Each area benefits from having a top level description and goal, a place to track progress, and a champion (or two) that helps push the effort.

Documentation

hyper has stabilized, so investing in documentation is wise! The way it is used won't change much, so documentation won't become outdated quickly. A tool that people don't know how to use isn't helpful at all. This helps hyper be Understandable.

The documentation focus area includes several different forms:

• The API docs as a reference.
• Examples as form of how-to.
• Website guides as tutorials.

Each of these could benefit from dedicated planning of their overall structure, editing the content that already exists, and creating the rest that is sorely missing.

hyper-util

hyper-util serves two main purposes:

1. Provide useful patterns that build on top of hyper.
2. Explore, stabilize, and graduate some of those patterns into hyper itself.

To that end, there are several new features that can be worked on and iterated on in hyper-util right now:

• New design for a higher-level Client.
• Breaking apart some patterns from reqwest, such as proxy helpers.
• Server automatic version detection.
• Improved builder patterns that make it easier to configure complicated options.

HTTP/3

hyper has an HTTP/3 crate, h3, that is generic over any QUIC implementation, similar to how hyper's HTTP/1 and HTTP/2 can be provided any IO transport. It supports much of HTTP/3 already, and interoperates with most other implementations. While some brave users have been trying it out the hard way (such as reqwest), it's time to bring HTTP/3 to more users.

The aim is to eventually support hyper::client::conn::http3 and hyper::server::conn::http3.

To do so, work is needed:

• Harden the h3 crate itself, such as fixing any straggling interop issues, and filling out the spec conformance tags we use for accountability.
• Proposal for (initially unstable) hyper::rt::quic integration, allowing people to bring their own QUIC.
• Write the hyper::proto::http3 glue that translates hyper's connection patterns with the h3 crate.

Observability

It's extremely common once operating a service using hyper to want more visibility in what exactly is happening. It's important to realize that there are 3 concepts involved that frequently get conflated: events, tracing, and metrics.

Some existing ways to get some of these:

• Unstable tracing integraton inside hyper.
• tower_http::trace which instruments outside of hyper, using Service and Body.

However, there are some events and metrics that are only known inside hyper, and having official, stable support would be very helpful.

Some potential options would be:

• Stabilizing specific tracing events (blocked on the tracing crate stabilizing...)
• Provide a rudimentary, programmatic way to query metrics without another crate.
• Provide some sort of hyper-metrics helper.

Beyond

The above are focus areas that are the most frequently asked for, and so have the most attention. That doesn't mean that nothing else can be worked on.

Motivated individuals that want to help make other improvements are certainly welcome!