📝 add deployment docs with Granian

[gi0baro]

Granian is a Rust HTTP server for Python applications which supports ASGI and HTTP/2.

It isn't as well known in the FastAPI community as an option - hopefully this will help that.

[tiangolo]

📝 Docs preview for commit 4467a44 at: https://6499e4188604e005d54425c6--fastapi.netlify.app

[gi0baro]

Any news on this?

[gi0baro]

FYI Granian 1.0 added support for lifespan state, thus the lifespan method is now supported instead of relying on deprecated lifespan events.

[JeyDi]

@tiangolo @Kludex any news on this?

[sreenivasulureddysura]

@gi0baro @tiangolo @Kludex any update on this? Good to include granian. Uvicorn + Gunicorn performance is slow if dealing with the 1 lacs of records.

[sreenivasulureddysura]

📝 Docs preview for commit 4467a44 at: https://6499e4188604e005d54425c6--fastapi.netlify.app

@tiangolo @gi0baro It would be nice to add granian.run command to take all Options(ex: host, port etc)

[tiangolo]

📝 Docs preview for commit c3e4adb at: https://f18da17c.fastapitiangolo.pages.dev

[sreenivasulureddysura]

@tiangolo In which release it will be available?

[sreenivasulureddysura]

@tiangolo In which release it will be available?

[sreenivasulureddysura]

@tiangolo any update?

[gi0baro]

tl;dr I'd really like to have an update from a maintainer here to – finally – have this merged or rejected.

I feel quite uncomfortable making this comment, and I've spent a few hours thinking about this, but given this is a 39 lines docs diff opened more than 1 year ago, here I am.
Again, I don't feel comfortable complaining on this, as I also am the main/single maintainer of several different projects in the Python ecosystem, and I totally understand the difficulty – sometimes even pain – in allocating time and resources to process issues, discussion and pull requests on projects in addition to all the activities these projects require (coding, design, architecting, promotion, community, etc.), especially consider that such time goes on top of everything else sum, like a 8-5 job and real life; I totally get it @tiangolo: I fail to properly do this even on my projects which have such a tiny popularity compared to FastAPI.
But, at the same time, I find quite difficult to imagine no one from the maintainers had the time to leave a feedback on this in 13 months; it feels quite bizarre to only receive notifications on this 'cause people from time to time ask for updates.

I don't know what the p3 label sticked on this for 6 months means, but it doesn't feel right to me leaving this kind of PRs in this limbo without any form of feedback/change request/comment. And again, I never claimed to have this merged; this can be easily rejected, as soon as there's a reason for that decision. The total absence of communication, on the other hand, doesn't really seem a good process, at least to me.

I never wanted to unsubscribe or close this, but the frustration is tempting me in this direction, sadly.
And maybe all of this is just me outbursting, but hey, 13 months is a long time to accumulate frustration 🤷‍♂️

[tiangolo]

Thanks for the comment @gi0baro, I understand your frustration.

About this PR

Here's the thing, I would need to see where are the places where notes around this would be relevant. It would probably make sense to include several alternatives, e.g. Nginx Unit. But then I'm not sure it would make sense to have instructions for each of them, or maybe it would be better to have a page listing the servers with links to their websites.

I'm also thinking of simplifying the docs not having too many options everywhere, to facilitate the decision, that was one of the reasons to build the fastapi CLI.

So, it's not about merging or rejecting the 39 lines, but about reviewing all the rest of the docs and places where it would make sense to have it or not.

About the process and frustration

Now, even though I would probably be included to simplify all the docs and not have execution instructions for each tool and instead have a page listing several or all the available ASGI servers, I'm not decided on that yet.

I haven't sat down to review this PR and review all the relevant sections and information. So, I'm not decided on this PR, about rejecting it or (probably tweaking it) and accepting it.

My thought was that closing it saying "I'm not sure yet", wouldn't be nice. So I was defaulting to leaving it open until I decided to take it or when I had made an alternative PR that would supersede it.

[gi0baro]

Thanks for the comment @gi0baro, I understand your frustration.

Thank you for the reply, I appreciate.

I haven't sat down to review this PR and review all the relevant sections and information. So, I'm not decided on this PR, about rejecting it or (probably tweaking it) and accepting it.

My thought was that closing it saying "I'm not sure yet", wouldn't be nice. So I was defaulting to leaving it open until I decided to take it or when I had made an alternative PR that would supersede it.

I totally understand that @tiangolo; again, I slipped into the same condition on my projects. But that's exactly where the frustration comes from (and came to others when I was on the other side of the story), 'cause when I read this

Here's the thing, I would need to see where are the places where notes around this would be relevant. It would probably make sense to include several alternatives, e.g. Nginx Unit. But then I'm not sure it would make sense to have instructions for each of them, or maybe it would be better to have a page listing the servers with links to their websites.

I'm also thinking of simplifying the docs not having too many options everywhere, to facilitate the decision, that was one of the reasons to build the fastapi CLI.

everything makes perfect sense.
Maybe having even shorter notes like this in the affected PRs and an on-hold label or similar can be a low-effort improvement in this sense.

So, it's not about merging or rejecting the 39 lines, but about reviewing all the rest of the docs and places where it would make sense to have it or not.

My thought was that closing it saying "I'm not sure yet", wouldn't be nice. So I was defaulting to leaving it open until I decided to take it or when I had made an alternative PR that would supersede it.

Letting me now of that when you first felt unsure might have led to keep the discussion open.
For instance: now that I know what you think, I can propose to open a PR in that direction which reviews the whole deployment thing with FastAPI so we can end-up with a solution you actually like and that was contributed by the community.

Would you be interested in a PR that tackles servers and deployment in a more dedicated way, and moving the discussion over there?

[tiangolo]

Thanks for the feedback @gi0baro! I took that in mind while setting up the new structure for us to handle new PRs, so there's clearer feedback. Thanks!

I think it will be easier for me to write the new section about deployment myself than reviewing an external PR without the ideas I've had in mind. So, probably better let's keep this on stand by for a bit. Thanks!

[bmoore]

I understand the want to refactor, but I do keep coming back to this PR (from google) to find that launch line for granian in FastAPI. Merging this simple change, and then refactoring documentation would be the more efficient route (for me personally), and might also clear up your mental backlog.

[tiangolo]

Thanks @gi0baro and everyone for the interest here! 🍰

I just updated the docs for serving FastAPI apps here: #12069

There are now links to several ASGI servers, including Granian. 🚀

I updated the other parts to simplify and reduce the options and recommendations, so, the docs in FastAPI are now simpler, but with links to several alternatives so that everyone can explore more on their own.

Given that, I'll now close this one. Thanks! ☕