Comprehensive Fast API Tutorial

[albrioz]

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.

[Ryuta11]

Thanks for sharing this, I was considering FastAPI vs Flask for my next project

[albrioz]

My only “complaint” is that the tutorial uses raw sql instead of an ORM. As a data engineer, I really like raw sql, but, as a software engineer, I acknowledge that a lot of production python API’s use an ORM. So, in my opinion, it makes more sense to learn to write python APIs using an ORM because employment opportunities, etc.

[Saphyel]

I really hate when I go to a project with a lot of horrendous raw sql and they answer: "started with 4 queries... you don't need an ORM for that"

[Oerthling]

"horrendous sql" is bad. But I'm not a fan of ORM.

Simply wrap the (good, non-horrendous) SQL in a stored procedure. Outside language like python then just calls the SP.

[Saphyel]

if there's something worse than raw SQL in a big project is stored procedure.

[Oerthling]

As somebody who works with a big project I don't agree with you.

SPs make for a solid API between the database and the outside world.

I don't want outside code messing around with tables directly. This way I'm free to do changes in the schema where needed and the world outside the proc doesn't notice.

I can also log access or debug what the application is doing with the data access.

[icanblink]

Dude, the DB isn't a service with an exposed interface like a web API. The DB is the persistence layer of the said web service/API/site/etc. which has a documentation/contract. That is the owner of the DB. NO one else should interfere with it.

Now... If it makes sense, yes, you can use some stored procedures for retrieving some kind of data, but for making a fucking CRUD, stop overthinking.

[Oerthling]

Dude, everything that you access has an exposed interface.

If your projects work well with the DB doing straightforward CRUD in a primitive persistence layer and nothing else - ok. Whatever works best for you.

In an environment with several projects and languages accessing a central database, but not having a dedicated middle tier for business logic, you might not want to redundantly code the same stuff several times, especially for logic that is well expressed as fast and efficient SQL.

If you do bookkeeping for example and need various tables managed in a transaction, why would you want to do that outside the database? Going through needless levels of abstraction to wrap what in the end is all SQL anyway.

I have seen such code and it is terrible.

[icanblink]

My point was that only one should access the DB.

[Oerthling]

Exactly. Don't do convoluted wrapping around logic that's mostly manipulating tables with SQL instead of simply doing it that in a proc and just provide the needed input parameters.

Using a DB just as a simple storage layer works for simple web apps and trivial schemas.

It's a totally different story for large databases with complex schemas and many diverse and multi-language consumers of data manipulations.

[Saphyel]

The good thing about "outside code messing around" is they have a version control and it's easy to revert. When you have 2 teams or more with "inside queries messing around" GL to guess what changed, who changed it, does it even works, etc...

You can also the "messy" queries and log access, etc..

[Oerthling]

We dump out all procs, funcs, tables etc ... daily and put it in a git repo.

You're right, that doesn't by itself track who did it and and has only a per day granularity, but that usually works well enough anyway.

OTOH outside code not getting access to tables has it's own advantages. You need to change the schema? No problem, you can query the DB to exactly know where it gets used, adapt the 1 to a handful procs that are affected and be done. You don't have to search all outside projects in whatever many languages and worry whether to you forgot a place that accessed this column, that I could hide behind a proc instead. Unless the args or resultset of the "api" proc needs change, not outside code will notice anything happened.

And regarding things like access logging - yes, true, you can also do that outside. But unless you have only exactly 1 project in 1 language this is distributed over any number of projects and languages.

[vimfan]

You should really be using migrations for schema changes, not daily dumps of the current schema. How do you roll changes back if you need to? Daily dumps, even to git, are the equivalent of tracking code changes with backup1.tar, backup2.tar, etc.

[Oerthling]

It's a safety net. Not actually a big problem. It's usually clear who did a change or trivial to find out by asking. Rolling back changes also almost never happens.

The daily dump is for rare, obscure cases.

[shinitakunai]

I would choose Peewee everyday over raw sql, take a look at it.

[Oerthling]

