ingres: webhook: use hyper instead of the ad-hoc http implementation #17
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…tion In the future we will likely want to do more things via HTTP, namely serving prometheus metrics, providing a status page or allowing the jobs inside of the machines to upload artifacts. Growing a custom web server to do all of these things would be possible, but not really a reasonable thing to do. Instead use the hyper crate as a HTTP server implementation for the webhook endpoint. Using hyper as a server crate has the benefit of already being in our dependencies via the octocrab crate. As far as I can tell this is however the only benefit of hyper (in our low-traffic usecase at least). The interface seems to be designed by a committee of drunk lawyers that are paid by the number of crates they split their completely bonkers traits into, as a result of this it is about as ergononic as a designer chair. The documentation is strewn all over the place between all these crates and the hyper doc writers have, in all their wisdom, included `#[doc(hidden)]`s in their documentation, making it even less navigable. Maybe what's hidden is proprietary knowledge that they can bill extra for. I hated any minute working with hyper so far. We are in for a good time.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the future we will likely want to do more things via HTTP, namely serving prometheus metrics, providing a status page (#8) or allowing the jobs inside of the machines to upload artifacts.
Growing a custom web server to do all of these things would be possible, but not really a reasonable thing to do.
Instead use the hyper crate as a HTTP server implementation for the webhook endpoint.
Using hyper as a server crate has the benefit of already being in our dependencies via the octocrab crate.
As far as I can tell this is however the only benefit of hyper (in our low-traffic usecase at least).
The interface seems to be designed by a committee of drunk lawyers that are paid by the number of crates they split their completely bonkers traits into, as a result of this it is about as ergononic as a designer chair.
The documentation is strewn all over the place between all these crates and the hyper doc writers have, in all their wisdom, included
#[doc(hidden)]s in their documentation, making it even less navigable. Maybe what's hidden is proprietary knowledge that they can bill extra for.I hated any minute working with hyper so far.
We are in for a good time.