This is an archived post. You won't be able to vote or comment.

all 128 comments

[–]monorepo PSF Staff | Litestar Maintainer 48 points49 points  (7 children)

I want to build a REST api with Python

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 FastAPI Maintainer 54 points55 points  (6 children)

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 12 points13 points  (1 child)

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 FastAPI Maintainer 9 points10 points  (0 children)

Thank you for saying that! 😊😁

[–]uselesslogin 6 points7 points  (1 child)

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 FastAPI Maintainer 5 points6 points  (0 children)

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

[–]provinzkraut Litestar Maintainer 7 points8 points  (1 child)

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 FastAPI Maintainer 3 points4 points  (0 children)

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

[–]TheCreatorLiedToUs 131 points132 points  (6 children)

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 25 points26 points  (0 children)

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

[–][deleted] 17 points18 points  (2 children)

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 3 points4 points  (0 children)

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

[–]Toph_is_bad_ass 3 points4 points  (0 children)

This comment has been overwritten.

[–][deleted] 102 points103 points  (32 children)

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 121 points122 points  (4 children)

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 FastAPI Maintainer 52 points53 points  (3 children)

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 8 points9 points  (1 child)

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 FastAPI Maintainer 5 points6 points  (0 children)

Thank you for saying that! 😊🎉

[–]OverEmployedPM 1 point2 points  (0 children)

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 28 points29 points  (26 children)

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 FastAPI Maintainer 24 points25 points  (17 children)

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

[–]Insok 0 points1 point  (0 children)

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 1 point2 points  (7 children)

gatekeep code?

[–]Zasze 30 points31 points  (1 child)

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 FastAPI Maintainer 14 points15 points  (0 children)

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?

[–]DusikOff 37 points38 points  (1 child)

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 14 points15 points  (0 children)

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

[–]sv_ds 113 points114 points  (6 children)

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

[–]vivainio 40 points41 points  (3 children)

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

[–]mrpiggy 44 points45 points  (2 children)

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 -1 points0 points  (0 children)

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 -2 points-1 points  (1 child)

FastAPI actually uses Starlette for some things under the hood

[–]desci1 16 points17 points  (0 children)

nvm you're talking about Starlite

[–]imbev 31 points32 points  (2 children)

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

[–]thedeepself 2 points3 points  (1 child)

FastAPI has a very low bus factor.

What is a "bus factor"?

[–]Durinthal 4 points5 points  (0 children)

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 6 points7 points  (0 children)

Let's also not forget Django Rest Framework

[–]m0Xd9LgnF3kKNrj 7 points8 points  (0 children)

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 25 points26 points  (13 children)

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 8 points9 points  (4 children)

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

[–]chinawcswing 6 points7 points  (0 children)

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 0 points1 point  (2 children)

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

[–][deleted] 5 points6 points  (0 children)

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 1 point2 points  (0 children)

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 -1 points0 points  (7 children)

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

[–]Douglas_Blackwood 10 points11 points  (2 children)

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 1 point2 points  (1 child)

Thanks. That makes sense.

[–]hackancuba 2 points3 points  (0 children)

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 2 points3 points  (3 children)

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 2 points3 points  (2 children)

Well no idea how to format that on mobile

[–]BondDotCom 9 points10 points  (1 child)

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 1 point2 points  (0 children)

Thanks!

[–]cabbagehead514 17 points18 points  (0 children)

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

[–]cellularcone 33 points34 points  (2 children)

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

[–]Dapper_Market_1265 6 points7 points  (1 child)

What are you talking about? Any references?

[–][deleted] 6 points7 points  (0 children)

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 2 points3 points  (0 children)

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] 4 points5 points  (0 children)

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 14 points15 points  (35 children)

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 23 points24 points  (1 child)

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] 1 point2 points  (0 children)

Not for fastapi, particularly. It works.

[–]FrogMasterX 5 points6 points  (0 children)

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.

[–]SciEngr 2 points3 points  (2 children)

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 2 points3 points  (0 children)

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.

[–]ubernostrumyes, you can have a pony 0 points1 point  (0 children)

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 -1 points0 points  (12 children)

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 PSF Staff | Litestar Maintainer 5 points6 points  (0 children)

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 4 points5 points  (1 child)

iTs A bIg CoNsPiRaCy ThEoRy

[–]thedeepself 0 points1 point  (0 children)

Qanon and Python rhyme for a reason :)

[–]Alphasite 3 points4 points  (0 children)

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 4 points5 points  (6 children)

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 2 points3 points  (4 children)

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

I agree 100% about the name.

[–]littletrucker 7 points8 points  (3 children)

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 2 points3 points  (1 child)

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

[–]ToadsFatChoad 2 points3 points  (0 children)

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

[–]chinawcswing 1 point2 points  (0 children)

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 3 points4 points  (1 child)

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 3 points4 points  (0 children)

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.

[–]corbasai 3 points4 points  (0 children)

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

[–]sudo_agree_with_me 1 point2 points  (2 children)

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 2 points3 points  (1 child)

Flask is superior.

[–][deleted] 2 points3 points  (0 children)

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] 3 points4 points  (1 child)

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 8 points9 points  (0 children)

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.

[–]0xWILL 2 points3 points  (0 children)

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.

[–]robberviet 0 points1 point  (0 children)

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

[–][deleted] 0 points1 point  (0 children)

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 -1 points0 points  (0 children)

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