Published: January 19, 2020
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.
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.
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.
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.
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.
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.