|
|
|
|
|
|
by bkovacev
1455 days ago
|
|
|
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. |
|
|
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.