gi0baro-dev

This guy had nice mustache

Granian maintainer here.

Can't speak for Robyn author, but in my opinion it's not a valid comparison. The only thing Granian and Robyn have in common is the usage of Rust and PyO3, but that would be like comparing two projects using Cython.

Granian is just a server, and as such it is comparable to projects like uvicorn, Daphne, hypercorn, gunicorn, uwsgi. It can be used to run any WSGI or ASGI application out there. Robyn is a web framework, and thus it does a lot more than Granian, and as such it can be compared to other async first web frameworks, like starlette, litestar, sanic, quart, Emmett, blacksheep.

If we're talking about performance then.. well it's still Python running the app code. There's no way to escape that. If we're talking about features, ergonomics, etc. then again, Granian is just a server, so there's not so much to talk about :)

Yup: `granian --interface asgi your_module:your_fastapi_app`

You can check benchmarks https://github.com/emmett-framework/granian/tree/v0.2.2/benc... ;)

Granian maintainer here.

While it might sound "odd", actually having two runtimes running in two different threads is not so strange. This is actually what you end up when spawning multiple Python processes even with uvicorn: each process will have the asyncio event-loop running in the main thread.

In Granian the Python runtime and the Rust ones communicate with each other in a non-blocking way, so – theoretically speaking – there's no additional CPU-bound load compared to a pure Python solution.

Also, theoretically speaking, the only condition I can imagine where the two runtimes fight too much with each other is in case where you have a single core system with so poor performance to not handle 2 threads concurrently, which is probably so rare that we don't need to think about it..

Probably I should add some resource usage tests aside to benchmarks, but – again, theoretically speaking – if the Rust code is more efficient than the Python one, the final CPU usage should be lower, or more efficient.

True. The "bad" thing about hypercorn is its poor performance, at least for now :/

Is not needed, is just a different async protocol implementation. Granian supports both interfaces, is a matter of how you want to write your application.

As you can see from benchmakrs (https://github.com/emmett-framework/granian/tree/master/benc...), the main advantage today of RSGI vs ASGI is the performance.

Granian maintainer here. As other people pointed out, the project relies on the Hyper Rust project, which at the moment doesn't support HTTP/3. Once the project will add support for this, will be implemented in Granian as well.

Granian maintainer here.

We have a couple of services in production at the company I work with, served with granian, they handles ~5k RPM traffic each (not so much) with no particular issues.

You can consider the ASGI support quite robust for the current version, WSGI was introduced in 0.2.0, so it might still suffer from bugs. RSGI is quite new as a protocol, so next versions might introduce breaking changes (but the RSGI specification has a version, so you can stick with a specific revision), at least until version 1.0 will be ready.