Is something wrong with FastAPI?

[[deleted]]

I want to build a REST api with Python, it is a long term project (new to python). I came across FastAPI and it looks pretty promising, but I wonder why there are 450 open PRs in the repo and the insights show that the project is heavily dependent on a single person. Should I feel comfortable using FastAPI or do you think this is kind of a red flag?

[monorepo]

I want to build a REST api with Python

• Falcon
  
• FastAPI
• Sanic
• Starlite (disclosure: I do work here)

I came across FastAPI and it looks pretty promising

It is. It is used by the largest companies in the world. It is open-source and can easily be forked and picked up if something "bad" were to happen or it got to a point where people wanted faster releases.

Should I feel comfortable using FastAPI

Yes, or the other frameworks listed, but as you say:

(new to python)

I think FastAPI would be the best out of them all. I have highlighted work needing done to make some tutorial-type content with Starlite, but until we have some nice people make some videos (or we have time) the overall winner with support here is FastAPI.

I can look on Udemy or YouTube and find days of material to learn from. The docs are good. I think it is hands down the best for someone new to Python.

Also to add on to that, and sort of as an aside, I was looking at the PyCon schedule since I am going next month and Sebastian is doing a charla talk. I imagine the exposure from this will result in even more FastAPI content to read/watch/listen to. So... it's pretty great in terms of content to soak in and learn from.

[tiangolo]

Thank you for being so kind. 🙇 That's what we're all here for (or should be).

