Hacker News new | past | comments | ask | show | jobs | submit login

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

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?




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.


> Note that as a side-effect of this change, Django is now aware of asynchronous event loops and will block you calling code marked as “async unsafe” - such as ORM operations - from an asynchronous context.

Am I correct to understand this as meaning async views can’t even read from the database yet? I guess the only use cases for ASGI views currently would be interacting with outside-Django backends that implement async support and such?


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?


Andrew gave a recent talk about it here 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.


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...


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), which is a wrapper on top of sqlachemy with a django like interface.


FastAPI runs blocking IO/sync functions in a separate thread pool to work around this issue.


Thanks for the suggestion - very interesting.


Thanks for the info. I'll probably start fiddling with Django again, it has sure been a while for me.

Also, thank you and all the contributors for such amazing resource.


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

[1] https://connexion.readthedocs.io/

[2] https://github.com/Yelp/bravado


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!


Thank you! ^_^


What's the difference from fastAPI? https://fastapi.tiangolo.com/


FastAPI generates specs from code, this generates code from specs


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.


Yeah didn't mean literary code generation, Python's dynamic nature makes such steps unnecessary.

In a way it feels kinda lispy (in a good way) to me, data is code, small DSL for working more efficiently with specific domain.


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


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

(Partly inspired by FastAPI)


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.


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


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


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


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


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=...). (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.


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?


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-...), due to the coupling of validation with serialization.


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.


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


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: