Is this production ready

[baseplate-admin]

Hi, I have been following the development of granian for quite a while.

I am intrigued by the possibility of granian replacing existing ecosystem ( uvicorn + gunicorn ).

A couple of questions :

• Is this Production ready? ( do we have live sites running granian that you are aware of? )
• Is granian able to mitigate thundering herd problem?
• Can it handle requests more efficiently ? ( eg: better request distribution among worker threads )
• Do you plan on marketing this on social media ( like twitter,reddit ) to get more reach ?
• Can it become even faster ? ( Offload more works to rust | Optimize rust codes to make it more efficient )
• Can you make it standalone? { Do you plan on making it standalone? } ( make it run without a reverse proxy like NGiNX )
• How does it compare to robyn ( another rust framework based on actix )? ( can emmett + granian handle more requests per second compared to robyn )

Thanks for creating something like this. I was looking for something like this for a long while.

[gi0baro]

Hi, I'll try to answer point by point.

• Is this Production ready? ( do we have live sites running granian that you are aware of? )

Well, this really depends on your definition of production ready. For instance, I would say granian is production ready, but until 1.0 I wouldn't say is production grade software. And this is made on-purpose: while the version is 0.x we can change interfaces.

Regarding live projects, the emmett website is powered by Emmett 2.5, and thus, by granian. In the company I work with we have something like 3 services in production using Granian. Mind that all of these services don't process heavy traffic, so if your definition of production ready relies on high traffic then these are not great examples. In regards of other projects using granian I have no information available, I'll welcome people replying this thread.

• Is granian able to mitigate thundering herd problem?

AFAIK since granian sockets are non-blocking and tokio uses e-poll behind the scenes, it should not be a problem. But this is also depending on the lower platform, so I'm not even sure granian should tackle that kind of issues..

• Can it handle requests more efficiently ? ( eg: better request distribution among worker threads )

More efficiently compared to..?

• Do you plan on marketing this on social media ( like twitter,reddit ) to get more reach ?

I already posted about granian on Reddit, someone else posted on HN and I should be able to make a couple of talks this year about it.

Given this, I'm not exactly a marketing guy, so, no, I don't have any proper marketing plans about it.

• Can it become even faster ? ( Offload more works to rust | Optimize rust codes to make it more efficient )

I think there's still room for performance improvements, but more on the Python <-> Rust interaction rather than offloading. As of today, there's no really much else to offload from Python, which is called only to run the application code.

• Can you make it standalone? { Do you plan on making it standalone? } ( make it run without a reverse proxy like NGiNX )

I think granian is already standalone. There's no need to put something else on top of it, unless you need features not already present in granian itself.

• How does it compare to robyn ( another rust framework based on actix )? ( can emmett + granian handle more requests per second compared to robyn )

I think the scope of the two projects is really different. robyn is a web development framework (comparable to emmett) which integrates a proprietary (not closed source, but proprietary in terms you cannot use the server part of robyn without writing entire applications with it) server which is based on actix (which behind the scenes uses hyper, the same library used by granian), while granian is just a server, that can be used with any WSGI/ASGI/RSGI framework in the Python ecosystem.

So, probably comparing robyn and granian is quite like comparing apples and oranges; robyn can be compared to emmett: I'm pretty sure robyn is faster compared to emmett for a couple of reasons:

• emmett was not designed to be the fastest web framework out there; is a full-stack framework designed more on simplifying developer experience and giving an all-in-one solution
• emmett doesn't have any Rust-backed code or optimization (yet?) while robyn is almost 100% Rust code

Thanks for creating something like this. I was looking for something like this for a long while.

Thank you for your interest!

[baseplate-admin]

Hi thanks for answering in detail. It's nice seeing someone actually maintaining a software with passion. But I have couple of counter question :

But this is also depending on the lower platform, so I'm not even sure granian should tackle that kind of issues..

Fair enough. But uwsgi handles it. I think its better to have some form of documentation, no?

More efficiently compared to..?

Gunicorn + Circus ?

Given this, I'm not exactly a marketing guy, so, no, I don't have any proper marketing plans about it.

Fair enough ( tho if users find it promising, they will do this part for you 👀 )

I think granian is already standalone.

So does it have the pitfalls listed here?

• Denial of service
• Managing Backpressure

---

Lastly do you have full feature parity with uvicorn/daphne ?

And will i run into the problem described in this blog if i use granian?

[gi0baro]

Fair enough. But uwsgi handles it. I think its better to have some form of documentation, no?

Sure thing, but at the moment granian doesn't have any documentation at all :)
This can be added to the documentation once it will exist

More efficiently compared to..?

Gunicorn + Circus ?

Never heard of Circus and never used. As fair as I got from briefly reading the documentation, Circus just handles the socket, so I would suppose there's absolutely no difference in requests distribution among Gunicorn workers compared to plain Gunicorn.

And granian won't do anything particular on the sockets as well, using multiple processes will rely on the kernel, using multiple threads will rely on the tokio event loop.

So to answer your question: is probably more efficient only when using multiple threads.

So does it have the pitfalls listed here?

• Denial of service
• Managing Backpressure

Yep. But I think we're mixing quite several things here: one thing is asking if granian is standalone, and thus can be deployed directly without anything over it, another thing IMHO is asking which features granian provides in terms of scaling and attack protection. Considering the hypercorn analysis on attacks, granian won't set the keepalive timeout for TCP connections, and the response writes are handled by hyper (which are Stream based, so is the same of having coroutines in Python).

Since granian is at its very beginning, I think the only thing I can suggest you is to run tests for such things and see how it behaves :)

Lastly do you have full feature parity with uvicorn/daphne ?

I need to double-check, but I think the only thing missing in granian compared to uvicorn is the ability to pass a logging configuration via json from the CLI, everything else should be 1:1. Regarding daphne I have no idea, I didn't check its features.

And will i run into the problem described in this blog if i use granian?

That's a hard question to answer: it depends.
If we're talking about a WSGI application, served by granian using a large number of processes, then yes.
Anyway, if I have to be honest, with those numbers I would probably rely on infrastructure facilities and orchestrators (kubernetes?) rather than pushing to the limits a single node with hundreds of processes.

[baseplate-admin]

Alright thanks a bunch for answering everything. I am going to give granian a test drive :)

I will re-query if i have any more questions.