Hacker News Reader

Comment by tiangolo | Hacker News Reader

Hey! FastAPI creator here

Nice surprise to find this shared on HN!

It's also great to see so many products/projects and companies using it successfuly in production!

I see a bunch of questions related to "how FastAPI compares to X", FastAPI was built from the learnings from other awesome tools, and is built on top of great packages. You can read a lot more about it here: https://fastapi.tiangolo.com/alternatives/

If you have questions or problems, you can ask in GitHub issues: https://github.com/tiangolo/fastapi/issues/new/choose

There's also an official Discord chat: https://discord.gg/VQjSZaeJmf

And finally, if you use FastAPI, I would love your input in the first user survey (you could win stickers ): https://tripetto.app/run/RXZ6OLDBXX?s=hn

View on HN

Thanks for FastAPI. It's a super exciting project.

As a very long time Django developer I see the potential for it to finally replace Django in jamstack-type apps. But two things are direly missing for that to be the default IMO:

1. A flexible admin. Django's admin allows for super fast prototyping. I wrote an accounting/bookkeeping app recently which I used for myself, and I didn't write a UI for it at all for several months because I could just get by with the admin. (Filed two quarterlies with just the admin as UI!)

2. An ORM that is as natural as Django's. I love SQLAlchemy but its syntax is a huge turnoff. I imagine the "right solution" combines the best of both worlds; maybe some Django-like syntax wrapper around SQLAlchemy. … with typings.

What do you think, is there progress in those areas?

Also a big django fan taking the plunge (we've started using FastAPI in production at work, and really love it!)

An admin interface would be wonderful, but given such a heavy API focus, I find Insomnia or Postman to work well enough for those interactions, so I haven't missed it all that much.

Seconding the SQLAlchemy friction though. Built-in ORM support would really help cut down the boilerplate required to wire FastAPI/Starlette models into the database. I think django devs feel the issue more acutely since defining FastAPI objects feels so familiar to making django models. But at the end, rather than having to wire up DRF serializers and viewsets, you need to wire up the database.

One other benefit to taking a more opinionated approach to database interactions: with a sensible-defaults-but-customizable user model, FastAPI could offer token based authentication/authorization out of the box by implementing something similar to Django+DRF+Djoser endpoints

Anyway, seconding the gratitude for this wonderful project, and really looking forward to using it more!

I don't know Djoser, but simpler utilities for auth and more docs with more examples are certainly planned. :)

Re #1, I haven't used it before but there is https://github.com/tiangolo/full-stack-fastapi-postgresql

Looks like it includes the kind of admin dashboard you'd get with Django.

Yep, that's the intention. But it's a frontend written by hand, and has to be updated by hand.

An automatic admin UI based on OpenAPI is one of the plans I have for the future. :)

I think the idea is that FastAPI does one thing and does it well. You can mix in other parts of what you need, in the same way FastAPI itself leans on great projects.

SQLAlchemy + Alembic are standard because they're robust and well-know, but there are alternatives (particularly with async)[0][1][2]

For admin you can FE it with something like react-admin which has pluggable data providers, or api-admin[4]

[0] https://github.com/tortoise/tortoise-orm

[1] https://ponyorm.org/

[2] https://github.com/encode/orm

[3] https://github.com/api-platform/admin

Is wtforms still in use?

using pydantic pretty much everywhere.

Ha! You just described 2 of the main future projects I have planned!

1. An admin UI based on OpenAPI, which makes it independent of DB.

2. A mix between Pydantic and SQLAlchemy, to use the same Pydantic model for both (I have some experiment in progress).

I just need to find the time for it all, but it's certainly planned.

> A mix between Pydantic and SQLAlchemy, to use the same Pydantic model for both (I have some experiment in progress).

I'm not if it's a good idea. If app is more complex than a TODO you end up with a few way to serialise the same DB model. You have a few schemas to update User in the DB, serlize into the queue without password etc.

> I love SQLAlchemy but its syntax is a huge turnoff.

Out of curiosity, which part of the syntax? (Hopefully not all of it.) Personally I hate the declarative part (defining the model), but feel the query syntax is good, especially with some SQL knowledge (Django’s isn’t bad either but is too divorced to the SQL syntax to me).

Thanks a lot for your work! We recently switched to FastAPI from Django rest framework at Etebase[1] and it's been an absolute pleasure!

P.S, if anyone is interested, it took a bit of hacking, but we managed to get two unusual things working:

1. Use MsgPack instead of JSON. It works great and wasn't too much of an effort (the existing libraries are done wrong and don't work well).

2. Use the Django ORM with FastAPI. This was quite hard to do and quite manual as the Django ORM assumes the rest of the Django stack is in use.

Etebase is open source[2], so you can just check out how it's done if you are interested. I'm also happy to help if anyone has questions.

I really hope we get a good async ORM soon. I'm currently using SQLAlchemy 1.4b1 in a side project, though the typing (and mypy plugin) are unfortunately not there.

[1] https://www.etebase.com

[2] https://github.com/etesync/server/

That's very cool!

TortoiseORM is quite similar to the Django ORM, but it's pretty early days, especially with the migrations. Might be a good fit for you guys, though.

