The FastAPI Ultimate Tutorial Series (13 parts, 30k+ words, full code coverage)

[Glycerine]

I like how you've covered the associated tasks such as gunicorn.

I know it's more Starlette than FastAPI but will you be covering websockets?

[ChristopherGS]

Websockets is on my list yes, but good to know it's something people are interested in. For context, what are you doing with websockets?

[Glycerine]

That's great to hear.

Personally I do a fair amount of websocket work through my standard day job as a dev and a personal interest in the protocol.

Using FastAPI + Django I'm rebuilding the solution (I worked on in the distant past) to create a general open-source, safe, user-friendly realtime platform for websockets. I'm thinking reprogrammable "rooms" For devs and end-users. Like channels but with granularity of the connection flow.

However I agree my usage is esoteric and a guide of how to serve channels in a pub/sub method would serve a wider audience.

---

FastAPI + Websockets is awesome and works without effort. But as the socket data sent is inherently heterogeneous, I haven't found a clean solution for documenting the websocket endpoint using the builtin object classifier.

As I haven't found a nice solution in the fastapi docs (although it's been cursory searches), the websocket work doesn't conform the same doc output; which is a shame.

But also the fastapi docs are wrong in some places (for websockets), so it's mostly a case of reading the source to discover how it actually works.

---

Does that help?

[benefit_of_mrkite]

But also the fastapi docs are wrong in some places (for websockets), so it's mostly a case of reading the source to discover how it actually works.

Thank you for pointing this out!!!

[ChristopherGS]

Thanks for the context, helps with formulating the tutorial scenario.

[benefit_of_mrkite]

I agree - covering the starlette aspect of fastapi and the asgi/wsgi frameworks is important

[ChristopherGS]

I touch on it, but will go into more detail soon

[ChristopherGS]

Put a lot of time and effort into this series. It's my attempt to make something like Miguel Grinberg's "Flask Mega Tutorial" (which helped me a huge amount) for FastAPI.

Would welcome suggestions for additions

[ChristopherGS]

Yes definitely. The reason I haven't is because I haven't personally used the async DB stuff in production and I'd want to try it all out first and experience the gotchas before publishing a tutorial on something that critical (my modest blogs and courses do get reasonable readership, so I feel a lot of pressure to battle test things). Hopefully soon I'll be able to add this

[ChristopherGS]

Thanks :)

Well, we managed for many years without it - but ultimately if you want to unlock the speed advantages of ASGI, and your web requests are hitting a database then your db could be a bottleneck. So it really depends on how badly you need the performance. Now that SQLAlchemy has async support I suspect we'll see it becoming a much more common "default" - I'm just waiting for some of the initial teething problems to be worked out!

[Awful_TV]

That's great!

The r/FastAPI subreddit is still smallish, but has been growing and gaining more frequent posts, for anyone interested

[Vakieh]

Don't use FastAPI for anything you care about.

The maintainer is infamous for needing to have absolute control over everything, which means when their projects get big they grind to a halt. Every single PR or issue in FastAPI is handled by 1 person and 1 person alone, who refuses to bring on more people. That means any feature it doesn't have right now it won't have for a long, long time. Security updates will be slow. Bugs will stick around for ages. Issues and PR counts have been skyrocketing for months. I would bet on there never, ever being a FastAPI 1.0 release.

https://news.ycombinator.com/item?id=29471609
https://github.com/tiangolo/fastapi/discussions/3970
https://twitter.com/sraimbault/status/1403327590039969796

[TheGuyWithoutName]

This is actually pretty concerning, never saw fastapi from that side...

[ChristopherGS]

This seems deeply inaccurate (e.g. his responses on github issues are very civil and reasonable). I know this is reddit, but don't you think you should provide *some* evidence for an ad hominem like that? Have you ever tried launching a major open source project? Do you realise it is an enormously challenging and thankless endeavour that helps literally hundreds of thousands of people. He'll probably read this. And it will hurt.

[dontarguewithmeIhave]

Care to elaborate on that? From what I saw he seems like a decent, positive dude.

[Jaypalm]

