9 ms·

I have been using FastAPI for the last two months (which also is an ASGI server and makes full use of annotations and type hints with mypy) and the experience h

by Ramiuz 7y ago

I have been using FastAPI for the last two months (which also is an ASGI server and makes full use of annotations and type hints with mypy) and the experience has been incredible. (https://fastapi.tiangolo.com/ https://fastapi.tiangolo.com/) If Django can now also support annotations and async code I dream of an scenario where apis can be built using this two elements. Does anybody know a good resource to learn/catch up with this release?

gonational 7y ago
I recommend the release notes for each version, starting with the one right after the last version you’ve used. There’s a couple reasons: 1. you get a breakdown of all the new features, which only takes a few minutes to kind of quickly go through each version and decide which bits you care about 2. you get a list of backwards-incompatible changes, which resolves any upgrade regressions, as long as you’re not using internal APIs that have changed
drieddust 7y ago
How hard was the learning curve? What are the main benefits over Django?
- m_ke 7y ago
  Learning curve is super low. Main benefits are: 1. Performance, it's a wrapper on top of starlette/uvicorn, which brings the performance closer to nodejs (https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=fortune&l=zijzen-1 https://www.techempower.com/benchmarks/#section=data-r17&hw=...). (I did run into some issues with it though due to the default response validation when serializing large response bodies) 2. Lightweight background tasks (from starlette) 3. Documentation generation from type annotations. It's a nice tool for microservices but coming from django you'll have to roll your own database management, authentication, sessions, caching, admin and etc. I'm also not a fan of the magic request unpacking using type annotations and prefer getting a request object as is done in django and starlette. IMHO most people would probably be better off with plain starlette and a 3 line decorator to handle request validation and response serialization.
  - bransonf 7y ago
    It looks pretty similar to flask as far as syntax goes. Why do you think plain starlette is better? Are the type annotations annoying to debug?
    - m_ke 7y ago
      I had a few endpoints that had to handle url parameters, query parameters, http headers and bodies which could either be json, form data or files, handling all of those options using type annotated parameters ended up being pretty messy and I ended up just using the starlette request object. I was trying it out for a machine learning service that had to send back large dense vectors and I hit some other performance issues (like https://github.com/tiangolo/fastapi/issues/360#issuecomment-537690623 https://github.com/tiangolo/fastapi/issues/360#issuecomment-...), due to the coupling of validation with serialization.
rsinger87 7y ago
I wrote a package that allows use of type annotations for validation/serialization in Django Rest Framework: https://github.com/rsinger86/drf-typed-views https://github.com/rsinger86/drf-typed-views (Partly inspired by FastAPI)
BerislavLopac 7y ago
Pyotr [0] is a small library I've been developing for a while, based on Starlette. In a nutshell, it takes an OpenAPI specification and turns it into an API application, taking care of all the routing and validation according to the spec. It is conceptually similar to connexion [1], but it supports async and is Python 3 only. There is also a client component, in the spirit of bravado [2]. [0] https://pyotr.readthedocs.io https://pyotr.readthedocs.io [1] https://connexion.readthedocs.io/ https://connexion.readthedocs.io/ [2] https://github.com/Yelp/bravado https://github.com/Yelp/bravado
- dtkav 7y ago
  This is awesome! I'm one of the community maintainers of connexion (I added openapi 3 support), but I don't have write access to the repo, and it's been really tough to get any changes landed lately. nice work!
  - BerislavLopac 7y ago
    Thank you! ^_^
- j88439h84 7y ago
  What's the difference from fastAPI? https://fastapi.tiangolo.com/ https://fastapi.tiangolo.com/
  - hultner 7y ago
    FastAPI generates specs from code, this generates code from specs
    - BerislavLopac 7y ago
      Just a bit of clarification: Pyotr does not generate any code, it uses the spec as configuration to construct the necessary routes at the app initialization, as well as to validate requests and responses.
andrewgodwin 7y ago
It's worth pointing out that the ASGI support in this release is very low level, and doesn't let you write async views or anything yet. We're still working on that.
- petters 7y ago
  Thanks for your work on this. If I am willing to hack a bit, is it possible? What is the main obstacle? Is it all middleware?
  - m_ke 7y ago
    Andrew gave a recent talk about it here https://www.youtube.com/watch?v=d9BAUBEyFgM https://www.youtube.com/watch?v=d9BAUBEyFgM middleware is a part of it, then there's the ORM, caching and anything else that does IO.
  - mattrp 7y ago
    If you’re in the hacking mode - what do you think of taking the Django orm and grafting it onto fast api - sort of like a stand-alone sqlalchemy but with all the ease and power or django’s querysets...
    - m_ke 7y ago
      Django ORM is not async so using it with FastAPI would block the event loop. I guess you could wrap the calls in sync_to_async from asgiref but it wouldn't be pretty. Another option is using something like Tom Christie's orm project (https://github.com/encode/orm https://github.com/encode/orm), which is a wrapper on top of sqlachemy with a django like interface.
      - mattrp 7y ago
        Thanks for the suggestion - very interesting.
      - hultner 7y ago
        FastAPI runs blocking IO/sync functions in a separate thread pool to work around this issue.
minimaxir 7y ago
See also the base starlette, which is what FastAPI is built upon and is ASGI from the ground up. https://github.com/encode/starlette https://github.com/encode/starlette
marliechiller 7y ago
id like to chime in with positive experiences with FastApi and starlette
lovehashbrowns 7y ago
I've been messing around with FastAPI as well and it really is such a pleasure to use. ️ Its documentation is what really makes it a stellar project for me.
deleted 7y ago
[deleted]
tedivm 7y ago
I love FastAPI. We're using it for a ton of different things right now, from machine learning model containers to API layers. It's a really easy project to get started with, and the developers have been iterating on it pretty quickly.
bredren 7y ago
I liked this (and other!) episodes of Django Chat, https://djangochat.com/episodes/django-30-preview https://djangochat.com/episodes/django-30-preview
mixmastamyk 7y ago
Looked at fast api docs and it looks great. Curious how to interface it with an ORM or DB without duplicating model/field definitions?
elm_ 7y ago
I've been using FastAPI at work for the last 8 months or so, and it's been a delight. Coupled with Pydantic for validation it really does make things easy :D

by Ramiuz 7y ago

gonational 7y ago

I recommend the release notes for each version, starting with the one right after the last version you’ve used. There’s a couple reasons: 1. you get a breakdown of all the new features, which only takes a few minutes to kind of quickly go through each version and decide which bits you care about 2. you get a list of backwards-incompatible changes, which resolves any upgrade regressions, as long as you’re not using internal APIs that have changed

drieddust 7y ago

How hard was the learning curve? What are the main benefits over Django?

m_ke 7y ago
Learning curve is super low. Main benefits are: 1. Performance, it's a wrapper on top of starlette/uvicorn, which brings the performance closer to nodejs (https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=fortune&l=zijzen-1 https://www.techempower.com/benchmarks/#section=data-r17&hw=...). (I did run into some issues with it though due to the default response validation when serializing large response bodies) 2. Lightweight background tasks (from starlette) 3. Documentation generation from type annotations. It's a nice tool for microservices but coming from django you'll have to roll your own database management, authentication, sessions, caching, admin and etc. I'm also not a fan of the magic request unpacking using type annotations and prefer getting a request object as is done in django and starlette. IMHO most people would probably be better off with plain starlette and a 3 line decorator to handle request validation and response serialization.
- bransonf 7y ago
  It looks pretty similar to flask as far as syntax goes. Why do you think plain starlette is better? Are the type annotations annoying to debug?
  - m_ke 7y ago
    I had a few endpoints that had to handle url parameters, query parameters, http headers and bodies which could either be json, form data or files, handling all of those options using type annotated parameters ended up being pretty messy and I ended up just using the starlette request object. I was trying it out for a machine learning service that had to send back large dense vectors and I hit some other performance issues (like https://github.com/tiangolo/fastapi/issues/360#issuecomment-537690623 https://github.com/tiangolo/fastapi/issues/360#issuecomment-...), due to the coupling of validation with serialization.

rsinger87 7y ago

I wrote a package that allows use of type annotations for validation/serialization in Django Rest Framework: https://github.com/rsinger86/drf-typed-views https://github.com/rsinger86/drf-typed-views (Partly inspired by FastAPI)

BerislavLopac 7y ago

Pyotr [0] is a small library I've been developing for a while, based on Starlette. In a nutshell, it takes an OpenAPI specification and turns it into an API application, taking care of all the routing and validation according to the spec. It is conceptually similar to connexion [1], but it supports async and is Python 3 only. There is also a client component, in the spirit of bravado [2]. [0] https://pyotr.readthedocs.io https://pyotr.readthedocs.io [1] https://connexion.readthedocs.io/ https://connexion.readthedocs.io/ [2] https://github.com/Yelp/bravado https://github.com/Yelp/bravado

dtkav 7y ago
This is awesome! I'm one of the community maintainers of connexion (I added openapi 3 support), but I don't have write access to the repo, and it's been really tough to get any changes landed lately. nice work!
- BerislavLopac 7y ago
  Thank you! ^_^
j88439h84 7y ago
What's the difference from fastAPI? https://fastapi.tiangolo.com/ https://fastapi.tiangolo.com/
- hultner 7y ago
  FastAPI generates specs from code, this generates code from specs
  - BerislavLopac 7y ago
    Just a bit of clarification: Pyotr does not generate any code, it uses the spec as configuration to construct the necessary routes at the app initialization, as well as to validate requests and responses.

andrewgodwin 7y ago

It's worth pointing out that the ASGI support in this release is very low level, and doesn't let you write async views or anything yet. We're still working on that.

petters 7y ago
Thanks for your work on this. If I am willing to hack a bit, is it possible? What is the main obstacle? Is it all middleware?
- m_ke 7y ago
  Andrew gave a recent talk about it here https://www.youtube.com/watch?v=d9BAUBEyFgM https://www.youtube.com/watch?v=d9BAUBEyFgM middleware is a part of it, then there's the ORM, caching and anything else that does IO.
- mattrp 7y ago
  If you’re in the hacking mode - what do you think of taking the Django orm and grafting it onto fast api - sort of like a stand-alone sqlalchemy but with all the ease and power or django’s querysets...
  - m_ke 7y ago
    Django ORM is not async so using it with FastAPI would block the event loop. I guess you could wrap the calls in sync_to_async from asgiref but it wouldn't be pretty. Another option is using something like Tom Christie's orm project (https://github.com/encode/orm https://github.com/encode/orm), which is a wrapper on top of sqlachemy with a django like interface.
    - mattrp 7y ago
      Thanks for the suggestion - very interesting.
    - hultner 7y ago
      FastAPI runs blocking IO/sync functions in a separate thread pool to work around this issue.

minimaxir 7y ago

See also the base starlette, which is what FastAPI is built upon and is ASGI from the ground up. https://github.com/encode/starlette https://github.com/encode/starlette

marliechiller 7y ago

id like to chime in with positive experiences with FastApi and starlette

lovehashbrowns 7y ago

I've been messing around with FastAPI as well and it really is such a pleasure to use. ️ Its documentation is what really makes it a stellar project for me.

deleted 7y ago

[deleted]

tedivm 7y ago

I love FastAPI. We're using it for a ton of different things right now, from machine learning model containers to API layers. It's a really easy project to get started with, and the developers have been iterating on it pretty quickly.

bredren 7y ago

I liked this (and other!) episodes of Django Chat, https://djangochat.com/episodes/django-30-preview https://djangochat.com/episodes/django-30-preview

mixmastamyk 7y ago

Looked at fast api docs and it looks great. Curious how to interface it with an ORM or DB without duplicating model/field definitions?

elm_ 7y ago

I've been using FastAPI at work for the last 8 months or so, and it's been a delight. Coupled with Pydantic for validation it really does make things easy :D