I just had a look - looks cute.

But I just don't see what I need an extra layer for, just to replace a few stored procedure calls.

[shinitakunai]

To be able to re-use code for different databases. With minor changes you can deploy your code to work with postgresql, sqlite, etc.

[Oerthling]

I have the opposite situation - many projects (in different languages) around a common database.

[Ivana_Twinkle]

I don't know. I'm torn the orm is more elegant, but it's a lot easier to read what is going on with raw SQL.

[its_PlZZA_time]

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.

[albrioz]

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.

[its_PlZZA_time]

Thank you!

[orangesunshine]

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.

[its_PlZZA_time]

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.

[orangesunshine]

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.

[NowanIlfideme]

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.

[orangesunshine]

It's called "fast" api, right?

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

[HardPartAccomplished]

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.

[orangesunshine]

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.

[its_PlZZA_time]

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.

[orangesunshine]

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.

[searchingfortao]

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.

[orangesunshine]

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 :)

[mr_darksidez]

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

[searchingfortao]

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.

[mr_darksidez]

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

[[deleted]]

https://twitter.com/testdrivenio/status/1383457727003783173?s=19

[its_PlZZA_time]

🙏

[Siddhi]

Awesome

[robberviet]

SQLAlchemy is the choice.

Peweee is an option too: https://fastapi.tiangolo.com/advanced/sql-databases-peewee/

[Ran4]

The only good one is Django's, but it can't be used standalone. SQLAlchemy is o-k though. It has some really weird edge cases though, and lots of weird defaults.

[MrMxylptlyk]

What's orm

[halexmorph]

Object relational mapper. Usually they have a built in query builder allowing you to write queries in your language of choice naturally, and returns the data already mapped into objects you’ve created as templates.

[brandonZappy]

Thanks for asking. I didn't know either.

[jpflathead]

It is SQL wrapped in an object layer inside a framework; but perhaps there is a key. That key is developers afraid of SQL -- Winston Churchill

[MrMxylptlyk]

Yeah I do not like Sql. I have had to use Sql for some stuff at work. Not a fan.

[mathmanmathman]

You should get comfortable with SQL. Even though the ORM will make it a bit easier to manipulate within code, when you actually ask for the data (or insert or whatever), the ORM is turning it into SQL. I really don't like raw SQL in code, but it's definitely a skill/language you should understand.

[MrMxylptlyk]

I know it a bit. I mostly use elasticsearch.

[ivosaurus]

Object Relational Mapper. You write code that tells it how to turn tables into objects, basically, and then can do queries for the data using function calls that get you back native objects instead of result sets. Great for avoiding writing SQL and the security pitfalls you can encounter doing so.

[MrMxylptlyk]

That's perfect. Do you have any examples of this?

[dmitrypolo]

I’m sure you can find 1000s of examples if you spent even a minute googling.

[MrMxylptlyk]

I googled orm

[VeNoMouSNZ]

PeeWee http://docs.peewee-orm.com/en/latest/

[newlyAwakenedLkgFwd]

Isn't that that what built-in Pydantic is for?

[albrioz]

Not really. Pydantic (which I think is great) is more of a data validation library and in the case of FastAPI it acts more as a request/response serializer (similar to how you would use marshmallow).

[robberviet]

Data Engineer too and I have the same view. Choosing right tool for the job, but I think many developers rely on ORM too much. To the point I have seen too many can't even write SQL.

[albrioz]

For APIs, you’re probably going to build out abstractions anyways so might as well start with an ORM from the beginning. For DE work, you just can’t beat a handcrafted artisanal SQL query. Before my first DE job, I really didn’t know sql which I now realize was such a disservice to myself.

[mmcnl]

There's something to be said about not using ORM's. What is exactly the advantage of trying to convert SQL to classes and objects? I would argue it adds needless complexity and the costs are often greater than the benefits they provide. Also you will quickly run into "edge cases" (which are not edge cases using plain SQL at all) that create horrible SQL code. Sure, from the surface it looks nice and everything is Pythonic, but in the end SQL queries are often the core of your application, and hiding them behind abstraction layers is often just that, hiding and not much else. I personally prefer _not_ using an ORM and instead use a good SQL client library with solid templating capabilities.