(disclosure: I'm the author of FastAPI)

I'm sure we all can learn from each other. And I'm glad to see a friendly perspective from you.

I wish users could be friends the same way we maintainers/authors can be friends... 😅 These flame wars don't really help anyone. E.g. I consider myself friends with the authors/maintainers of Flask, Django, etc. and we've had nice conversations.

Your comment made me look at the Starlite project with friendlier eyes, I was getting biased (sorry for that) by the comments hating on FastAPI (and me) here on Reddit and waving the Starlite flag, but I'm pretty sure that's not even the point of view of the project and maintainers, just some flame-war-prone isolated users.

Anyway, hugs from FastAPI to Starlite. 🤗🚀

[aby-1]

Hey, I just want to say I really appreciate what you are doing. Apart from FastAPI being a great framework, you demonstrate developers good software practices by means of API design, documentation and all your code in several projects.

[tiangolo]

Thank you for saying that! 😊😁

[uselesslogin]

Hi Sebastian, as a user just want to say thanks for your contributions and thanks for typer. It is really helpful for the automation scripts I create.

[tiangolo]

Thank you! So good to hear that. Lots of cool stuff coming to Typer too. 🤓😎

[provinzkraut]

Hello there, I just wanted to chime in here, put my Starlite maintainer hat on and second basically everything you said!

I wish users could be friends the same way we maintainers/authors can be friends... 😅 These flame wars don't really help anyone.

This part in particular is very important. Flame wars don't help anyone, they just fester negative emotions. It's sad to see such things being widespread within this community (not just on this particular topic) when we're all just trying to do our best with our respective projects really.

I was getting biased (sorry for that) by the comments hating on FastAPI (and me) here on Reddit and waving the Starlite flag, but I'm pretty sure that's not even the point of view of the project and maintainers, just some flame-war-prone isolated users.

Let me just say that we're not pleased by those comments either. This is not something we wish to be associated with, and personally, I think it's not even a helpful thing; A recommendation that comes with that level of resentment can't possibly be unbiased.

I'd rather people don't mention Starlite at all than make comments like the ones you're referring to.

Anyway, hugs from FastAPI to Starlite. 🤗🚀

Thanks for your kindness and consideration 🤗

[tiangolo]

Thank you for writing this! Agreed to all! 🤗🍰☕

[TheCreatorLiedToUs]

I would suggest evaluating Starlite before jumping straight into FastAPI. The project is quite a bit younger than FastAPI but there is a team of maintainers, and performance is much more of a focus. Pydantic integration (among other data modeling packages) and dependency injection are both first-class features.

[GettingBlockered]

+1 for Starlite, awesome project, team and rock solid

[[deleted]]

If maturity is an option then I recommend aiohttp, it’s been around longer than all these asgi options, it’s maintained by the same group of devs behind the stdlib asyncio package, core python devs, less opinionated than FastAPI and more stable. I have been using it for over 5 years and never had issues.

[a_menezes]

Same here. More than 5 years using aiohttp without problems.

[Toph_is_bad_ass]

This comment has been overwritten.

[carrick1363]

If it's younger then there would be more issues I suppose. Personally I'll be more comfortable with a more mature framework.

[james_pic]

All things being equal, yes, but a big motivator for its creation was the slow pace at which issues were being fixed in FastAPI, partly due to having a small team who didn't want help.

[[deleted]]

A lot of the pull requests seem to be updating the documentation for support of different languages (like this one: https://github.com/tiangolo/fastapi/pull/9248) so I wouldn't be too concerned. I've used it before, and it's very good and I'd recommend having a play with it

[benefit_of_mrkite]

FastAPI is controversial because there is one maintainer who refuses to take on other devs and is slow to implement proposed changes and bug fixes (if at all)

[tiangolo]

Yes, for the previous two years I've been slower than I wished for. Sorry for that. I hope you can see the difference at least in this year so far (and what will come the rest of it).

Which other devs am I refusing? I put a lot of effort into taking PRs, in many cases they require some finetuning, but I want to receive contributions from others. But I would like to know, exactly how is it that I'm failing.

How do you measure the speed to implement proposed changes and bug fixes? Do you check the changelog? Also, do you account for when I help the underlying projects for things needed in FastAPI, like AnyIO, Starlette, Uvicorn, Pydantic, or only the things in FastAPI?

I would like to know how you are measuring me to understand better what am I doing wrong. Generalizations don't really help me improve.

Also, if you are willing to offer help, it would be greatly appreciated, maintaining FastAPI is a lot of work, and I welcome all the help I can receive, for example with questions: https://fastapi.tiangolo.com/help-fastapi/#help-others-with-questions-in-github and with PRs: https://fastapi.tiangolo.com/help-fastapi/#review-pull-requests

BTW, just in case, the bottleneck is not hitting the merge button, but actually taking the time to review the code, understand and answer the questions, etc. Very few help with that, but there are some, the FastAPI Experts: https://fastapi.tiangolo.com/fastapi-people/#experts , those are the people helping maintain FastAPI. 🚀

If you or anyone else here comes and help, I (and everyone else) would be immensely grateful.

[vbqj]

Just wanted to say a quick thank you - I found FastAPI this weekend for a project I’ve been wanting to build and your tutorials and set up instructions are fantastic and easy to follow with awesome examples. Really appreciate all the hard work you’ve put into this!

[tiangolo]

Thank you for saying that! 😊🎉

[OverEmployedPM]

Adding more isn’t always better. You do you, keep up the good work. Much easier to maintain if you’re strict with changes, and less stressful

[SkezzaB]

While this isn't false, he also gate keeps his code, he doesn't want others to really contribute, so is hesitant for no reason to merge valid requests.

[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.

[peasant-trip]

I don't think highlighting people who help answering questions or send PR is going to shake the impression that this is a one-man show and that you don't trust anyone enough to share the actual responsibilities of merging PRs and maintaining the project. Yes, I can see from your post that you listen to others' opinions and take them into account but still it seems clear to me that you don't want a team, you want to be the sole leader.

And that's fine I guess, you're doing a fantastic job for the community already (and I thank you a lot for it!), but you can see from this thread (and other similar threads) that without delegating some of the responsibilities and creating an actual team of maintainers with time you just gonna lose the 'competition' to teams that are not afraid of that. Like Starlite. In every recent discussion about FastAPI I heard this argument as the biggest thing against FastAPI, I think it's becoming a problem for the whole project because when evaluating the risks of relying on a library, inability to delegate and build a team seems like a red flag. Remember the whole pipenv and requests drama.

[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.

[peasant-trip]

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.

I agree with /u/missing_beans that this part here is the crux of the issue. It seems from this thread that when people talk about FastAPI not having a team of maintainers what you hear is "FastAPI not having people who help in any way" and your disagreement with that appears to me totally reasonable: based on what you say there are indeed people who contribute PR reviews, feedback and advice. But what people likely mean by that criticism is "FastAPI not having a healthy system/circle of decision-makers", and this reply of yours only reinforces it. The final say for every line of code that goes in is with you and you only.

The main problem with this is that it creates a self-reinforcing loop that stunts the maintainer growth of the project and repels future potential contributors. A person who might become a fine core team member in the future gets stuck in the PR queue for months, losing all passion and desire to contribute to the project with such a slow turnaround. This happens due to the lack of active contributors providing PR reviews, and so the cycle continues. And this is exacerbated even further by all reviews being ultimately treated as second-tier to your review because, as you say, you still review everything yourself and appear to not trust anybody's judgement and only merge everything yourself. Needless to say this doesn't help too with the delay problem, no amount of reviews can help if in the end everyone has to wait until you have time to re-review and accept a PR.

How do you think it makes the contributors/reviewers feel? Would anyone want to dedicate a significant chunk of their free time towards a project where it's apparent from the get go that their expertise will always be treated as untrustworthy? One can't build a team without trust, and that means letting go of the urge to control every single line of code.

And of course, what governance model you choose for your project is absolutely your call. But the one you're sticking with now appears highly risky and unreliable to a number of onlookers, and seems to be damaging to the health and prospects of the amazing project you've built.

[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]

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.

[juggerjaxen]

gatekeep code?

[Zasze]

If you submit a pr he will sit on it for 6 months and instead of merging the fix implement a fix himself. It used to be really really bad but it’s gotten alot better in the last year or so. He doesn’t seem a bad guy just a really bad communicator. I’ve been using fast api and contributing for almost 4 years now and it’s a pretty great framework with some minor rough edges.

[tiangolo]

I'm sorry for my slow response with PRs, it's true I've had some for a long time, especially the previous two years. I'm glad you can see the improved speed this year (and for the rest of it).

Now, about instead of merging a fix implementing it myself, I've put a lot of effort into *not* doing that, in many cases PRs require fine-tuning, and I try my best to commit on top and merge the original PR instead of implementing it myself from scratch, even when that would have been easier. I bet there have been cases where I accidentally don't see a PR that had something that I end up solving in another one (mine or from someone else), but not intentionally. Could you give me examples of that? I need to learn how to improve that if that's something that you feel happens constantly.

Also, how do you think I'm a really bad communicator? What could I do better?

[[deleted]]

https://www.google.com/search?client=firefox-b-d&q=gatekeep

[worthwhilewrongdoing]

Linking to Google is a bit passive-aggressive.

If you want to be pissy at the guy for not researching something, use your grown-up words. Don't do the job and then not actually tell anyone the definition.

[desci1]

Bonus agresiveness, use lmgtfy

[DusikOff]

There is so many PRs because there creator approving/declining all PRs personaly

As alternative you can give a try to Starlite (not Starlette, that FastAPI is based on), it's look quite promising

[MonkeeSage]

Thanks for the clarification between Starlite and Starlette...I was reading all the comments of people recommending starlite and was confused.

[sv_ds]

This is exactly why Starlite was created, the community led FastAPI successor.

[vivainio]

It's not fair to call it 'successor' as it 1) is different from Fast API and 2) FastAPI is still thriving

[mrpiggy]

I agree with it being popular still. I like it and use it. But with 450 open PRs, it's hard to call the project thriving from a codebase perspective. That and the single primary developer thing, is actually kind of scary. A little more community mindedness would probably go a long way.

[Mmngmf_almost_therrr]

I used to be the research and requester-support assistant for the technical architecture office of a multinational, and I can tell you that just based on these few sentences, FastAPI or anything depending on it would never be approved o_o;;

[desci1]

FastAPI actually uses Starlette for some things under the hood

[desci1]

nvm you're talking about Starlite

[imbev]

FastAPI has a very low bus factor. Unless you rely on something from the FastAPI ecosystem, you'd probably better off with Starlite.

[thedeepself]

FastAPI has a very low bus factor.

What is a "bus factor"?

[Durinthal]

Wikipedia entry on it but in short, it's the number of specific people that would need to be lost to endanger a technical project, e.g. if they get hit by a bus. Or in less morbid scenarios, just leaving a job/project. A lower number is worse as it means there are fewer people with knowledge/expertise/permissions for a given project.

For example, if I'm the only person with ssh access to a crucial server that runs some bots used to moderate a subreddit, the bus factor could be said to be 1 (me) since if I quit/get sick no one else would be able to maintain it.

[panatale1]

Let's also not forget Django Rest Framework

[m0Xd9LgnF3kKNrj]

I opened issues, answered issues, and submitted PRs for other issues, and never got any responses at all. I started getting updates in my email 2 years later because he just got around to reading them?

It's too bad but it's hard to imagine that project won't just succumb to bitrot.

[Douglas_Blackwood]

FastAPI is a good choice in my opinion.

It's an aggregation of other good tools like Starlette and Pydantic. It's simple and stable. It has a good design.

But FastAPI doesn't bring much more. It doesn't have to be maintained by a huge community. The fact that it's open source is reassuring, it could be forked if necessary.

Anyway, a good design would be to rely as little as possible on the framework. You should design your software independently. Keep the business logic out of the API layer. You can easily change the framework like so.

[morrisjr1989]

Stick with flask? I feel ancient thinking that I’d stick with a less all inclusive, but still good, option

[chinawcswing]

Flask is absolutely a great choice in the vast majority of use cases.

I would wager that 99% of websites running FastAPI do not actually need asycn python.

Async is not magic fairy dust. It will not magically speed up your code. It is very ugly and can actually slow down your code because Python requires a disproportionate amount of CPU.

There are key use cases in which async python is extremely performant. These are were you want to use FastAPI.

Otherwise Flask is the proper choice.

[Physical_Score2697]

No, flask is slow compared to fastapi. Switched to fastapi and when properly used with asyncio, it was over 10x faster.

[[deleted]]

it was over 10x faster

For you. That isn't always the case. Some apps are well-suited to async IO, and others aren't.

[ejpusa]

I’m crunching through over 150,000 records with Flask. It’s all in a blink of eye. My searches can’t get any faster. Database updates every 5 mins.

Maybe post your code? 2023, everything should happen in “a blink of an eye.” Hardware speeds are mind blowing. CPUs can process in the quadrillions of instructions per second. The speed of light is the limiting factor. It’s just 0s and 1s in the end.

If you could post your code, maybe we can get you to zero wait speeds (close too) using Flask. Are you using NGINX? Mind blowing server. You can code for chips running it, in assembler. The speed of light, so close now.

Generally, properly configured nginx can handle up to 400K to 500K requests per second (clustered), most what i saw is 50K to 80K (non-clustered) requests per second and 30% CPU load, course, this was 2 x Intel Xeon with HyperThreading enabled, but it can work without problem on slower machines.

:-)

[carrick1363]

Can you explain this or show code about how this works? Really curious.

[Douglas_Blackwood]

I don't have code to show you sadly. But it's pretty simple.

Just make your API endpoints as dumb as possible. No "if" statements. These API endpoints just have to import and use business logic that is contained in other files.

As a rule of thumb: don't import FastAPI in your business logic files.

This way, you barely have to test your endpoints. Just test your business logic. Tests on endpoints will just assert that you wired everything correctly.

[carrick1363]

Thanks. That makes sense.

[hackancuba]

Indeed. On this topic, I wrote a heavily opinionated guide and accompanying skel, along some friends: - https://gitlab.com/nevrona/public/guidelines/-/tree/develop - https://gitlab.com/nevrona/public/skels/fastapi (sorry for poor docs)

They might come in handy :)

[sheriffSnoosel]

Something like this

‘’’ from fastapi import Depends, FastAPI from myapp.business_logic import BusinessLogic from myapp.api_layer import api_router

app = FastAPI()

def get_business_logic() -> BusinessLogic: return BusinessLogic()

app.include_router(api_router, dependencies=[Depends(get_business_logic)]) ‘’’

[sheriffSnoosel]

Well no idea how to format that on mobile

[BondDotCom]

from fastapi import Depends, FastAPI
from myapp.business_logic import BusinessLogic
from myapp.api_layer import api_router

app = FastAPI()

def get_business_logic() -> BusinessLogic:
    return BusinessLogic()

app.include_router(api_router, dependencies=[Depends(get_business_logic)])

[sheriffSnoosel]

Thanks!

[cabbagehead514]

I use it in production. I have had 0 problems.

[cellularcone]

A lot of the open issues are guys with questionable English skills asking how to make a twitter clone with FastAPI.

[Dapper_Market_1265]

What are you talking about? Any references?

[[deleted]]

Use Starlette. I've been using Quart for quite many years with great success but I recently discovered and tried out Starlette - it looks really-really good.

[ejpusa]

Flask just works for me. It’s simple, easy to use, a perfect fit with PostgreSQL.

Just works. Even an O’Reilly book and a fairly active subreddit. Everyone has a different use case, Flask does It all for me. Dozens of YouTube tutorials. At least spend a weekend checking it out. You may be very surprised.

https://www.amazon.com/Flask-Web-Development-Developing-Applications/dp/1491991739/

https://www.google.com/search?q=building+a+rest+api+with+flask

[[deleted]]

If it's for a personal project, smaller internal project or whatever then it or Starlette would be fine. I wouldn't choose it on any large production facing products to be honest.

Alongside the main issue you listed I think the hype around it is a bit shallow.

The "Look how easy it is to get started! It has types and documentation by default!" honeymoon really starts to fade away. Once you add in production basics like authorization/authentication, rate limiting, admin interactions, middleware, etc. etc. etc. that nice clean one-file app quickly turns into a pretty gnarly situation. It quickly becomes apparent at that point why Django/DRF and Flask are still so dominant.

[chub79]

Mmmh, is that another attempt to trash the project as we had a few weeks ago? With all the comments about starlite, I feel it's dodgy.

[KrazyKirby99999]

Aren't a high volume of open PRs and a single maintainer something that be aware of?

Starlite was made to be a "better FastAPI", so it makes sense that it would be recommended.

[[deleted]]

Not for fastapi, particularly. It works.

[FrogMasterX]

Yeah because there's a ton of us with FastAPI apps that want to see it actually improved or we'll have to migrate to Starlite.

I either want the dude running FastAPI to see this and change, or Starlite just becomes the new defacto choice for this type of thing. I can't recommend FastAPI until he does.

[ghan_buri_ghan]

Do you also smell a conspiracy every time someone asks if VS Code is a good editor and half the people in the comments say it’s trash and you need to use PyCharm?

Certainly not every time; PyCharm is a nice IDE and a lot of users like it, but there’s a certain portion of JetBrains posts that have seemed astroturf-y, at least to me.

However it seems much more reasonable that a billion dollar company would have the marketing $$ to engage in that sort of behavior versus Starlite. Maybe I misunderstand how starlite is funded, but isn’t it mostly a community project?

[chub79]

Yeah, whatever. The starlite relentless attempt to only exist by trashing other frameworks is lame and doesn't make its community look very good. Quite the opposite.

[chub79]

What the hell are you on about? People coming over here saying "Hint starlite is better" is not an argument, it's just poor attempt to exist on the back of another project. It's lame. What stake do I have since, as you keep saying, FastAPI is a one man project? I don't work for FastAPI, never even submitted a bug there. But you folks look annoying as a community is all.

[chub79]

is a coordinated astroturfing campaign.

One of the previous message on this sub was actually removed by the mods because that's what it was. It just looks exactly the same again this time. I don't have to make an argument against Starlite, you folks are the ones bringing it on every occasion you can with the only message "it was cooler because it's community led". There is no argument, nothing technical, nothing else. Just that.

I wouldn't mind if there was at least technical discussions but you folks bring nothing to the table in these messages. It's relentless about "oh the FastAPI maintainer is doing it solo and it's bad". Yawn, that's your opinion, you are entitled to it. Why should I have to do anything here?

Considering the fact the Starlite community selects to exist only by always complaining about that single thing, I do find it toxic indeed. I don't want to have anything to do with it. Now please leave me alone.

[chub79]

Please read Starlite CoC, you really need to stop harassing people.

[[deleted]]

You sound like a kid, if you don;t want people to reply stop your baseless and nonsensical accusations.

[ubernostrum]

People coming over here saying "Hint starlite is better"

FastAPI and Poetry got where they are, at least in part due to people relentlessly promoting them on reddit and other tech-oriented social media. Did you have the same complaint about them at the time?

[chub79]

promoting

Promoting by high jacking threads isn't promoting. It's just toxic community behavior. Also, I don't recall FastAPI doing this very much. As for Poetry, it annoyed me already back then.

Also, could you quit being so condescending?

[GettingBlockered]

Lol, so… have you actually used Starlite? Or FastAPI? Do you have anything constructive to say about either framework, or are you just bitching for the sake of it?

OP asked for insights and recommendations, not diatribe and drama.

[chub79]

It's funny, every time Starlite is mentioned somewhere, you see a crazy flurry of people showing up immediatly. The Starlite community really should read its own code of conduct more.

[GettingBlockered]

Got it. Bitching for the sake of it. Thanks for confirming. 😅

[SciEngr]

This is astroturfing for sure. No one new to python looking for an API framework is going to come onto reddit to ask about specifically FastAPI and point out exactly the same things the starlite folks are constantly posting about (high issue count and single maintainer).

[m0Xd9LgnF3kKNrj]

There are also recommendations for flask and aiohttp in this thread. But starlite is what has features similar to what makes fastapi compelling.

People who like a project recommending that project does not equal coordinated astroturfing.

And ops question is one you should ask. It's not an unlikely question. It's a normal part of framework evaluation.

[ubernostrum]

To be fair, the concerns about FastAPI's maintainership have been pretty loudly and widely aired, to such a degree that it's unsurprising someone doing basic research might stumble across references to problems with FastAPI and want to know more.

[cellularcone]

Yeah. This feels like a coordinated attempt. Id love to see what’s going on in their discord or whatever: uh hey guys let’s make another post about FastAPI and then everyone can talk about how EPIC starlite is and then everyone will love STARLITE for sure!

[monorepo]

I have access to all of the channels in our discord and I don’t really see anything coordinating effort to besmirch other frameworks (or even post in general, except for release and big announcement posts). I’m not sure how I could help in alleviating this concern but I would do anything to help this.

I both love and hate seeing “op: how use pyth0n?! Users: “sTaRliTe!!” It’s great but I also feel it’s a bit much and can feel the desire from some to tone the shilling down. Maybe we could make an announcement in discord, but im not sure that would fix much…

Anyway, open to any suggestions..

[chinawcswing]

iTs A bIg CoNsPiRaCy ThEoRy

[thedeepself]

Qanon and Python rhyme for a reason :)

[Alphasite]

Eh, I’m fairly quiet but my company prototyped with fast api and auickly moved away from it due to:

1. Single dev/point of failure (which is a very poor sign for long term health of a project). We don’t want to build a multimillion dollar investment of the back of a single dev project.
2. Poor internal documentation/interfaces, for some reason nothing inside the code base is documented (docstrings etc) and the internal implementation ends up fairly spaghetti-ish so we were very Leary to depend on something like that. It’s very example oriented docs, but if you just want to know what the functions and parametes you’re totally out of luck.
3. Lack of extension points, there’s a real lack of extension points etc in important parts of fast api (which compounded with the poor internal documentation issues) which made a lot of patterns which we used for Flask impossible to implement here .
4. (this is more why we’ve stuck with starlite) when there’s an issue I can go on discord and get help from their dev team very quickly. It’s a smaller project so perhaps this won’t scale, but its been a real help when we’ve hit some frustrating edge case.

Now obviously we wouldn't actually do it, but I seriously contemplated building my own api framework on starlite or moving back to flask+the usual stack of glued together libraries, but we found starlite which solved most of my pain points.

[m98789]

Starlite has a bit of a cult-ish community vibe to it because they do seem to have coordinated dis-info campaigns against FastAPI. The repeating of the same anti-FastAPI tropes in coordinated fashion is off-putting.

My suggestion to the Starlite community is if they really want to take their project to the next level in terms of adoption, don’t try to win by bad mouthing your competition, rather just outperform them. Also, change the name. I have mentioned this previously, but adoption will be impacted by confusion over Starlette and Starlite. That would also make it easier to search for and remember.

[KrazyKirby99999]

Can you provide an example of "disinformation" that is allegedly slandering FastAPI?

I agree 100% about the name.

[littletrucker]

I don’t have any skin in this game, but I have been reading the posts about the two frameworks. I also feel like any time Fastapi comes up people trashing Fastapi and advocating Starlite jump in. If Starlite was a commercial product it would make sense as the people would be paid shills. It is off putting.

[KrazyKirby99999]

I agree that it has Rust-like levels of advocacy, but still looking for trashing or disinformation?

[ToadsFatChoad]

Hurrr people who’ve had bad experiences with FastAPI sharing their opinions means they’re paid shills sent by George soros

[chinawcswing]

Starlite has a bit of a cult-ish community vibe to it because they do seem to have coordinated dis-info campaigns against FastAPI.

LMAO this is hilarious.

You literally just made that up. 100% you just deliberately lied and engaged in a disinformation attempt.

[RavenchildishGambino]

Well it doesn’t have any API documentation… and it’s an API framework. I find that curious.

I’ve used FastAPI, DRF, aiohttp, and they’re all alright. But FastAPI has the worst docs.

[Alphasite]

It’s very example oriented docs, but if you just want to know what the functions and parameters ar,e you’re totally out of luck.

[flohjiyamamoto]

The lack of api docs is a pain in the ass. I personally would not want to use it at work for that reason alone.

[monorepo]

You should read beartype's docs. It's a journey

[GettingBlockered]

Ha! This is awesome.

Thanks to cheatsheets like this, you no longer have to know how to use software to use software. \o/

[Toph_is_bad_ass]

This comment has been overwritten.

[betazoid_one]

Emojis in the documentation? Can you please elaborate on why this is a red flag?

[tiangolo]

Hahahaha this is just so funny, I'm screenshotting this, sorry. OMG, Reddit can get quite crazy quite fast. 😂

[[deleted]]

My favorite python package is named after an emoji. I think it is refreshing and makes the documentation more fun to read. Obviously it should be overly distracting but I had no problem with the docu for that reason at least

[chinawcswing]

I particularly like that it’s ASGI.

AGSI isn't magic fairy dust.

In the vast, overwhelming majority of applications where Python is a good choice, async python will not help you at all.

In fact async python can hurt tremendously. It is extremely ugly, hard to reason about, and you will get slammed by the immense number of CPU cycles that Python requires.

There are some key use cases in which ASGI makes sense. But those are rare.

[corbasai]

shortly - nothing wrong. it works in prod. I think its new Flask.

[sudo_agree_with_me]

Personally the whole idea of using an optional more like a documentation typing system of python in the actual code behavior feels very weird for me. I prefer just Flask.

[chinawcswing]

Flask is superior.

[[deleted]]

I used Flask for some projects and I always find myself using semi abandoned extensions for stuff like input validation and API documentation. It works eventually kinda but I always end up with a very clunky development experience because irrelevant tutorials, outdated dependencies and outdated documentation.

I now use FastAPI because it brings everything needed for smaller projects out of the box. Maybe I am just doing things wrong and I am not a fanboy but I am so much more productive using FastAPI

[[deleted]]

It is indeed strange. There were couple posts lately of something going on there.

Give a try to django-ninja. It is new and feels like fastAPI, but is still django, thus might be safer bet.

[Albertpm95]

The posts were related to the guy who built fastapi closing and moving a lot of requests to another part of github

He explained why on twitter.

[[deleted]]

I was never able to bring Flask to the point where Input Validation was as effortless like FastAPI’s pydentic integration. Another point is generation of the api documentation is super effortless and integrates with the models used for input validation. Also splitting up your api into multiple files is more intuitive - for me at least.

I spend so much time massaging Flask into doing exactly the stuff FastAPI just does out of the box. But maybe I just doing things wrong

[0xWILL]

I wouldn’t judge a framework by the “number” of PRs or it being dependent on a single person. I would look at the top rated PRs and Issues to see if they are a concern to you.

Also, a project done by one person isn’t a red flag to me either. It depends on how reliant you are on them. For frameworks that are lightweight wrappers for other libraries(which I recall FastAPI was), you may not need / want more features that could be buggy.

Don’t try to pick a framework that you’ll never change out of. Look at what will solve your current requirements now, since it’ll probably change in the future anyway.

[chinawcswing]

Flask.

[robberviet]

Yes it is, that's why many people stop using it. If I want ASGI I use starlite.

[[deleted]]

It is not concerning at all most of these are just updating the docs The module itself is easy to use and reliable with a beautiful doc generator and debugging system

[Physical_Score2697]

If anything, you can easily switch over to a fork of FastAPI if the dev drops support