aioquic VS k8s-openapi

One of the interesting patterns happening in Rust is io-less libraries. I'm not sure where best to link this phenomenon. It here s a open issue for an io-less quic library, from 2019, https://github.com/aiortc/aioquic/issues/4

It'd be so fracking sweet to see filesystems follow this pattern. If we could re-use the file system logic, but apply it to windows or fuse or Linux or wasm linearly-addressed-storage, that would allow such intensely cool forms of portability/reuse & bending/hacking.

for those wishing to use http3 with a Python web framework, the ASGI hypercorn[1] currently supports it.

made a Django example last week with a sample client based on the examples from aioquic[2]: https://github.com/djstein/django-http3-example

this example also includes the first pass at async Django REST Framework using adrift[3] based on these GitHub issues:

- https://github.com/encode/django-rest-framework/pull/8617

- https://github.com/encode/django-rest-framework/issues/8496

sources

[1]: https://github.com/pgjones/hypercorn

[2]: https://github.com/aiortc/aioquic

[2]: https://github.com/em1208/adrf

In your estimation where does the QUIC specification, HTTP/3 specification, WebTransport specification, aioquic QUIC and HTTP/3 implementation in Python https://github.com/aiortc/aioquic (notice the GoogleChrome/samples WebTransport sample code is described as local server "There's code for a sample local server at https://github.com/GoogleChrome/samples/blob/gh-pages/webtransport/webtransport_server.py") fit into the categories you color "Framework" and "Webserver"?

Whilst the article rightly mentions aioquic to use HTTP/3 with Python, it is only a minimal example server. Hypercorn is a compete ASGI server built on aioquic that is likely more useful practically.

It's called sans-io in Python land, which is where I heard it first.

https://sans-io.readthedocs.io/

I did it for one of my projects back in 2018 https://github.com/Arnavion/k8s-openapi/commit/9a4fbb718b119...

Another option is to implement your API in a sans-io form. Since k8s-openapi was mentioned (albeit for a different reason), I'll point out that its API gave you a request value that you could send using whatever sync or async HTTP client you want to use. It also gave you a corresponding function to parse the response, that you would call with the response bytes however you got them from your client.

https://github.com/Arnavion/k8s-openapi/blob/v0.19.0/README....

(Past tense because I removed all the API features from k8s-openapi after that release, for unrelated reasons.)

Macro expansion is slow, but only noticeably in the specific situation of a) third-party proc macros, b) a debug build, and c) a few thousand invocations of said proc macros. This is because debug builds compile proc macros in debug mode too, so while the macro itself compiles quickly (because it's a debug build), it ends up running slowly (because it's a debug build).

I know this from observing this on a mostly auto-generated crate that had a couple of thousand types with `#[derive(serde::)]` on each. [1]

This doesn't affect most users, because first-party macros like `#[derive(Debug)]` etc are not slow because they're part of rustc and are thus optimized regardless of the profile, and even with third-party macros it is unlikely that they have thousands of invocations. Even if it is* a problem, users can opt in to compiling just the proc macros in release mode. [2]

[1]: https://github.com/Arnavion/k8s-openapi/issues/4

[2]: https://github.com/rust-lang/cargo/issues/5622

>OpenAPI Generator allows generation of API client libraries from OpenAPI Specs

It does, but the generated code can be very shitty for some combinations of spec and output language. I maintain Rust bindings for the Kubernetes API server's API, and I chose to write my own code generator instead. The README at https://github.com/Arnavion/k8s-openapi has more details.

k8s_openapi - https://github.com/Arnavion/k8s-openapi

For example: I have a routine that checks the value of (from k8s-openapi): Ingress -> IngressStatus -> LoadBalancerStatus -> Vec[0] -> String

As the maintainer of the Rust bindings that the library used in the article (kube) is backed by, I can confirm that Kubernetes' openapi spec requires a lot of Kubernetes-specific handling to generate a good client than generic openapi generators do not provide.

See https://github.com/Arnavion/k8s-openapi/blob/master/README.m... for a full description.

I also confirm that I keep it up-to-date with Kubernetes releases and have been doing so for the ~3 years that it's been around. Not just the minor ones every few months, but even the point ones; these days the latter usually only involves updating the test cases instead of code changes and they're done within a few hours of the upstream release.