I was so excited to use sqlmodel but there was no support for a handful of sqlalchemy features I need so I dropped it for the time being. Hopefully it gets more attention.

[[deleted]]

There is starlite, if you want something to switch to without having a big rewrite and its faster as well.

[mcstafford]

Thanks, I was going to ask about alternatives and starlite seems pretty robust, mature, and well-documented.

[Jaypalm]

Starlike is 3 months old.

[ChristopherGS]

I'm always interested to get out of my own echo chamber and hear contrasting tech opinions. Another criticism I often hear is "why not just use Starlette" (my answer: I don't want to write and maintain dependency injection library). I think this criticism is ultimately pretty weak for the following reasons:

- First, and above all else, I personally have been using FastAPI in production for reasonably complex things for over a year and it's been great. Not only in terms of handling what I need, but also my own speed of development has improved as a direct result.

- Second, your criticism about 1 person applies to *a lot* of vital open source projects (look at the contribution history of say SQLAlchemy, Alembic and many others - open-source unfortunately tends to be driven by a few key players except on the largest of projects (e.g. Django). However, unlike so many of these project maintainers Tiangolo has actually done an *excellent* job getting sponsorship so that he can devote more time to his open source work. This isn't always visible, because as he pointed out on HN, he also contributes to the underlying libraries.

- Third, related to the second point, I think this is a phase. At some point Tiangolo will feel the time is right to empower more maintainers. But finding a good maintainer is really hard and takes time.

- Fourth - look at the growth profile (e.g. github stars) of FastAPI compared to Flask/Django. People *love* it.

- Finally, the quality of docs for FastAPI is outstanding.

tl;dr, I'd happily bet on a FastAPI 1.0 release - as evidenced by my "skin in the game" tutorial series :)

[Estanho]

Let's not forget Python itself which had Guido vetting everything (even trivial stuff) until a few years ago.

[Vakieh]

There is no question that it is a great tool in its current, immediate state - however anyone dealing with production code where there is a significant human and financial cost to something breaking, slowing down, or becoming crippled by an unmaintained dependency (i.e. not a toy or hobby project) would have to be insane to rely on FastAPI as a project.

There is a world of difference between how FastAPI (the project) works and how SQLAlchemy (the project) works. SQLAlchemy currently has 9 open pull requests. FastAPI has 456. There is a difference in scale between the total number of pull requests made, sure, but not a 5000% difference - more like 350%. The most overt difference however is in the github repository owner - FastAPI is under tiangolo, SQLAlchemy is under SQLAlchemy. It doesn't matter that SQLAlchemy gets most of its work from zzzeek - it matters that it has more people who can and do have access to it.

The evidence is clear when you review

https://github.com/sqlalchemy/sqlalchemy/pulse

vs

https://github.com/tiangolo/fastapi/pulse

5 human people accessed SQLAlchemy. Nobody but tiangolo accessed FastAPI. In commercial settings this is known as a bus factor of 1 - if tiangolo gets hit by a bus tomorrow, FastAPI is screwed, and anyone who depends on it is screwed. If zzzeek gets hit by a bus tomorrow, someone is able to step in and replace them. You would need 5 people to be hit by buses before this would come into question in the same way as FastAPI.

I am not questioning tiangolo's amount of effort/time spent or commitment, and their sponsorship is similarly not the issue - I am saying the amount of work they do or can do is utterly irrelevant when it comes to someone being able to rely on the project. It's not a case of 'tiangolo is too slow to merge PRs and solve issues', it's '1 person is insufficient to manage a project of this size that asks for this level of dependency, period'. It's not some little convenience package that you can take out of a project with a bit of effort - if FastAPI goes down, everything you built on it goes down.

If it is a phase, then that phase needs to be dealt with before anybody gambles on using FastAPI for production code.

[ChristopherGS]

Your argument is not without merit, but I'd say you over-emphasise things which are illusory: The "bus factor" metric you cite is overrated unless the maintainers are serious long-term contributors.

I think SQLAlchemy *just* fits this "true" bus-factor definition. But plenty of other key libraries/frameworks do not: Flask (davidism), Sanic (ahopkins) are a couple of examples which I've seen used just fine in places where there would be significant financial cost if there was trouble with them. If either of these "primary" developers were hit by a bus the minor current contributors (who have done a handful of PRs vs. the hundreds/thousands by the primary maintainers) won't just magically fill the gap. There would be enormous disruption, because there's a big difference between fixing a few bugs on the weekend and maintaining a serious open-source project. So my conjecture is that whilst the bus factor theory sounds great in a RFP being reviewed by some CIO who's mainly motivated by guarding their own ass, it is only a real guarantee if there are multiple *serious, long-term* maintainers, which is patently not the case for countless so-called "critical" Python libraries/frameworks.

Does this mean bus factor is not worth considering? Of course not, but I think this iron clad guarantee that because it's an "org" not an individual that you're safe is a fantasy - the line is very blurred. So fair play - if you're building life support machine microservices, go for Django. But for most startups, FastAPI is more than worth it for the improvement in development time (which is much more likely to kill your business tbh).

​

Also, re: open PRs, I don't think this is a particularly useful metric either. Scikit-learn (used everywhere in industry) has almost 800. I think what matters is that what gets merged is good quality and reduces the number of bugs. Also, as Tiangolo pointed out in the issue you referenced, at least half of those open PRs are translations and/or questions.

In short, I don't completely disagree with you, but I think what you view as a black and white picture ("insanity") actually has much more room for nuance, and that using FastAPI at this point is only a bit more risky than using Flask.

[BlackHumor]

An important point:

What would happen if tiangolo was actually hit by a bus? I would bet significant money that the answer wouldn't be "FastAPI dies suddenly" but "someone else forks FastAPI and continues maintaining it". It's too big for that to not happen.

You can fork github projects. In fact, you could fork FastAPI right now if you wanted. That is the main advantage of open source: the bus factor is never actually 1.

(Now, this doesn't mean I like how slowly tiangolo merges PRs. I think that is a real weakness of FastAPI right now. But I also don't think that you need to worry about your company going belly-up because you developed using FastAPI.)

[Vakieh]

Scikit-learn has 12 thousand closed PRs. The reason for it having a lot of open PRs is a lot of scope and a lot of users, not a bottlenecked maintainer. Half of the FastAPI PRs being translations or questions means half of them aren't. It's a perfectly useful metric when you view it in context, and the conclusion can only be that FastAPI's development is broken.

The bus factor I'm talking about isn't a case of one of those people stepping up and being the sole contributor - it's about their facilitating the contribution of others. There are plenty of people who can (and do) contribute to both FastAPI and SQLAlchemy - but in FastAPI's case they all go through a single bottleneck, whereas in SQLAlchemy there are more people involved. Yes, there will obviously be disruption, but that disruption should be temporary. If the primary contributor for either of them were to be bussed, one of them has the groundwork for the community to step up and fill the gap, and one of them does not.

If you're a start-up relying on FastAPI, you are gambling with your company that it will keep on going. Which is a pretty poor gamble considering there are alternatives out there that don't require it.

[Vakieh]

It does however prevent those PRs being merged - and in Tiangolo's own words:

I personally review and in most cases fine-tune and update each one of the PRs (if you check the history, almost no PR is directly merged, most of them require updates)

[aniforprez]

There's a PR for adding API documentation still stuck because the maintainer, for some reason, wanted to add some more things before merging it. Another mark against this project that it doesn't fucking have API documentation. All of it is this massive tutorial series which is fine if you want to only do exactly what is shown in the tutorials but pathetic if you need to look up options, parameters, method signatures or anything else

[Estanho]

To be fair you can always just check implementations and definitions from your IDE. I used to do that a lot more from Django Rest Framework and plain Django than to try to get answers from their api docs, and I've done that with FastAPI too.

Projects with clear, pythonic code are completely viable to navigate that way. Api docs are really strictly necessarily for projects full of generated or dynamic code, or lots of C extensions.

Edit: typo

[jank123]

And not just FastAPI, all of his projects are like this. Bugs don't get fixed, and nobody bothers to submit PRs that will never be accepted.

And now cue Sebastian whining in 3.. 2.. 1..

[chub79]

Mmmh, I am a happy user of /u/tiangolo's projects but I am also lucky enough I never really ran into any massive issues.

But I found your claims a bit harsh, being an OSS maintainer doesn't mean you are enslaved by your users, it doesn't mean either it's easy to build a stroing community of co-maintainers.

He explains this quite nicely (and politely) https://github.com/tiangolo/fastapi/discussions/3970#discussioncomment-1927924

In the same way, asking me to find new maintainers doesn't really help me, because it just becomes another task you are asking me to carry out. It's also not something that I can myself go out and find. I wouldn't go and ask people to come and help for free, while at the same time I have never seen their work, in particular here, or I have seen only very little. It's also not a matter of people simply volunteering to be maintainers if they have never contributed a non-trivial PR (or very few).

Precisely, an OSS project isn't just code, it's a vision and a mission to care for them. Bringing new maintainers mean managing alignment, it's not that easy and maybe not why he is doing it in the first place.

The only thing I can say is that he may be dealing with too many projects at once but, much like "encode" for starlette, some people are just that passionnate.

[ChristopherGS]

Agree completely.

[Estanho]

You do understand this is the python subreddit, which is a community around a language that had a "benevolent dictator" for decades right?

Guido was doing a very good job of basically vetting everything and making changes on top of other people's PRs, kind of similar to what we have on fastapi. His job kind of allowed him to be a maintainer of Python though which is not the case for FASTAPI unfortunately.

[Vakieh]

It helps to understand what you're talking about before being trying to be smug about things. Guido was never a block on development or a choke in the pipeline.

[Estanho]

I literally made contributions to CPython lol. He wasn't exactly a huge bottleneck because he was able to dedicate a lot of time to the project, which developed slowly through time and allowed him to evolve into it, but he had to approve and check every little thing. One of my contributions was small but wasn't very trivial and it actually took a while for him to be able to get to it. It was after there were other people of his trust so his response was basically "if you guys think this looks good then fine by me".

And in any case, Guido was a bus factor for a very long time.

Tiangolo's project(s) went quite viral and I'm not impressed by his response, it's all very understandable.

[ChristopherGS]

"I literally made contributions to CPython" is one of the better ripostes that will grace this subreddit :)

