Introduction
When I first learnt about how to deploy my Django website. I took the easy route which was deploying it on Heroku.
There's literally tons of tutorial on how the process of deploying it work. Heck, there was even a book about the benefits of deploying Django using Heroku.
Soon in my own work, I needed to deploy my own Django project. It was working well for a bundled development grade web server. I thought to myself, why not find a better way on a production-grade web server. Instead of just a miserable default web server that is not production-grade.
My journey in searching on deploying Django started for me. Which if you look at multiple tutorial references they still suggest the use of Heroku or Digital Ocean.
What is WSGI?
WSGI stands for Web Server Gateway Interface. It is essentially the standard that talks about how Python web applications are deployed.
WSGI servers were there to help standardise the deployment process among various frameworks even till this day. Which the popular choice was Flask and Django.
Now there is a ton of choices to select in deploying Django through WSGI. The traditional route was using mob_wsgi that is an additional module for the Apache web server where PHP & Java uses it to deploy their web applications.
The others are more towards specific niches or purposes like if you had a small project. I would choose uWSGI, due to it's all in one nature. Which bundles static file asset hosting, caching, SSL connections, reverse proxy & task queuing.
The other popular choice was having Gunicorn for flask applications to be bundled together to deploy it with Nginx.
ASGI Replaces WSGI for the Future
WSGI server has served an important purpose to make deployment of web applications easy for a web framework like Flask or Django as part of backend infrastructure instead of a full-stack solution due to the raise of frontend web framework like Angular, React and Vue.
The problem comes down to its relevancy where asynchronous requests are becoming the norm in Javascript land. New technologies like HTTP/2 or Websockets is being used as part of front-end development.
Therefore it is expected that in the future for web development asynchronous requests are considered the norm. Instead of being replaced by other backend technologies like ExpressJS, Laerval or Go.
The World with ASGI
Moving forward, I am excited about how ASGI can help a lot in the Python community.
In the use of async & await capabilities, web sockets and http/2 to make it faster and to remain relevant as the backend of choice for Django moving forward.
To me, Django might leak into the realms of microservices. Which Zappa took a different approach by integrating with AWS related. Please donate to the project if you had gain value from it to keep the project alive and well.
ASGI will be used more often and hopefully allows anyone to break the dependency of Celery. Which can be a pain to set up and maintain when developing in Django with it.
Conclusion
Wow, that's a lot of things I wrote about ASGI. Moving forward if you don't require an asynchronous request, WebSockets & HTTP/2. It won't put much of a dent to you as a Django developer.
Instead, I would use WSGI servers like uWSGI or Gunicorn to help in my deployment. If I'm going for a customised approach to deploying my web applications on a server.
I had heard great things about cloud providers like AWS, Azure and Google Cloud. Besides that, I am thinking of playing around with Digital Ocean for their Hatch program for Startups and Linode that was recommended by Chris Hawkes.
In future articles, I'm thinking of playing around with various deployment options in the cloud. Since it feels like a growing trend to deploy it on these cloud providers.
If you like this article sign up for my Adventurer's Newsletter for a weekly update in the area of Python, Startup and Web Development.
You can also follow me to get the latest update of my article on Dev
The original post was on Why ASGI is Replacing WSGI in Django - Reading Time: 3 Mins and cover image by timJ on Unsplash
Reference
- Web Server Gateway Interface
- An Introduction to ASGI, Asynchronous Server Gateway Interface
- How to Deploy with ASGI
- How to Use Django with Daphne
- How to Use Django with Uvicorn
- A Single File Async Django Application
- Hello ASGI
- Django Channels
- Django 3.0 begins its async-capable journey with ASGI
- The ASGI Revolution is Upon Us
- mob_wsgi
- uWSGI
- Gunicorn
- Nginx
- HTTP/2
- Websockets
- Zappa
- Celery
- Digital Ocean
- Hatch
- Linode
- Chris Hawkes
- Undraw
Top comments (15)
Thanks a lot Max. I am using pythonanywhere to deploy my Django projects. The problem though is setting environment variables. I have tried to use python-dotenv but it's still some pain in the a**. Would appreciate if you made an article on the same. Thanks
Hmm.. haven't been using pythonanywhere for a while. I might think of writing it soon.
Thank you..how do you set your environment variables. I am deploying a project that requires twitter api credentials.
Did you try this?
Yes i did. That is what i was following. I can get the SECRET_KEY in my bash shell but the code provides an error that the secret_key environment variable is not set.
I concur that some of the patterns that "require" reliance on a task queue do go away with ASGI/event-loop. However, ASGI is not a task queue -- it does not have the same power and resilience built-in. Depending on what your application is doing, you'll likely end up needing to rely on those technologies, still.
That being said, the point is valid: lightweight tasks may be able to be moved into ASGI land!
Nice I think there's multiple ways to skin a cat for task queue. Due to it's being relevant for a while now but let's us look at the development for it.
ASGI is an excellent idea! I've deployed countless sites using tried and true mod_wsgi with Apache. But as the back-end is quickly moving to REST, with app logic increasingly built into JavaScript payloads, server driven template frameworks are becoming less versatile. I think ASGI is a welcome compromise to keep Django relevant.
Yup it is that is why Django should change with the times if not it will fade away in not being used anymore.
Thank you for the introduction Max. I was looking to write something similar.
The next big milestone for jungle in my humble opinion is the orm to natively support nosql.
Hmmm..I don't really think so I think it might be good to have GraphQL support by default will be good.
Than again there is a Django package for it so there is nothing really that bad with it.
Are you talking about djongo? I'm not aware of any other to be honest, can you throw me a link?
I think the graphql integration can be achieved very nicely with the graphene module.
Yup that is the graphene module.
Thanks for introducing ASGI Max. I have been using Gunicorn for Django too. You might wanna check post on dev for the same.
Deploying Django with Celery and Redis on Ubuntu
Idris Rampurawala ・ Nov 5 '19 ・ 7 min read
It's not really that relevant for my article but well as long as it helps the Django community I don't mind.