5 ms·

We have been migrating a project from DRF to FastAPI, and its a massive performance improvement. Which was what we were needing. Unfortunately our data was just

We have been migrating a project from DRF to FastAPI, and its a massive performance improvement. Which was what we were needing. Unfortunately our data was just not well handled by DRF, and serialization from PG > Python > JSON was absolute horrendous. So we love the speed we are getting with FastAPI. Now you do lose a lot of things. There is no more Django ORM, so we are back to using SQLAlchemy. I don't think this is bad, but definitely different. You also have to write a lot more specs, and such. Which can be annoying, but not too bad. It also encouraged us to go over to type hints on the whole code base and has save from a few bugs as well. Overall we really like it, not sure I will go back to DRF on any future big projects. Still handy for something quick, but not what I want to be using moving forward.

rattray 6y ago
Thank you for sharing! Very useful. Can you share what kind of perf gains you got? latency? concurrency? > You also have to write a lot more specs, and such Sorry, by "specs" do you mean type definitions? Oh, and congrats on a successful port!
- Bedon292 6y ago
  Our performance gains have primarily been in serialization, so response times are way better. It used to take multiple seconds for some things to serialize in DRF, and down to sub seconds. Its like 4x faster in that regard. Yeah, meant Pydantic Models, SQL Alchemy models, and the actual endpoints. Its a lot of repetition in places. But the finer grained controls have been good for us so far. You just have to write the models, and don't need to worry as much about input validation in your own code. Which has been great.
  - rattray 6y ago
    That makes a ton of sense - thank you! Yeah part of the magic of DRF is all the implicit stuff and the DRYness, but of course that can bite you anyway.
jamestimmins 6y ago
OP has a pretty interesting writeup about why DRF model serialization is slow. https://hakibenita.com/django-rest-framework-slow https://hakibenita.com/django-rest-framework-slow

rattray 6y ago

Thank you for sharing! Very useful. Can you share what kind of perf gains you got? latency? concurrency? > You also have to write a lot more specs, and such Sorry, by "specs" do you mean type definitions? Oh, and congrats on a successful port!

Bedon292 6y ago
Our performance gains have primarily been in serialization, so response times are way better. It used to take multiple seconds for some things to serialize in DRF, and down to sub seconds. Its like 4x faster in that regard. Yeah, meant Pydantic Models, SQL Alchemy models, and the actual endpoints. Its a lot of repetition in places. But the finer grained controls have been good for us so far. You just have to write the models, and don't need to worry as much about input validation in your own code. Which has been great.
- rattray 6y ago
  That makes a ton of sense - thank you! Yeah part of the magic of DRF is all the implicit stuff and the DRYness, but of course that can bite you anyway.

jamestimmins 6y ago

OP has a pretty interesting writeup about why DRF model serialization is slow. https://hakibenita.com/django-rest-framework-slow https://hakibenita.com/django-rest-framework-slow