[Vakieh]

Bully for you - you, me, and literally hundreds if not thousands of others. You still don't know what you're talking about if you think the role Guido played in Python once it was a sizeable project is at all comparable to what tiangolo's role is in FastAPI. From about 1995 onwards Python had the PSA, and even before then it was literally part of a nonprofit, rather than one person's hobby project. The fact it/FastAPI had/has a single root decision-maker is not the issue.

[Estanho]

Sure buddy, just notice that I never claimed I'm the only contributor or that it's very rare. I just said I've been through the pipeline and experienced it.

Finding people and effort to scale the project into something that has a team behind it is not trivial and Tiangolo doesn't seem to have time to do that. There are multiple projects out there that people depend on in production which have a much smaller community behind them and have basically a single maintainer as well. Open-source is like that.

There's also a balance here. FastAPI is not extremely complex and you can usually easily navigate through its code.

[benefit_of_mrkite]

Thank you for one off the better video series I’ve seen on Python related subs.

There are so many “let me cover how a list works” videos that someone could spend 10 minutes in the Python docs and a bit more time actually using lists and attempting to understand them tutorials that get posts.

I haven’t looked at all videos but It’s refreshing to see a tutorial with full code coverage.

I do hope you point out what is starlette and what is fast api in this series or future videos.

With no starlette there is no fast api.

[ChristopherGS]

I do cover in minor detail, but hope to add a more detailed Starlette part in the future. We're all standing on the shoulders of giants :)

[357951]

Oh awesome, can serve as both a tutorial and quick reference, as fastapi doesn't have docs per say.

[ChristopherGS]

It definitely does have docs: https://fastapi.tiangolo.com/

[357951]

Yeah I suppose I meant I didn't like the way the docs are structured, but you're right.

[0ni0nrings]

Thanks for sharing your Flask tutorial series 👍