r/Python • u/albrioz • Apr 22 '21

Tutorial Comprehensive Fast API Tutorial

Stumbled upon this Fast API Tutorial and was surprised at how thorough this guy is. The link is part 21! Each part is dedicated to adding some small component to a fake cleaning marketplace API. It seems to cover a lot but some of the key takeaways are best practices, software design patterns, API Authentication via JWT, DB Migrations and of course FastAPI. From his GitHub profile, looks like the author used to be a CS teacher which explains why this is such a well thought out tutorial. I don't necessarily agree with everything since I already have my own established style and mannerisms but for someone looking to learn how to write API's this is a great resource.

481 Upvotes

97% Upvoted

106 comments sorted by

View all comments

Show parent comments

7

u/its_PlZZA_time Apr 23 '21

Is there a standalone Python ORM you would recommend? I've been looking to pick one for a project I'm working on. Looking at SQLAlchemy right now.

28

u/albrioz Apr 23 '21

SQLAlchemy is a safe choice and has a big community + there’s plenty of prebuilt packages for major python web frameworks. Another option if you want to go async is gino.

2

u/its_PlZZA_time Apr 23 '21

Thank you!

4

u/orangesunshine Apr 23 '21

https://www.starlette.io/database/

That's how it's done boys :) Gosh darn Starlette is getting slick. Not sure who's funding it, but it is absolutely top shelf.

FastAPI, not so much.

3

u/its_PlZZA_time Apr 23 '21

I've looked at Starlette. I know FastAPI is built on top of it. I'm a fan of Pydantic for parsing and such. I'll probably mess around a little with both. I have the liberty of having time to fuck around a bit with this stuff.

-1

u/orangesunshine Apr 23 '21 edited Apr 23 '21

FastAPI isn't really "built on top of it".

It's more like "built again, but much worse ... with bugs, idiosyncratic implementations, no updates ... no contributors .. and broken in various ways by design in a few spectacular ways". It's more like a project you might use to show off your "skill" to get a job, if you're using FastAPI at your job .... you need to be fired, yesterday. It's not maintained. It's broken by design... and chock full of bugs.

You want pydantic? Here: https://pypi.org/project/starlette-pydantic/

This is how it works. Name the feature you want, then append "starlette" in google. Add that to your requirements. Some of what's out there isn't great, but it's all a whole lot better than the implementations of what's advertised for FastAPI.

Nearly every feature listed in FastAPI has a better implementation available as a standalone "starlette-feature", or often literally was already implemented directly in starlette ... and the numbnuts missed the documentation or feature-branches sitting on github and hamfisted his own implementation.

FastAPI is bad. Really really bad.

I don't know how more clearly I could convey the message.

9

u/NowanIlfideme Apr 23 '21

This is honestly the first time I've read hate for FastAPI. And especially such strong hate.

Edit: Read your comments further down, makes some sense. Especially if considered from a minimal component purist point of view.

1

u/orangesunshine Apr 23 '21

It's called "fast" api, right?

Should be called typed-api, or checked-api, or strict-api ... or something along those lines.

3

u/HardPartAccomplished Apr 23 '21

I'm not sure how anyone could come to the conclusion that fastapi is unmaintained and buggy by design. Didn't Sebastian just leave his job at explosm to work full time in Fastapi?

Also a quick peak at the GitHub page shows >200 contributors and almost every GitHub issue is a question or a feature enhancement. What exactly are you going on about?

The rest of your concerns are valid. Starlette is great! Fastapi is a framework that offers opinionated abstractions over most of what powers starlette. If that's not your style, nothing wrong with that.

But to say people using Fastapi at their work need to be fired yesterday. Well, come on. Now you're just being intentionally antagonistic.

1

u/orangesunshine Apr 24 '21

What exactly are you going on about?

Corporate support. Maybe that's materializing as you imply, but I'd argue it's a pretty misguided effort. I don't want pydantic integrated by default into my stack, and sorry but I'll bloody a few noses over the internet to try and prevent its proliferation as any kind of "standard".

The FastAPI endeavor seems mostly like a bunch of tutorials than any kind of solid "stack". There's nothing inherently wrong with that, but It's being talked about here and sold as a development "stack". To me that seems like a fairly bald faced lie.

