1

I'm developing an application that controls some piece of complex hardware and exposes a front-end to the users using Django, mainly for cross-platform and remote access reasons. Currently using Django templates, but soon with a separate front-end through DRF calls. My main points of interest are:

  • user management. Admin users have more access
  • session management. Ideally, one cannot login from multiple IPs at the same time.
  • web-socket support for asynchronous notifications and real-time monitoring.
  • asynchronous background operations. e.g. with celery workers

Note that the users of these application are the hardware operators which are usually no more than 3-5 tops, and most of the times, only one of them is actively working on it so no real user concurrency, neither real need to scale.

So my question is: Is there a real reason I would want to distribute my application using a production server such as gunicorn instead of simply running manage.py runserver?

Vagos Duke
  • 331
  • 2
  • 11
  • 2
    I would ask the opposite question: Is there a real reason I wouldn't want to distribute my application using a production server such as gunicorn and instead run `manage.py runserver`? – Abdul Aziz Barkat Oct 26 '22 at 08:02
  • 1
    Does this answer your question? [Django: Difference between using server through manage.py and other servers like gunicorn etc. Which is better?](https://stackoverflow.com/questions/35657332/django-difference-between-using-server-through-manage-py-and-other-servers-like) – Abdul Aziz Barkat Oct 26 '22 at 08:08
  • The benefits of a proper production server far outweigh the costs really, and the costs basically are just the initial setup being a little more complicated. – Abdul Aziz Barkat Oct 26 '22 at 08:10
  • @AbdulAzizBarkat Mainly for configuration overhead. If I want to distribute a single-click application, I can start the server with `manage.py` and then lunch the system's default browser to localhost. Whereas, if going with gunicorn, I'll have to setup with docker-compose along with nginx and whatever else, and then launch the browser – Vagos Duke Oct 26 '22 at 08:23
  • So you're saying the users would be running the server on their own machines and accessing it from localhost, there won't be any domains or TLS/SSL certificates, etc? Tell me why then are you even going for a **web** application? BTW containers are nice but you can totally deploy NGINX, gunicorn etc. without any containers. – Abdul Aziz Barkat Oct 26 '22 at 08:26
  • Definitely no domains or SSL. But remote access may be a possibility (through VPN for example). I already answered why a webapp. Also because I know how to build it pretty fast and Django has many things already handled for me. – Vagos Duke Oct 26 '22 at 08:51

1 Answers1

2

From django runserver documentation:

DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests. (And that’s how it’s gonna stay. We’re in the business of making Web frameworks, not Web servers, so improving this server to be able to handle a production environment is outside the scope of Django.)

The development server is not intended for use in production. It is not designed to be particularly efficient, stable, or secure. It does not support all the possible features of an HTTP server.

In short, python manage.py runserver may work until it breaks!!

JPG
  • 82,442
  • 19
  • 127
  • 206
  • 1
    well, it does support the features I want. Let alone that "works until it breaks" applies to ALL software – Vagos Duke Oct 26 '22 at 08:25