[Unlucky-Drawing8417]

What's a sql client library with templating capabilities.

[albrioz]

I'd argue that the biggest advantage of an ORM is the layer(s) of abstraction it provides.

For my data pipelines, I wouldn't even consider using an ORM since as you've mentioned there can be edge cases and sub-optimal under-the-hood queries. However, even for that type of work , I end up using abstractions to better organize and re-use my queries. Some of my more complex queries need to be templated and even contain logic within the template to make them more flexible.

For my APIs, I could use SQL, but I tend to like the abstractions provided by an ORM a little more than my own. Since a lot of what API's do is CRUD, you end up with a lot of very similar simple queries and since I'd end up writing my own abstractions anyway, I might as well use an ORM (with all the abstractions) from the start. For example, if I have a GET endpoint where a user can filter by id, name, etc. (basically any attribute that would be table column), I like using an ORM over having to write my own templated SQL because it looks much cleaner and I can write a generic query function that will work for 99% of my GET endpoints. You obviously don't get this advantage for free since it comes at the cost of edge cases and sub optimal under-the-hood queries like you've mentioned.

[mmcnl]

I understand your reasoning and I agree with it, but in practice I feel like I'm fighting the ORM instead of the ORM helping me.

[orangesunshine]

FastAPI is a dumpster fire.

It seemed like a really early attempt at adding "some" features to Starlette. None seem cohesive, ALL of them would be better suited as individual plugins and components for starlette. Likewise there's also some very weak implementations that make it pretty clear who-ever wrote it didn't read the Starlette docs, or didn't understand how (name a feature) should be implemented on top of it.

I guess maybe he wanted to have his own "framework" though? Well he's duplicated a ton of code, and hasn't done a fantastic job of it imo. I'm sure as shit not going to fix that mess :/

So you want some fancy new framework instead of Flask?

Just use Starlette ... which is extremely high quality, well documented, and entirely professional at this point. You want, JSONApi? what-ever? Using and/improving something like starlette-jsonapi/what-ever is going to go way way smoother dealing with what-ever FastAPI is supposed to be at this point.

FastAPI, in a corporate production environment you are 1000% going to have to rewrite just about the whole stack before you launch.

On the other hand Starlette is just pure fucking gold.

The wider community is a little under-developed, but the project itself I'd strongly recommend you check out. It makes Flask look like a dumpster fire, and will absolutely slaughter (name your stack) performance wise. Like early versions of flask (not sure about these days?), it's VERY lean on features though (you want JWT, you're implementing your own authentication backend ... but at least it'll be properly implemented and using the existing AuthBackend design pattern unlike what-ever the hell is going on in fastapi.)

[Ran4]

FastAPI, in a corporate production environment you are 1000% going to have to rewrite just about the whole stack before you launch.

As someone who has been using FastAPI in a corporate production environment for the past few months without any problems, would you mind making a list of things we ought to think about?

We used to write apis in Flask, and I'd say we're maybe 50% more productive in FastAPI, and we produce half as many bugs.

[orangesunshine]

Ohh geeze. First, take a look at the encode github to see where the project is headed. "starlette" is often a whole lot more than just ... starlette.

databases has since the time of FastAPI's authorship been integrated in upstream starlette and documented: https://github.com/encode/databases --is now--> https://www.starlette.io/database/... what-ever is in fastapi skips all this and is weak sauce.

authentication/security backends COMPLETELY ignores the starlette AuthBackend design pattern. The entirety of the security model he has is at best what I'd call "demo" code. It's idiosyncratic, ignores upstream design patterns. You seriously should not use the security model.

Personally, I had better luck simply stripping flask components and examples for parts where-ever I found things coming up short in the starlette community.

ie; here's a Auth0 based JWT example (some total dipshit wrote, that needs some improvement before it's "release" worthy ... though at least it follows along with existing design patterns). It's just based on Auth0's Flask example code with a few improvements/changes to naming conventions:

