Comment by arcturus17 | Hacker News Reader

Comment by arcturus17 | Hacker News Reader

Parent Full thread

I built a production app in Django last year, and I loved a lot of things about it, but I felt some important shortcomings.

Async support was clunky at best... The Django way of doing things has traditionally been to either use a queueing system like Celery or multi-threading, but I find first-class async like in Node is much easier for many typical web tasks (database I/O and calling external services).

I also faced issues with libraries for menial tasks. My setup was Django + React and JWT was poorly supported - the most popular auth library needed quite a bit of manual patching in code to make it all work. This was very surprising... I walked away with the feeling that some of the libs for what should be common use cases nowadays are not "production-grade".

DRF while powerful and well-documented also had a decent amount of quirks for things that were not so far at the edges.

Raw deployment on PaaS like Heroku and Elastic Beanstalk (tried both during the project, ended up settling on the latter) without Docker or K8s, also a bit messier than I'd have liked at times, but ultimately OK.

Things I really liked: models and the ORM (again the occasional niggle at the edges but good 98% of the time), most of DRF, Python itself, Python types, the admin panel, management commands, the custom commands "framework", testing.

But as it stands, with my qualms above, I think for the next project that deserves a full-batteries framework, I might give something like .Net or Spring + Kotlin a chance.

Just a few observations:

- Async... The Django way of doing things... Celery -> it's a background task system which is like bringing a bazooka to kill a fly for what you wanted to do (I assume proxying the request to an external API).

- database I/O and calling external services -> Use gunicorn gevent worker type that brings up the pseudo threads.

- JWT was poorly supported -> There's at least 5 battle tested libraries that you can use to implement JWT alone (simplejwt comes to mind first)

- the most popular auth library needed quite a bit of manual patching in code to make it all work -> Which one? There's few that are standard and most are easy to customize via global settings.

- Raw deployment on PaaS like Heroku and Elastic Beanstalk -> that's more on the platform rather than Django itself

- DRF -> I agree, DRF has it's own way of doing things and deviating from them can give you massive headaches.

> it's a background task system which is like bringing a bazooka to kill a fly for what you wanted to do

We actually used for things that were close to its purpose. Mainly scheduled background tasks. However, from what I could see in the Django world, sometimes there's also a temptation to use it for heavy CPU or network bound tasks.

> Use gunicorn gevent worker type that brings up the pseudo threads

My point still stands, more complex than async in Node.js, C# or Spring for example.

> There's at least 5 battle tested libraries that you can use to implement JWT alone (simplejwt comes to mind first)

Exactly what we used: dj-rest-auth (the supported one) with simplejwt plugin. And we encountered problems on a very simple use-case: simply sending the JWT to the client. I had to patch some code found in an obscure GitHub issue for the repo, which I cannot find right now, otherwise I would link to the issue itself.

> that's more on the platform rather than Django itself

Yes, mostly, I don't blame Django itself, but support for deployment is important for me and at the end of the day I do factor it in.

> DRF -> I agree, DRF has it's own way of doing things and deviating from them can give you massive headaches.

I would add, sometimes the way of doing things was not that clear... It was not always clear whether the convention was to annotate some data or do some intermediate computations in the models or in the serializers, and opinions on the internet varied wildly. But overall that comes with the territory in software development, again I don't think DRF itself was to blame, it does many things extremely well, and does offer many clear conventions.

> the most popular auth library needed quite a bit of manual patching in code to make it all work

Which one did you use?

It was dj-rest-auth, the version that continues to be supported, with the jwt plugin.

Reply on news.ycombinator.com