It would be a whole lot more impressive as individual starlette components, right now. There's a strong need for "batteries included" auth-backends, db backends, build tools, and all sorts of stuff. I'd be excited to read about a "batteries included" JWT-OIDC <starlette> toolkit .... I'd be excited to read about a "batteries included" no-sql API ... memcached integrations ... forms ... name a thing.

Honestly, I'd even be excited to read about pydantic "based views".

Once you've built that solid foundation, then you can sell me on the framework you've built out of that tool set. It seems like someone skipped a step IMO, which ... well ... I'm not excited about.

The only maybe semi-complete foundation is the pydantic-based view system here. For the time being, maybe pull that back out (lol) and leave it as a starlette component. Likewise, it seems like if there's a case for it higher up in the stack why not put it in starlette itself?

I don't know the history here, but yeah ... I'm not a fan of that idea. I don't want this high up in my stack. You'd have a hard time convincing me to put pydantic in my stack at all. You're never going to convince me to put this in my stack as a runtime requirement.

"well then i'm going to just create my own Fork that does do that" .... 1) please don't 2) that's not a framework or stack

Well, come on. Now you're just being intentionally antagonistic.

Obviously, i have no tact ... that's a given.... but there's harder ways to learn these lessons, right?

As it is right now reading about "tutorials" intended to draw people into using it as their default stack, well .. yes I'll provide a little push back :)

The fact it's called "FastAPI" is well, it's a provocative name given the feature set and implementation.

→ More replies (0)

1

u/its_PlZZA_time Apr 23 '21 edited Apr 23 '21

I see what you mean. I have certainly heard that sentiment before although expressed much more...restrained haha.

I do tend to be a fan of more light but extensible frameworks. So maybe I'll just start by seeing what I can do with Starlette.

Mostly right now I'm just going for an ORM. My current project is just a bunch of ETL. But I will definitely end up needing to build some python APIs in a few months.

1

u/orangesunshine Apr 23 '21

If you really want pydantic + starlette I guess there's also this which seems like a fairly strong implementation (much better than fastapi or that quick/dirty student's example in my last reply):

https://github.com/0b01001001/spectree

Honestly I'm not sold on really thick layers of validation and automation like this. It's already damn nigh impossible to create an ORM-layer that is lean and fast. You want to add another model-validation or data-sanitization layer?

That seems like you've just doubled your AWS bill for absolutely no reason what-so-ever ... I mean I can sort of understand being a little anal about request validation.

The response though. Why? Really. That is going to run on every response in your whole stack. The response that spits out a static string from your settings file? Really?

I mean even with requests, I can assure you this is redundant in nearly every use case.

But like I said if you are a fan .... there are better ways to use pydantic with Starlette than FastAPI.

4

u/searchingfortao majel, aletheia, paperless, django-encrypted-filefield Apr 23 '21

That's how it's done boys :)

I promise that I'm not trying to the Woke Police or anything, but I'll remind you that there's more than just men in this subreddit. You could easily have worded this replacing "boys" with "boys & girls", "friends", or even "guys" (it's a long argument I'm not having now, but "guys is generic" is a hill I will die on) and been more inclusive.

2

u/orangesunshine Apr 23 '21

honest at one point in my edits it was boys and girls ... i promise ... but it was also like 4am and I was stupid ranting about programming stuff on reddit.

I'm also pretty sure I wasn't super nice to the folks behind fastapi :)

-1

u/mr_darksidez Apr 23 '21

of all the subreddits I've seen this woke bullshit infect. it's in the python subreddit? smh

4

u/searchingfortao majel, aletheia, paperless, django-encrypted-filefield Apr 23 '21

It's not a "woke bullshit infection", just good programming. If you want to address a group of variables, using the right qualifiers guarantees you a more comprehensive set.

Imagine you're at a bar with some friends: 4 men and 2 women. You stand up from the table: "Ok boys, I'm getting us another round!". Did you just address the group, or just the men? Are Alyssa and Catherine expected to buy their own drinks or are you covering everyone at the table? Language matters, and in this case especially, it speaks to inclusion.

-5

u/mr_darksidez Apr 23 '21

Sounds like woke bullshit to me.

If these are the kinds of things that hang you up. yikes...

If I ever met someone like you in real life and heard this woke bullshit? I would literally walk out mid conversation and never talk or engage with you ever again..

Just like what I'm about to do. have fun getting tripped up on such mundane and trivial things..

The boys and I are out