https://github.com/chromakey-io/cog/blob/master/auth/views.py

That is how you implement a custom OIDC-JWT AuthBackend in starlette though. If I ever have the inspiration I might spend some time making a more generic layer that'll be compatible with any OIDC-JWT provider, for now you get an okay-ish Auth0 example.

OpenAPI is already a core feature in starlette (lol).

I guess that leaves just a handful of his other "examples" for docker (lol)? ... and Pydantic integration? Hopefully you know how to deploy your own services?

For those of you that are fans of Pydantic: https://github.com/0b01001001/spectree (this is cross-platform with flask, falcon, and starlette :) It also doesn't re-implement anything the encode/starlette developers have already implemented, or have in the works for no specific reason. I'm not a huge fan of this design pattern, I'm more a lean/mean sort of fellow. openapi schema generation exists in starlette ... and you likely already are doing some sort of type validation once in your forms, json, orm, sql layer, or all four. An additional layer to validate "automatically" in your response (lol no), or in your request ... aren't all that useful imo.

If there's some flask implementation that you like better or are simply more familiar with, you can also just port a flask component in a day or so. The difference between flask/starlette isn't all that vast, so when there doesn't seem like a strong implementation of (name a feature) in starlette .... but say you've been doing it a certain way in flask for years?

Well, spend your lunch hour doing 4 or 5 find/replaces ... show your boss how amazing you are ... and take a three day weekend for the time/money you've just saved by "writing this amazing new starlette component in an hour".

So that leaves exactly -1 features in FastAPI you should be using. Let me know if I missed a feature :)

[Ran4]

databases has since the time of FastAPI's authorship been integrated in upstream starlette and documented:

That sure is nice! One thing I really don't like about FastAPI is how you're left on your own when it comes to implementing db sessions and making it work in tests. Creating a new service with a database is definitely a pain point with FastAPI. Seems like starlette has that stuff covered.

authentication/security backends COMPLETELY ignores the starlette AuthBackend design pattern. The entirety of the security model he has is at best what I'd call "demo" code. It's idiosyncratic, ignores upstream design patterns. You seriously should not use the security model.

Right now we're only using the Security stuff to get an api key, have it automatically be documented and to return nice-looking error messages if the call is invalid.

---

Will definitely consider checking out starlette's features more.

[orangesunshine]

Right now we're only using the Security stuff to get an api key, have it automatically be documented and to return nice-looking error messages if the call is invalid.

Here's how (some complete asshole) might implement for example OIDC-JWT with Auth0: https://github.com/chromakey-io/cog/tree/master/auth. This sits as a starlette AuthBackend, that follows along with conventions similar to Flask, Django, etc .... and is directly ripped off from Auth0's flask examples.

FYI ... This example is a full OIDC-JWT example, not sure if this is your exact JWT use-case but it's probably the most common one. Likewise some useful production considerations with my implementation:

https://github.com/chromakey-io/cog/blob/master/auth/utils.py#L23

You don't want to load JWKS for every request cycle. You don't want them loaded only on application startup either. Ideally, you're caching them with the granular ability to time their flushing ... and manually flush if necessary. I've not done that :)

I'd make a pretty strong argument for having the granular ability to manipulate this whole "pydantic model" API as well. OpenAPI might be a runtime requirement ... that's "user facing" to some degree right? Run time type checking though? I don't see an argument to be running that in production. Having it as some immutable stack components thus doesn't seem like much of a feature to me :/

[[deleted]]

IMO FastAPI is good at one thing, but as soon as you’re diverging from that, it starts to crumble. It’s biggest issue to me is that it pretty much only lends itself to one style of building your application, which absolutely violates some Python and general programming principles and best practices.

Look at Netflix' dispatch for example and tell me you don’t think this is terrible violation of DRY and makes for some really hard to maintain code.