Yeah, I took a look at it but decided against betting on another new tech, especially in such a sensitive area where there are so many things that can go wrong!

I have had the same challenge with other python ORMs. I would love it if the django ORM were separated from the django project itself. That would be a hugely positive thing for the industry.

Same experience. Just had a new project a month ago and we decided to stick to the tried and tested sqlalchemy + alembic after spending a few days looking at the new crop

pyDal has been around for ages. Wonder if you have seen it?

Was there any performance gain when you guys switched to MsgPack?

We didn't do it because of performance, we did it because of size. We deal almost entirely with encrypted data which means binary blobs. Msgpack lets us send binary data directly without the base64 overhead.

Thank you for FastAPI! Really well put together and I like how you’ve leveraged other great Python libraries.

Also had a good laugh when you posted about unrealistic job requirements awhile back [1] you know you’re doing something right when recruiters start asking for experience with your project.

[1]: https://twitter.com/tiangolo/status/1281946592459853830

Thank you, really appreciate your work! I think FastAPI is the first serious contender to Flask, which is saying a lot.

There is one thing though. It sounds small, but... Docs favicon is loaded from your webserver by default. I know telemetry helps, but not disclosing it and making it difficult to remove (believe me, it took me some time to do it) leaves a bad taste. Unnecessary, I would say, as the framework is impressive otherwise... I hope you reconsider this decision.

Regardless, thank you for creating and maintaining such an useful piece of software!

I'm glad you like it!

Hehe, there's no telemetry at all. It just points to the same docs' favicon (that is not even measured). Just to make a simple and easy to recognize UX. The same way JS and CSS for Swagger and ReDoc come from a JS CDN instead of forcing developers to figure out a way to serve those static assets.

But anyway, if you want to remove the favicon from Swagger UI, it's also in the docs: https://fastapi.tiangolo.com/advanced/extending-openapi/#sel...

Not sure we are talking about the same thing? The favicon is loaded from tiangolo.com server, not from the location of the docs? If there is no telemetry, then it's all the more important this got changed...

But anyway, last thing I want to do is argue - as I said, I really appreciate your work! Really big thank you! :)

That doesn't sound great. There is no reason the favicon should be loaded from tiangolo.com...

There is NO reason? Not even that is where the FastAPI is hosted and is the developer’s website? You can’t think of any other examples of something linking to the product homepage?

Here's the favicon URL: https://fastapi.tiangolo.com/img/favicon.png

The docs are here: https://fastapi.tiangolo.com/

Anyway, I'm glad FastAPI is being useful!

Thank you for creating this.

Until this post, I (1) was amazingly not aware of this (2) have started a side project in Django/DRF (3) am incredibly attracted by FastAPI's high-quality documentation

As it relates to the final point I would say the documentation has won me over so convincingly in just an evening's reading that I am planning to immediately rewrite the django rest framework codebase in FastAPI.

I'm glad you liked it that much! ...I hope the refactor is not too bad.

See my sibling comment[1]: I highly recommend switching to FastAPI, but you need to know that if you plan on still using the Django ORM you will need to do quite a bit of manual stiching in order to get it to work.

[1] https://news.ycombinator.com/item?id=25993345

Hi, thanks for a great framework!

You mention "High perf" as the first claim. Are there any performance benchmarks in comparison to other frameworks? I only ask because I see FastAPI as #228 on techempower. https://www.techempower.com/benchmarks/

If you actually wanted a fair(er) comparison, you can filter your benchmarks by Python. People choose FastAPI if they want a Python web framework, there is little use in comparing it to Rust and C++ frameworks or whatever...

That said, this list looks pretty bogus anyway, many of the tools listed here are not really frameworks to begin with. uvicorn for example is an ASGI server (you can run a FastAPI application ON uvicorn) so I'm not sure how this benchmark is "comparing" uvicorn and FastAPI.

If you filter the list to just Python you can see Starlette and FastAPI are the fastest.

This list falls away pretty quickly when building a real app. Common actions like calling another API or running a cpu or I/O intensive task for the user can change the performance profile of your app.

Good frameworks have tools for you when such needs arise and keep your app scalable.

One could write an app using the #1 on the TechEmpower list and end up with an unmaintainable mess. Maybe there should be a 'real app' benchmark that various languages/stacks implement to compare 'real world' scenerios.

Just want to say, what a great example of how to do documentation on mobile. Clean, legible, responsive, concise and human.

Thanks!

The system in big part thanks to Tom Christie (https://twitter.com/starletdreaming) for creating MkDocs (the documentation system) and to Martin Donath (https://twitter.com/squidfunk) for creating the Material for MkDocs theme.

I have been using fastapi for a project in the last months and it has been a delightful experience. I really love how the framework is designed, the great documentation and the built in support for Async/await.

Thanks for creating this awesome framework!

Nice work. Reminds me of Spring Rest support. I think both are similar in regards of development speed.

Will definitely add it to my toolbox. Hope Flask will die for good.

Thanks tiangolo! Keep up the great work!!

Reminds me of Spring Rest -> will add it to my toolbox. Hope nobody ever uses Flask again for Rest services in Python.

Reply on news.ycombinator.com