3 Best Django Hosting Providers in 2022 – Django App Deploying on Live Server

Platform as a Service

For those developers who know what they’re doing, and yet don’t wish to have to deal with the entire software stack underlying their Django application, there’s PaaS.

The illustration above shows the difference between three prevalent cloud models, differentiated by how much control is left to the customer and how much of the infrastructure is handled by the vendor. With Platform as a Service(PaaS), every single bit of software infrastructure-on top of the hardware-is handled by the vendor. This usually includes the framework itself-in our case, Django, WSGI (or, as we will discuss, ASGI), server software, database server, middleware, and so on.

Vendors like Google App Engine, Heroku, and platforms such as Pythonanywhere and Platform.sh usually provide customers with the tooling, conventions and workflow needed to deploy Python web apps to their infrastructure. The customer provides the application logic and the vendor provides the platform.Other cloud vendors such as Microsoft Azure and Amazon also provide this model. Each vendor differs in the level of management, tooling and so on they provide to developers, so do your homework before choosing one.

Server Interfaces

Web applications essentially respond to different (web) route requests by clients, by outputting some kind of code. Usually it’s a combination of static files, HTML markup, CSS, JSON data and other formats. What makes web apps different from mere web pages is their dynamic output.

These applications aren’t equipped or optimized to serve web pages in production, to handle the HTTP protocol, to serve static files, to cache content in an optimized way that web servers like NGINX or Apache are.

That’s why we have web server interfaces. If we deal with Python web app deployments in any significant way, we need to know about WSGI, and the newer web server interface ASGI.

Web Server Gateway Interface

PEP (or Python Enhanced Proposal) 3333 from 2010 defines the Python Web Server Gateway Interface, an interface specification for communication between python web apps and servers. WSGI applications, compliant to the specification, are stackable, and pass on the requests and responses between the application and the server.

From Python release 2.5, in 2006, Python implements its own WSGI server.

The stackable nature of WSGI apps means that apps in the middle must implement both sides of the interface-server and application-and the top and bottom ones need to behave as server and application, respectively. This also means practically unlimited extendibility through middleware.

With Django apps, for years the standard has been Apache server +mod_wsgi. mod_wsgi is an Apache server module first publicly released in 2007, when it replaced another module,mod_python, which worked by embedding a Python interpreter into the Apache server process.

Just as mod_python was a successor to CGI interface with Python in terms of efficiency, mod_wsgi succeeded mod_python.

Another implementation of the WSGI standard is uWSGI, an application server compliant with the WSGI standard, which has gained popularity in recent years. It’s capable of running as a standalone server, but it’s usually deployed behind NGINX as a reverse proxy. As the docs say:

We wrote about deployment flow of a Django app with uWSGI with Mina, which is a capable and minimal deployment tool specialized for Rails apps, along with a screencast.

Another tutorial by the author, describing deployment of a Flask web app on Alibaba Cloud, and which can be used to deploy web apps on any Linux server,can be found here.

uWSGI has extensive documentation that covers a wide range of scenarios, from standard cases like deployment of standard Django apps behind NGINX and deployment on Heroku to using WebSockets, and includes discussions about the separation of resources using Linux namespaces versus LXC containers. uWSGI is currently one of the more robust server options for the WSGI stack.

Other WSGI implementations to mention are Gunicorn, a Python web server installable via pip, which also recommends deployment behind a web server like NGINX,werkzeug,CherryPy,gevent-fastcgi and numerous others.

If we deploy a WSGI application and server behind a server like NGINX, our virtual host file will simply proxy the requests to the dynamic part of our app to the WSGI server running on a certain port on localhost, by using the proxy_pass directive:

When we use uWSGI as an application server, according to the docs, we can also pass requests via Unix sockets, using theuwsgi_passdirective:

uwsgi_pass unix:///tmp/uwsgi.sock;
include uwsgi_params;

More information about the WSGI standard can be found here, and the documentation has user guides for a wide range of cases.

Asynchronous Web Server Interface

Asynchronous Web Server Interface, or ASGI, is described inits documentation as “a spiritual successor to WSGI”. It aims to be backward-compatible with WSGI, but to provide support or interface for asynchronous applications.

This interface is meant to provide for long-polling and WebSocket connections.The asynchronous ASGI server works as an event loop, so a simple application, to borrow from the docs, might look like this:

async def application(scope, receive, send):
event = await receive()
…
await send({“type”: “websocket.send”, …})

The implementations recommended by the Django docs include Daphne, which is a reference implementation of the spec written on top of Twisted, an event-based, lower-level server or engine, and Uvicorn, an ASGI web server that supports WebSockets, includes Gunicorn worker class, and is wsgi-compatible.

According to some benchmarks, Uvicorn is faster even than Node.js, but for a real benchmark, we would have to have very similar, almost identical applications to compare on top of Uvicorn and Node.

"""WSGI config for xyz_app project.
It exposes the WSGI callable as a module-level variable named ``application``.
For more information on this file, see
https://docs.djangoproject.com/en/2.2/howto/deployment/wsgi/
"""
import os
from django.core.wsgi import get_wsgi_application
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'xyz_app.settings')

One environment variable here comes to our rescue: DJANGO_SETTINGS_MODULE . We could change the filename and path to our settings.py file here and make it custom.

Thanks for choose django as a web framework.