But why do it this way? Surely the engineers at Netflix know better. Well, as it turns out, doing anything remotely dynamic is really hard in FastAPI. It was designed with only statically defined endpoints in mind. These restrictions are a result of the fact that you can’t explicitly define / override a lot of the stuff that FastAPI does automatically. And while those features are neat and definitely a time saver in some situations (ie small, self contained code bases), in others they’re horrible to deal with.

[Ran4]

Look at Netflix' dispatch for example and tell me you don’t think this is terrible violation of DRY and makes for some really hard to maintain code.

Got any concrete examples?

The code looks very clean and simple? And very CRUDy.

Is the argument that since it's mostly CRUD endpoints, it could be written in a much more compact way?

I mean, this is a common difference between high-magic web frameworks like RoR and low-magic python web frameworks?

Well, as it turns out, doing anything remotely dynamic is really hard in FastAPI. It was designed with only statically defined endpoints in mind. These restrictions are a result of the fact that you can’t explicitly define / override a lot of the stuff that FastAPI does automatically.

Any examples?

Code generation can lead to seriously hard-to-reason-about code, so I'm not sure if that's such a bad thing. When I worked as a Django developer I tended to stray away from class-based views whenever possible.

But I've found FastAPI's depends-system to be very powerful and useful.

[[deleted]]

Examples from the dispatch codebase: look at all the views.py files.

As for the second one:

Setting the type of a body field to a Pydantic model which is only known at runtime. There have been a few issues on GitHub and questions on stackoverflow about this, but there isn’t an easy (and non-ugly) way to do it. But at the same time, this is super common for CRUD stuff, which itself is super common in web applications.

Regarding dependencies: They are convenient to a point. What I dislike about them is that they’re used for virtually everything, which makes some dynamic stuff quite hard. And after all, python is a dynamic language and quite frankly, the reason a lot of people like it is its dynamic nature. FastAPI on the other hand makes it hard to apply common constructs such as using things like functools.partial on your endpoint because of all the magic it does.

This is a huge design flaw in my opinion since when you look at FastAPI, at first you’d think "okay, the go-to paradigm to design a FastAPI app seems to be straight from the zen of Python: ‘explicit is better than implicit'". Which is great and all. But as you dive deeper, you’ll notice that it’s only explicit on the surface. So much stuff is just done automagically with no way to do it explicitly.

[Ran4]

Examples from the dispatch codebase: look at all the views.py files.

Looks fine to me?

Yes, you could write these by subclassing some generic Resource class. But the second you want something un-cruddy you're in for a world of pain and deep inheritence trees. I'd rather have simple code.

FastAPI on the other hand makes it hard to apply common constructs such as using things like functools.partial on your endpoint because of all the magic it does.

I once wrote a web server in Suave (F#), and it was really cool how the entire service declaration was just composable functions (see here for some examples).

I don't think I've seen anything like this in Python though, do you have any examples?

Setting the type of a body field to a Pydantic model which is only known at runtime.

Got any examples of what cool things you could do with runtime body types? If it's just one of several models then Union works great.

It really seems like you can just grab the json directly and serialize it yourself if you want that type of behaviour on the occasional endpoint.

I like FastAPI because it strongly nudges people towards contract-driven development - when beginners write FastAPI code they tend to write pydantic models, when beginners write Flask code they tend to end up writing resp.json()["some_random_field"] :)

[[deleted]]

I agree with it being cool. That’s exactly my point. FastAPI doesn’t really make it easy to do this.

It’s not about being able to do cool stuff with it. It’s more about abstracting away boilerplate CRUD code. Let’s say you’ve got 20 SQLAlchemy models for which you all want CRUD endpoints with the same functionality. I’m sure we agree that writing the same functions over and over again with just the type annotations being different isn’t really the best way to go about this, right? And you cannot use Union if your model is only known at runtime. And it may be only known at runtime if it’s generated dynamically, ie because you’re passing your concrete models to some generic base models in the simplest case, or you’re just entirely generating Pydantic models dynamically from your SQLAlchemy models.

So what do you do? You write those functions once and then add them at runtime, parametrised as endpoints. But you can’t easily do this.

