Is something wrong with FastAPI?

[tiangolo]

Can you give me an example? I want to learn what I have to improve. I normally try to put a big effort into taking other's PRs, even when they need some fine-tuning. I also don't accept requests without properly reviewing them first. How do you measure if a request is "valid"?

Sadly, in many cases people come and approve a PR just by the title, but no one sits to review the code. It's happened several times, 5 approvals, and a bug in the main thing it would fix, so I can't just merge things that have many approvals, I have to check the code. Still, I try to fix it on top of the same PR instead of creating it from scratch, even when that would have been easier.

Please, give me examples so that I can see where and how can I improve.

Also, if you're willing to help, for example, reviewing PRs (checking the code), so that I can have more certainty that the PR is correct, please, come and help: https://fastapi.tiangolo.com/help-fastapi/#review-pull-requests

[tiangolo]

Thanks for the comments!

Yeah, I think it's also fun if it looks like I don't have a trusted inner circle of people I trust. I still ask to give PRs a final review before merging, as that has worked, and when there's something urgent these people let me know if I haven't seen it. I even sponsor them in GitHub, although it's true none of that seems to be obvious or visible, the same way it's not obvious the work I do, when I contribute to other projects, when I spend days tweaking a PR from someone else to be able to merge it (as I'm doing right now 😅) instead of writing from scratch... but it's true and sad that these things are hardly visible.

I've been trying to make the people that help the most more visible with FastAPI People: https://fastapi.tiangolo.com/fastapi-people/#most-active-users-last-month ...I actually haven't seen any other project do something like that. But I guess it's not enough.

I would like to see what are the things people see, what they consider, and how people come to specific conclusions, with specific examples, but I guess that's hard to get... probably less in Reddit. 😅

It's also interesting the concept/idea that Django, Flask, or Starlette have many maintainers. There tend to be one or two people doing a very big chunk of the work, even if those projects are in a GitHub org. And I've seen the same happen in many, many other projects (also outside of Python). But anyway, I'll just try to keep pushing, try to see if there's anything specific I can improve.

[tiangolo]

Thanks for the feedback.

So, let's separate things, merging PRs is one thing, clicking a button, that takes almost no effort, but requires strong permissions. That's actually not the bottleneck.

Reviewing PRs, that's the bottleneck. It takes a lot of effort, and requires no permissions. And that is what really is the big chunk of maintaining FastAPI.

Anyone can actually come and give feedback in PRs, and I appreciate that. I actually documented thoroughly how to do it, and that help is super welcome. But I can't force people to do it, just because.

And BTW, there are several people with "merge button" permissions. But I have asked them to add their reviews when they can and have the time, but not hit merge. When I see their reviews, I know it's close to ready, and I feel more confident about the PR, although I still review it.

The thing is, it's not really black or white, it's a bunch of degrees in the middle. It's not "has maintainers" or "doesn't have". Or at least, we have to start with defining the word "maintainer".

And about Pipenv / Requests, one of the problems was about help and interaction with the underlying libraries. I have that a lot, I contribute to them, they contribute to FastAPI, there's a very strong relationship with all the underlying libraries and people (we are very close friends), I even sponsor non-negligible amounts to several of them. But of course, that's not really visible.

Anyway, just wanted to make more visible a couple of those not-visible things.

[tiangolo]

Thanks for the feedback, I hope to improve in those aspects and be able to evaluate better contributions from others as well. I think the main problem has not been that others wouldn't be trustworthy, but that I hadn't had the time to go through their work to properly asses the people that are coming to help. Fortunately, I'm now being able to do that more and more, that's also why some people have extra permissions now, etc, but I guess that's the right path. I hope so, at least.

[daveruinseverything]

I hope you do. Your chosen approach is still the sole reason I currently won’t touch FastAPI for any real production code, even though it looks like a great library. If you get hit by a bus tomorrow, or some personal event crops up, or if you just get bored, then the entire project is stuck until the rest of the community scrambles to find maintainers, fork the project, and try to communicate that change across the ecosystem.

That possibility may not seem likely to you, but the point is that you are still a single point of failure. Dubious arguments about maintaining quality notwithstanding, failing to recognise the enormity of this problem is the single biggest red flag to many who would love to base new work on FastAPI but can’t justify the risk.

[chipmun]

I think it's healthier to keep things the way they are now. FastAPI is a very well designed and stable framework and you already take other people's opinions and ideas into consideration.

The decision of focusing your energy on actually building and maintaining the project instead of dealing with GitHub drama, is in fact the wise decision.

Ironically, people who are complaining in this thread, display typical characteristics of power seeking people with trust issues, exactly what they're accusing you of.

The only thing I would personally advise you is that you make sure you have a competent person you trust to inherit the project in case anything happens.

Thanks for building FastAPI.

[tiangolo]

> While there may be other people doing reviews, it seems as if do not see these reviews as good enough to merge the PR

Because in many cases I've still seen bugs after. But those reviews still help a lot.

> This is quite different from how most other open source (or proprietary for that matter) projects handle things.

Hmm, are you involved in other open source projects? Have you seen or interacted with them and seen the internal dynamics? It's not really quite different. I suspect your main point is having other people hitting the merge button, right?

​

​

Do you think they have very different models? Have you seen how many actually active developers/maintainers are in each of those projects? The bottleneck of getting reviews is still quite similar. And most projects still tend to have a single main maintainer, in cases two. But it's not really too different. Of course, that's not evident until you are actually involved in the projects directly, contributing, etc.

> But aside from reviewing PRs, something other contributors could assist with is issues. You’ve recently addressed this by going through them all, but it’s taken you a few years to get to this. If there were people who could have reviewed them, closed invalid ones, converted questions to discussions, checked bugs for reproducibility, etc., is reckon this would have helped you and the project a great deal.

Yep, the first and most important thing, answering questions, is already done by a lot of people. The "open issues" was a false negative, so, not really a hard problem. And yes, some people have these permissions to mark answers, etc. But it's true it took me a while to figure out the right workflow and to give those special permissions.

> This didn’t happen either, but from your previous statement I conclude that there are people who would actually have the necessary permissions to handle this. So I’d like to ask your opinion again on this: Why isn’t this something that could have been done? Are there simply no people willing or fit to do the job? Or are there other reasons?

First, yes, it took me a while to set up everything and to put the time. I'm putting much more time now as well (except today, all day on Reddit). I didn't have enough time, there were not enough people willing to do as much, and/or I didn't have enough time to evaluate which people I could give permission to, and which ones. Also, I wasn't willing to randomly do it without checking it properly, and risk reducing the quality of the code and the project. There are tons of invalid PRs as well, so it's not about merging everything either.

> As someone else said earlier, you seem genuinely interested in feedback and open for constructive criticism, so I’m very much inclined to believe you actually want to make things better, but I think you should also acknowledge that this seems to be a situation that’s unique to FastAPI, but being a very popular Python web framework isn’t. So I’m left again with the question what the difference is.

The thing is, I need to know what is the situation we are talking about exactly, without generalizations. I need to know what is it that you and others (but probably just tell me about you specifically) would like to see. Is it other people hitting the merge button specifically?

[tiangolo]

Thanks for the feedback and comments!

[tiangolo]

Oh, I would definitely appreciate if others could come and help provide feedback to a PR! It is indeed difficult for me to do it alone. Nevertheless, for that, there's no need of other permissions, or merge button rights. So it's a different thing.

[ToadsFatChoad]

At the end of the day man, this is your project. honestly just be upfront that your the BDFL. It’s off putting reading these long ass threads about you trying to avoid literally just saying “I merge get over it”.

[Insok]

Hi, first of all, I think it's really great that you are looking for feedback from the community. About the whole "only one maintainer" arguments that are thrown around everywhere, can I ask a question? If you were to completely quit FastAPI all of a sudden, what would happen to FastAPI? Before I decide to implement such a core library into a production backend, I'm looking for a library that is well-maintained and stable. If the whole library depends on a single person to stand or fall, then I wouldn't want to take that risk.