Early results from the Django Survey show that Django REST Framework and django-cors-headers are the top 2 third party packages by a lot. PyPI downloads show the same. I just had a short debate with @jeff on this, who maintains that often don’t need CORS so thought I’d share here and curious about others experience.
For me, I’ll often have Django on port 8000 and, say, React on 3000. So need CORS for that. Then will deploy front-end to S3 or something with a CDN and Django on its own, so need CORS there.
@jeff would say that’s over engineering; can just put it all on the same domain and use CDN for all of it.
“It depends” but I certainly didn’t expect to see more people say they use django-cors-headers over django-celery, pytest-django, django-crispy-forms, etc by a pretty wide margin.
If I understand the purpose of this package, it’s to allow other applications to make requests to your Django app? (Or do I have this backwards?)
Indeed. The typical usage case it to have Django/DRF stack on api.learndjango.com with a JS frontend hosted on learndjango.com or another domain.
Either way, I didn’t know about this package and hadn’t read anything about it until about 10 minutes ago.
The package is great.
All my deployments are behind nginx / uwsgi, any time I’ve needed to deal with those headers, I handle at that layer.
I would expect >90% of installs to use what you described. A good CDN provider can make this more manageable too plus you get all of the nice scaling wins of a CDN to boot.
For Will’s “I’m developing on two different local ports,” a proxy tool like devd (GitHub - cortesi/devd: A local webserver for developers) was built to help solve this. It’s a wonderful tool and you get the bonus of a livereload tool that mostly just works both with Django and JS.
Maybe we can get @adamchainz or @carltongibson to weigh in here. I get what @jeff and @KenWhitesell are saying but, in my somewhat limited professional experience, I’ve only seen it done in a separate matter (frontend vs backend) which requires the use of CORS. And devd looks cool, but that’s new to me. React reloads changes automatically and Django’s local server does most of the time too for reloads.
I guess it really all comes down to deployment though, which is such a deep ocean of differences that it can become hard to generalize.
Django’s local server does most of the time too for reloads.
Django’s runserver picks up most code changes (not so good at config changes), but it doesn’t livereload your changes.
devd will transparently re-fetch your page in your browser anytime you make code, template, CSS, or JS changes so that you don’t have to hit your browser’s refresh button to see the updated changes.
This doesn’t surprise me. I think most teams are split into multiple units: there’s one lot building an API using Django plus DRF, and another building the frontend with React or Vue or… Where there’s budget, there’s a third (or forth) team building native mobile apps, hitting the same API.
Most times, I’d guess, the frontend web team can’t have or don’t want any dependency on the Django project, so they can’t serve their app in development via the Django application. This means they put it on the separate subdomain, app., and so they need the CORS headers set.
It’s not how I’d do it on a solo project, or ideally in a team environment where there wasn’t such a wall between the groups, but, if I had to lay money, I’d punt that’s how it’s done in most shops in the wild.
In production, I too would have the frontend server set the headers, but it’s already working is a pretty powerful pull, and I’d guess a reasonable amount of folks aren’t necessarily deploying to an environment where they (easily) get to control these things. (I guess it’s similar to whitenoise: it sets all these headers that, surely, are the web server’s job. But what if there’s no web server? Or if you forget/don’t have time to set it up properly? … — that’s a massive tangent.)