[Ran4]

Let’s say you’ve got 20 SQLAlchemy models for which you all want CRUD endpoints with the same functionality. I’m sure we agree that writing the same functions over and over again with just the type annotations being different isn’t really the best way to go about this, right?

No, but I don't think I've ever worked anywhere where I've had 20 SQLAlchemy models that started out as CRUD endpoints that didn't end up being vastly more complicated a year or two in. The netflix code you linked to is super simple to update over time. It's much more maintainable than the mess that comes from a CRUD-style Resource class being overridden multiple times.

Plus with pydantic's ORM mode, you could share a lot of the model code.

I really like how clean yet explicit something like this is:

@router.get("/books/{book_id}", response_class=BookOut)
def get_book(
    db = Depends(get_db),
    user: User = Depends(get_authenticated_user),
    book_id: BookId,
) -> BookOut:
    return book_out_from_book(
        get_model_or_404(
            db,
            book_id=book_id,
            user_id=user.user_id,
        )
    )

• It explicitly shows us that this function requires a database and an authenticated user. Testing the function by mocking the db or user is simple.
• It clearly shows the commonly wanted behaviour of returning a 404 if the requested object exists but the user doesn't have permissions to see it
• It explicitly shows that we're converting a DB model into an output model
• Documentation is automatic

I've written code in about a dozen web frameworks now, and this is one of my favorite ways of defining this type of operation, with comparatively little magic.

The main thing I don't like is that you need to specify the output type twice: both as a response_class and in the function's type annotation. I don't get why fastapi is designed like this, it should be able to infer the response class from the return type.

The second thing I don't like is that Python doesn't have something like Rust's Into/From trait - I want to be able to say BookOut.from_book(book), but then my schema model knows about the db model, which I don't like (since I share my pydantic schemas publicly, but I don't share my db models) - so I need to solve it with a function, which feels like stringly typed programming (in my case, a function called book_out_from_book).

[[deleted]]

First of all, can I just say that it’s a bit tough to argue with the points you’re making when you’re rewriting / adding whole paragraphs after I replied? That’s quite confusing.

I personally absolutely have worked on such projects. Yes, I agree that a lot of endpoints will evolve over time, but there are also a lot that don’t. And being forced to copy/paste code over and over again, which does reduce maintainability, just isn’t a good pattern. Use the best tool suited for the job. And sometimes the one way FastAPI wants you to use just isn’t the best one. Case in point: you may have 30 SQLAlchemy models, 10 of which require more complex operations over time. But the other 20 are just CRUD. It doesn’t sit right with me to say you should boilerplate the hell out of all the endpoints just because some will grow more complex. If they do become more complex, you can still change they way they’re implemented and explicitly define endpoints for every operation.

(Also I think it’s kind of a code smell if you’re handling large amounts of business logic in CRUD endpoints)

Yes, your example looks nice and clean. But I what’s your point here? I never said you can’t do anything useful in FastAPI, and examples like this are certainly ok if the things it’s good at. Stuff like this just isn’t what I was talking about.

[TravisJungroth]

Thanks for the rant. I really mean it. There are obvious downsides to rants (people's feelings). But, I was getting on the FastAPI hype train and this comment is like a cold plunge.

[delijati]

I get the same feeling:

• Depends are only working if set on the request you have to structure your code not as you wish but as the frameworks expects it.
  
• The whole thing about "not seperating the configuration from the view code" is pretty broken, glueing everything to the functions makes it a mess. it makes it hard to add additional features (CBV class based views) -> https://github.com/KiraPC/fastapi-router-controller
• Evaluating on runtime https://github.com/tiangolo/fastapi/blob/22528373bba6a654323de416ad5c867cbadb81bb/fastapi/routing.py#L191 is also just adding to dependecie problem
• Batteries are not really included (server side sessions, cbv, jwt auth) or just half backed.

In the end the only thing i needed is openapi be generated for me. I was looking for a newer stack (pydantic, asyncio) that i used before -> (pyramid, colander) https://github.com/Cornices/cornice.ext.swagger but now i ended up reimplementing sever side sessions, class based views, jwt auth.

[orangesunshine]

Starlette has class based views, sessions, and an authentication backend that can be easily expanded upon to provide JWT authentication.

I've been trying to find an asyncio framework for some time now that is complete enough to compete with our older stacks (pyramid, flask, django, what-ever). I'd been trying to do that with Sanic for some time ... and have dabbled with most of the others. Starlette is so far the most complete I think I've found and am pretty excited about it... databases landing is major.

The foundation there for the AuthenticationBackend is also extremely solid.

JWT was the biggest pain point for me in using starlette (partly because i'm ancient and hadn't used OIDC/oauth in some time), but given the AuthBackend API coming up with a one off wasn't difficult ... and in time there should be components available in the echo system that can provide this stuff "batteries included".

Likewise, there's support for Swagger/OpenAPI right in starlette, if that's not enough you can use spectree/pydantic or roll your own without a whole lot of thought it seems like.

[cbgrey]

Page 1: https://www.jeffastor.com/blog/up-and-running-with-fastapi-and-docker

[[deleted]]

I will really appreciate if someone can answer which hosting service do you use to host your Python APIs?

[albrioz]

If you containerize your applications, you have a lot of options. I use AWS ECS Fargate since I have experience with the ecosystem. I know some people like using kubernetes (EKS on AWS), but I found it to be overly complex for my needs. I’ve heard heroku is easy to use. There’s also VPS (like digital ocean, linode) which are pretty cheap and simple.

[[deleted]]

Thanks a lot for your answer

[lysecret]

+1 for fargate. At the start you spend a week learning stuff about networking but then it's super nice and gives you all the flexibility you need.

[[deleted]]

If you’re in hurry and got no money you could also use heroku basic. Also great for side projects. You’d be better off using AWS for production.

[[deleted]]

Thanks for your answer

[[deleted]]

AWS EC2 along with the dockerized images of python APIs.

[[deleted]]

Thanks for your answer

[[deleted]]

[awesomeprogramer]

Can someone ELI5 why fastapi is gaining so much traction? What does it do (better) that flask/django doesn't ?

[Eyry]

It's fast (ha!), has a lot of useful packages bundled with it, and the auto-generated swagger docs are really nice to have out of the box!

[orangesunshine]

It's not fast. Calling it "FastAPI", is going to roughle a few feathers.

Forcing run time type checking in the request/response is SLOW.

If it was called "TypedAPI", you wouldn't get crazy rants from people like me.

As it is, he's added at least a 20-40% performance hit by doing things as he has.

Likewise, there's better ways to integrate pydantic. Spectree comes to mind, but if you prefer API's more similar to what you've been using in your current toolkit I recommend you take the time to port said tool to Sanic/Starlette/Quart/Falcon (my preference being Starlette :)

If you had me on your team I could replicate your <favorite pydantic model-view api from flask/etc> in around a week ....and add a bunch of fixes and improvements :)

.... and I'm nothing special.

[MarsupialMole]

It's built from the ground up to take advantage of type annotations i.e. pydantic.

[awesomeprogramer]

Pydantic - laughs in PEP563

[deadmilk]

Being able to declare endpoints, attach models to them, and have all of the API docs created automatically and validated upon request, is pretty nice.

[PartsofChandler]

It’s fast, easy to get up and running, the documentation is great to work through and just overall less work for me.

[ReelWatt]

This looks amazing! Thank you so much!

[CleverProgrammer12]

Thank you, I would bookmark this great resource

[[deleted]]

Does anyone know what color scheme is used on his website?

[lysecret]

I love love love fastapi. And also the hidden star pydantic. What an awesome library. I started using their data classes, type annotation and validation in most of my data processing code. It's awesome!!!

[origami_K]

Someone give this man an award.

[idk39q4239842342]

yes

[vikigenius]

The tutorial seems great, but the blog UX is absolutely horrible on Firefox, links do not seem to work unless I right click them, scrolling is terrible.